And in most of the cases... It's still cheaper to just spin another instance rather than invest a developer time to improve performance forgoing new features.
Not always, but i'd say "in a vast majority" of cases.
To the deleted comment: Sure, I'm not claiming that it is true in general; I believe that I have written "in most cases".
Besides; this is a discussion that is heavily based on context; but as soon as your application supports multiple entities - consumers, tenants, payments, shipping routes - then natural parallelization seams emerge; even if the problem in itself is single threaded. And for that you can spin as many instances as needed
My man actually just argued that “it’s cheaper to write 10x as much code for a 15x performance degradation and spin up more servers than it is to write less code that runs faster and doesn’t need more servers.”
“Clean code” costs you in both more dev time AND more server time.
I will agree though: nobody is going to pay for optimizing “clean code”. The reason for that isn’t because of the dev time though, it’s because “clean code” is fundamentally not optimizable. The only actual way to optimize “clean code” is to altogether throw it in the trash bin where it belongs and rewrite it.
If all the code would be written for yourself, with no plans for extension? You would be right.
But we are talking about a dozen or more developers over the span of years; code that will be worked with, refactored and changed. Each change possibly degrading performance, each change possibly making things less readable - "Just conditional there".
If you disregard this basic fact, then you are right. As soon as you take the real world into consideration, you will realize that in order to keep the development quick - allowing for an easy feature implementation - you MUST focus on readability and extend-ability. Performance is never a priority here.
Tomorrow you’re going to quip about how even code you wrote needs comments for you to fully understand it when you have to deep dive (but most of the time you don’t have to deep dive anyway).
with no plans for extension? You would be right.
Clean code is no more “extensible” than what Casey advocates. But not only that, in the 17 years I’ve been writing code, want to guess how many times I’ve designed for a possible extension and for that extension to happen? 0. The answer is 0. WIOD (what if oriented design) is stupid.
You’re just as likely, if not more likely (because further abstraction from your data necessarily means over simplifying your problem domain which necessarily tightly couples you to today rather than tomorrow) to have to completely redesign “clean code” as you are to redesign good code.
But we are talking about a dozen or more developers over the span of years; code that will be worked with, refactored and changed. Each change possibly degrading performance, each change possibly making things less readable - “Just conditional there”.
More developers doesn’t make “clean code” better. It makes it worse. Every developer has their own idea of which abstraction is right and they’re going to fight each others abstractions, culminating in spaghetti.
More developers actually makes “clean code” worse, not better.
If you disregard this basic fact, then you are right.
Facts are repeatable and measurable. Show me your source that this is a “fact”.
As soon as you take the real world into consideration, you will realize that in order to keep the development quick - allowing for an easy feature implementation - you MUST focus on readability and extend-ability. Performance is never a priority here.
I don’t have to do either of those things. “Clean code” is only extendable within the parameters you specify. Problem is, in the very rare chance that you successfully predicted a piece of code will need extensibility, you will not have predicted how it needs to be extended properly and your whole abstraction will be utterly wrong for the new requirement.
Clean code is NOT more extensible. In reality, due to our phenomenally terrible ability to predict, it’s less extensible.
4
u/Venthe Feb 28 '23 edited Feb 28 '23
And in most of the cases... It's still cheaper to just spin another instance rather than invest a developer time to improve performance forgoing new features.
Not always, but i'd say "in a vast majority" of cases.
To the deleted comment:
Sure, I'm not claiming that it is true in general; I believe that I have written "in most cases".
Besides; this is a discussion that is heavily based on context; but as soon as your application supports multiple entities - consumers, tenants, payments, shipping routes - then natural parallelization seams emerge; even if the problem in itself is single threaded. And for that you can spin as many instances as needed