Giant, long lived, codebases are full of code that should never be used for anything new. Not only shouldn’t the code be used for anything new, it shouldn’t be used at all; but if it ain’t broke, don’t fix it.
The brownfield codebase gets littered with mineshafts, wells, and other hazards from products that were discontinued or never made it into production. Will the shaft collapse if you start digging? Maybe. Are those abandoned wells the right size to swallow new developers? Absolutely.
How do you move forward when your codebase has become a hazardous environment?
When a developer hangs the UI for your biggest customers because a reporting function is slow; is that the UI developer’s fault for not testing well enough, the report developer’s fault for not adding a warning about the function’s performance, or a sign of a dangerous codebase?
Once your codebase becomes hazardous it is everyone’s responsibility to be cautious, and everyone’s responsibility to warn of danger. Develop as a team and watch each other’s backs, otherwise you might end up stuck in a well.
