>The problem with a careful but non-methodical approach is that it requires the programmer to correctly determine the stability value of their design. We often overestimate the importance of architecture on stability, or worse, architect something that is harder to maintain than the naive solution
There is EXACT SAME PROBLEM with choosing to cut engineering tho. And the cost of getting it wrong is far higher.
If you catch a problem early, well you just wasted the amount of time you tried to save.
If QA catches the problem before you get it to the client, that's 2-3x the cost right there. 5-10x when it gets caught on production. 20 to near unbound when it causes some long standing issue that's noticed too late
>With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple.
>With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping.
Not every software is a startup. If you have a requirements, first verify that they make sense in wider scope, then implement carefully while caring about potential edge cases. Not even handling them just making sure that they error out instead of propagate potentially invalid data further. That doesn't cost you even 2x the productivity.
> The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
In vast majority of cases those end up as pieces of spaghetti legacy code that are worked around by the rest of the org, not fixed. "Fixing it later" is more and more and more expensive the longer it is in production and the more code grows around it.
There is EXACT SAME PROBLEM with choosing to cut engineering tho. And the cost of getting it wrong is far higher.
If you catch a problem early, well you just wasted the amount of time you tried to save.
If QA catches the problem before you get it to the client, that's 2-3x the cost right there. 5-10x when it gets caught on production. 20 to near unbound when it causes some long standing issue that's noticed too late
>With buggy ship-it-now software you have a known bounded risk - bugs will occur in some cases but the software will ship and the bugs can be fixed because it’s simple.
>With prematurely architected software the risk is unbounded - the project may get bogged down indefinitely in its own complexity without shipping.
Not every software is a startup. If you have a requirements, first verify that they make sense in wider scope, then implement carefully while caring about potential edge cases. Not even handling them just making sure that they error out instead of propagate potentially invalid data further. That doesn't cost you even 2x the productivity.
> The inverse extreme can also be a problem, of course A project that is maintained for a long time on the naive implementation will also become unmaintainable. However, this will be due to _known_ architecture problems encountered during maintenance. These problems can be addressed in a relatively bounded amount of time. They are also quantifiable and thus explainable to management.
In vast majority of cases those end up as pieces of spaghetti legacy code that are worked around by the rest of the org, not fixed. "Fixing it later" is more and more and more expensive the longer it is in production and the more code grows around it.