Simple techniques for minimizing legacy code

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).

要查看或添加评论,请登录

Gil Broza的更多文章

  • Why your process needs slack

    Why your process needs slack

    Let's say you and the team keep a sustainable pace, are productive, and always have enough useful tasks to keep you…

    1 条评论
  • Why is “When will you be done?” so hard to answer reliably?

    Why is “When will you be done?” so hard to answer reliably?

    The question “When will you be done with X?” is asked a lot at work. It often creates tension, because it’s hard to…

    2 条评论
  • What does designing an Agile way of working look like?

    What does designing an Agile way of working look like?

    This client is a tech company with a pronounced engineering culture. When I started working with them recently, they…

    10 条评论
  • Agility Takes More Than Practices

    Agility Takes More Than Practices

    Your organization has an Agile way of working. Your previous company probably did too, but theirs was different.

    5 条评论
  • How to Maintain Agility During Rapid Growth

    How to Maintain Agility During Rapid Growth

    If you're a senior leader in a fast-growing tech company, this is for you. Agility was a vital strategy for getting…

  • Are Your Agile Planning Meetings Strategic Enough?

    Are Your Agile Planning Meetings Strategic Enough?

    Does your team frequently get together to plan the next sprint or some other cycle of work? In those meetings, do the…

    5 条评论
  • Do you have Waterfall in Agile clothing?

    Do you have Waterfall in Agile clothing?

    Recently, a project director at a client company asked me for help with sprint planning and retrospectives. He said: “I…

    2 条评论
  • How to Achieve Meaningful Agility

    How to Achieve Meaningful Agility

    Agile seems to be everywhere now, but I still see too many implementations that don’t produce meaningful agility…

    4 条评论
  • Are Your Agile Planning Meetings Boring?

    Are Your Agile Planning Meetings Boring?

    Does your team frequently get together to plan the next sprint or some other cycle of work? In those meetings, do the…

    2 条评论
  • Is your Agile process *really* feedback-friendly?

    Is your Agile process *really* feedback-friendly?

    Feedback is a fundamental principle in Agile. Do you truly get enough actionable feedback about your deliverables, and…

    1 条评论

社区洞察

其他会员也浏览了