[Joeri]

Codebases are sensitive to entropy, they degrade over time as they are changed, and it takes active effort to push back on technical debt. On a young project there is not much technical debt. On a small project you can have a quality release where you pay off most of the technical debt all at once, which is doable. On a large and old codebase the only way to push back against accreting technical debt is continuously and incrementally, reserving a slice of the budget in every cycle specifically for quality work. Most organizations do not do this, because that time rather gets spent on features instead. And that’s why as codebases get older and larger they degrade. Because they become unpleasant to work in, the older and more experienced developers leave for greener pastures. The more of the core team leaves, the bigger incentive to leave. Eventually the project is mostly staffed with people of lesser skill or lesser tenure (contractors passing through, juniors) and the practices start degrading as well.

And this is where you come in, on an old ugly codebase with perennial quality problems and bad development practices, stuck in a hole and trying to dig its way out. Eventually it will get replaced by a fresh new project by a fresh new team, who just know that this time it will be different.