[riskneutral]

I think you mean "code quality" is always decreasing. The more people that touch a codebase, the lower the code quality gets. As soon as you get more than one person involved, the conceptual integrity and code consistency begins to breakdown. Even with a single individual, if they stop working on the code for a long time, then code quality will decrease when they resume development. The very best codebases are the product of a single mind, developed in a short period of time. These are, necessarily, smaller and more recent codebases, since one person can only do so much for so long. A small team can be cohesive enough to effectively share a common understanding of what "conceptual integrity" means for that codebase. As the team grows, organizational communication and coordination problems take over and codebase integrity degrades. The other enemy is time, because eventually the author(s) of any codebase will move on and it will become someone else's task to inherit and maintain that codebase. That is where the largest breaks in code quality will occur, due to the loss of institutional knowledge. It is very difficult for institutions to retain intuitive knowledge such as what the "conceptual integrity of the codebase" means. The problems are exasperated by the fact that code is rarely highly documented, and it can be difficult to express conceptual integrity in code because it is implicit in the code rather than explicit. The problems are exasperated by the fact that code quality is not the most important objective to maximize for most software developers and organizations. There are more important objectives, like delivering bug-free, working software on-time.

Which brings me to my point that "software quality" is something different. "Code quality" is what programmers obsess over because it determines the quality of their lives. But "software quality" is what defines the lives of their users. I would define high quality software as being performant, efficient, bug-free, secure, correct, usable interface, etc. Fortunately, these objectives can be met without necessarily needing very high code quality under the hood. The core banking software keeping track of your bank balances, or the autopilot software on your next plane ride, are probably written in in some terrible legacy of COBOL, FORTRAN, C, C++, etc, and probably have huge amounts of technical debt. But the objective quality of the software from the user side is very good, and once a critical software component has been written and tested, the preference is to not change it (if it isn't broken, don't fix it). As long as your bank balance shows up correctly and your plane doesn't crash, you don't worry about the underlying code quality at all as a user.

So, in summary, the bad news is that you can never prevent code quality degradation. Any large, growing and aging system will inevitably lose conceptual integrity, have poor code quality, will come with a mountain of technical debt, and will get harder and harder to modify and grow over time and scale. The good news, however, is that you can still ensure quality of the product for the end-user by throwing enough people, grind and money at the problem.

[timhrothgar]

This also matches my perspective. I was too cavaliere to make reference to software quality when in fact, I'm more curious about code quality. I think the implicit nature of the problem is a central component - because conceptual integrity can only be achieved (or maintained) through a greater appreciation for what is implicit vs explicit.

As such, perhaps its an unworthy goal to maintain high code quality over the long-term.