Matthew Walther

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.

So where does communication skill come into all this, you might ask? Is this another rambling thread that took an unexpected turn into philosophy and isn’t coming back? (I mean, that’s a fair cop. I do a lot of those.)

Well, let’s say I’ve convinced you that you need to do those small, opportunistic refactorings. You’re all in! You’re ready to work through the discomfort of introducing deliberate inconsistency in the name of improvement over time! Fantastic! HOW do you do that?

Remember, there were TWO problems that got you here - organizational pressure to forego refactoring, and a feeling that refactoring can only be done when you have time to do it all at once. At this point, we’ve only fixed the easier problem.

There are many in the Software Development Thoughtleadership Corps who take an individual, moralistic approach to organizational pressure. “It’s your job as a professional!” they say. “Just write good code! If they push back, just tell them ‘that’s not how I work!’”

This, of course, is horrible advice that comes from a place of extreme privilege. It does _occasionally_ work for white dudes. For most of us, though, if we tried it, we’d be labeled “difficult” or “naïve” and eventually managed out via tepid performance reviews.