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.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programming@programming.dev
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person’s post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
Follow the programming.dev instance rules
Keep content related to programming in some way
If you’re posting long videos try to add in some form of tldr for those who don’t want to watch videos
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.