[proc0]

I think it's caused by the nature of how most companies scale their productivity up, which is by adding more people and creating more teams. As a result the codebase for any given product starts to reflect this organizational structure.

For example, a bank app might have a team for user management, and another team for product management. Then in the bank app, the designers added one module for selecting products on one page, and another module for selecting users on another page... and even though at the implementation level, these two modules are essentially the sam, they are implemented separately, as there is a lot of overhead in communication to have both teams implement one that handles both requirements.

I think this phenomenon guarantees that as codebases grow they accumulate tech debt. As more and more people develop on one application proper global abstractions that would be more efficient are not as common because of how the teams are structured in a way that is not aligned with this abstraction and instead is aligned with how the business side decides to structure teams.

I think it is born from a fundamental misconception of how software should scale as you add more and more features, and typically companies favor adding more people instead of asking their engineers to do the scaling using the software itself. Within a certain domain, there is very little reason not to abstract the implementation of features themselves, which would scale the application just by adding a few lines in a configuration file. Then a single engineer can be developing multiple features in the same amount of time an entire team completes only one. This might just be a blind side of someone who has not studied computer science theory, and instead thinks that if you want more software you need more people.

[bruce511]

I can resonate with this. We do well in a space with a commercial program. It's been under constant development for 27 years. It has never had more than 2 developers at a time (only 2 project leads).

This means the system is "coherent". Things are where you expect them to be, in code, and in the UI. it has scaled very well starting out for "small businesses" and today runs in big enterprises.

One benefit of this leanness is that there are very few meetings. When something is needed by sales, or there's a tricky design question, or hard programming, then a simple ad-hoc phone call moves things along.

That said, having 3 or 4 people going can be advantageous, but team-management goes up exponentially.