Hey Igor, you are definately on the right track. It is all about the ability to change the code as 2 things happen over time: (1) the codebase gets more complex, - as we add/fit more capabilities, more features, into it etc - it therefore becomes less generalised and more specific and (2) it is likely to need to become more perfromant as a result of the success of the product requiring more resources (i.e. faster response times).

To allow this to happen (in the future): (1) the team has to remain small (large teams have too many inter-dependencies), (2) the codebase has to be easy to change (component dependencies remain decoupled, affording scale out options), and (3) changes have to be fitted with confidence to avoid rework.

In order to enable that, you not only need clean code, you need to have an evolving architecture that takes care of decoupling the various components, and offering options to scale.

The majority of people creating and running software busineses these days do NOT understand these needs of their software business, and therefore they fail to prioritise and care of them early on enough.

They are the ones who also believe that adding more people to a codebase, makes it go faster, and replacing the existing "underperforming" people are viable strategies for dealing with big balls of mud to make them go faster. They fail every time. The only saving grace for them, are expensive rewrites with new people at the helm. Who then go on to repeat these mistakes every 5 3-years or so.

Was intending to help you refine the message you are sending.