Simple techniques for minimizing legacy code

Legacy code... developers know it when they see it, even though it eludes a single definition. "Code that's hard to work with," "code lacking automated test coverage," "someone else's code," etc.

It's a vital part of products everywhere, but it's trouble. It makes product maintenance harder, more specialized, and slower. Programming around legacy code is scary ("What did I break? What should I retest?"). It invalidates estimates for new development. It makes team self-organization (and hiring!) harder.

Legacy code is not a new phenomenon. But it's a bigger problem when you use Agile methods!

Agile teams respond to changing requirements. Their members are empowered to work anywhere in the code. They may also be expected (pressured?) to have consistently fast delivery.

In many teams, these conditions result in a reduction in design, holistic thinking, intrinsic quality, and code maintenance. Those teams still produce legacy code, only faster. They move fast today, risking the ability to move as fast tomorrow.

Pre-Agile, teams tried to minimize legacy code in four ways: limiting changes to requirements, designing extensively before coding, specializing in parts of the code, and making code more generic/abstract than needed for the problem at hand. These approaches were rarely effective long-term. Nowadays, they're often barriers to agility.

In an Agile environment, minimizing the creation of legacy code takes other strategies and tactics that must become second nature. One of the strategies is to *evolve* software in *small, safe steps*. While that's a cross-functional responsibility, here are simple-to-implement examples of what it looks like for developers:

• When you're adding or changing code in some area, start by understanding the intents and ideas of the existing design, and work within them.
• Break down your work into small meaningful steps. And then break them down into even smaller meaningful steps, so you're not tempted to do Big Design.
• If that existing design doesn't readily support the next addition, adapt the design first. That's known as "pre-factoring."
• Instead of making the code so generic it can handle every eventuality, make it *simple* so it's cheap to adapt to likely changes.
• Keep the code clean as you go. Always be thinking: What will make it easy for others, and your future self, to keep working on this code?
• Get your colleagues' opinion and advice about your code, in real conversation, at least once every day (no big pull requests!). Be open to receiving and considering negative feedback. This will help you avoid getting too attached to, and reluctant to remove, code that harms the design.
• If you find yourself writing a TODO to go back and fix something, stop! Remember what happened to your last TODOs. Either fix the issue now, or put that task where it'll be seen and prioritized.

These techniques would greatly reduce legacy code without your having to "go hardcore" with TDD and mobbing (which are great, but let's face it, not welcome or realistic everywhere).