John Terracina

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.

This is so good. I've gotten so much push back over small refactoring. The push back always boils down to "why don't you refactor everything then?" Because that would take forever.

I could usually convince all the stakeholders, but it would take way too much effort. More effort than the code change. But I don't have the time or energy for 5 hours of meetings for each PR. So eventually I would avoid making any changes not directly related to the JIRA ticket