John Terracina

Ha ha! Of course not! This is where communication skills come into play. Because it is not at all trivial to even _understand_ the incentive structure that got you where you are, let alone to negotiate a new, healthier set of incentives.

The most common “presenting” pathology in the hoarded codebases I’ve seen - by far - is that developers don’t feel they have time and/or permission to refactor code.

Frequently occurring alongside that pathology is another - that developers see “refactoring” as a completely separate activity from building features or fixing bugs. A key indicator of this pathology is seeing stories in the backlog like “refactor user class.”

Just like its physical analog, a hoarded codebase only improves if you intensively work on changing those habits. This means deciding you will always do small, opportunistic refactorings when they appear to you in the course of fixing a bug or adding a feature.

I’m not talking about taking three extra days on a 1-point story to totally rewrite the user class. I’m talking about noticing a method you’re working in is out of place, and moving it - even if you don’t have time to extract the rest of the concept from the 8000-line file.

Just like when you’re dealing with its physical analog, your number one most important mantra when you want to improve a hoarded codebase is: Improvement Over Consistency.

This is SO HARD for us as developers. It gets drilled into us from day one that consistency is key to good code. And if you had good code, then sure, that would be true. But right now you don’t. Improvement Over Consistency.

One book on the shelf and five in the pile is better than six books in the pile. Improvement Over Consistency.