John Terracina

And at that point, all you’ve accomplished with the money & time they gave you for the rebuild is to shift your problems to the network layer, where they are way harder to see, analyze, test, and fix. That is not progress. IMO that’s engineer malpractice.

So...is it just impossible to improve your working conditions, when you’re working in a hoarded codebase? Are you just DOOMED to feel anxious every time you need to go near the precariously balanced User class until one day it just...falls over on you?

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.