The right example is poorly executed. The left example is fine, but has one crucial deficiency: it’s not very modular, which makes it difficult to test and scale. Big problems need to be broken down and managed in discrete steps, and this is also true of computer code.
The left example is like running a pizza shop where you explain all the steps to everyone and then let everyone loose at the same time to make a pizza. The right example is like creating stations and delegating specific responsabilities to one person at a time.
The former creates redundancy and is manageable at small scale. But as you grow, you find that the added redundancy is of no additional value, while you end up with chaos, as people argue and fight over the process.
Can you imagine five developers working on the monolithic pizza code all at the same time? Total chaos. Better to have one developper assigned to baking, another assigned to prep, etc.
On the contrary, I think that the left piece of code is not building constrains prematurely and actually enables you to modularize it away when needed.
Sure, if the logic grows, if it needs to scale, if the team increases in size… then it makes sense to modularize it. But building something from the very beginning to achieve that is going to impose constraints that make it harder to reason about and harder to refactor; you’ll have to break down the previous structures and boundaries built by the function heavy example, which will probably introduce needless indirections.
The right example is poorly executed. The left example is fine, but has one crucial deficiency: it’s not very modular, which makes it difficult to test and scale. Big problems need to be broken down and managed in discrete steps, and this is also true of computer code.
The left example is like running a pizza shop where you explain all the steps to everyone and then let everyone loose at the same time to make a pizza. The right example is like creating stations and delegating specific responsabilities to one person at a time.
The former creates redundancy and is manageable at small scale. But as you grow, you find that the added redundancy is of no additional value, while you end up with chaos, as people argue and fight over the process.
Can you imagine five developers working on the monolithic pizza code all at the same time? Total chaos. Better to have one developper assigned to baking, another assigned to prep, etc.
On the contrary, I think that the left piece of code is not building constrains prematurely and actually enables you to modularize it away when needed.
Sure, if the logic grows, if it needs to scale, if the team increases in size… then it makes sense to modularize it. But building something from the very beginning to achieve that is going to impose constraints that make it harder to reason about and harder to refactor; you’ll have to break down the previous structures and boundaries built by the function heavy example, which will probably introduce needless indirections.