Remaining Agile When No One Around Knows Your Code

“Every project has code that might be deemed too hot to handle, or even radioactive. That’s legacy code.” — Steven Sinofsky, Surviving Legacy Code

In veteran digital industries, like financial services and others, core business platforms can easily be decades old. Regardless of the language in which they were written – much of this legacy architecture either can’t be replaced, is not cost-effective to replace because of its complexity, or poses too great a risk to product stability to modify.

At the same time, digital transformation and market demands require a higher level of code and infrastructure security, backed up by modern development standards and faster time-to-market.

So, when your code is decades old, written by programmers who have moved on to other roles or retired (in the best case) or even passed away (in the worst) – how can you be agile? How can you achieve the benefits of agility when there may literally be no one around who really understands your code?

SEE ALSO: Developer Velocity Drives Business Performance. Here’s How to Start Achieving It

What Does Legacy Code Have to Do with Agile?

There are three principles of agile software development (out of the 12 in the Agile Manifesto) to consider when discussing legacy code:

1. Gaining customer satisfaction by early and continuous delivery
2. Constructing your dev cycles to be flexible enough to support late development requirements changes
3. Delivering work frequently

To realize these very worthy goals, companies need to invest in four key areas that are both interconnected and mutually supportive:

1. CICD automation
2. Automated test coverage
3. Fast dev cycles, and
4. Frequent iterations

By investing in these four areas, time-to-market can be much faster, which increases competitiveness and customer satisfaction. Moreover, the ability to iterate faster translates into better product quality and greater flexibility in accepting last minute changes. And all of this facilitates better cross-company collaboration with less resource wastage.

Yet with legacy code, there’s a catch. Having evolved over decades of patches, revisions, and updates, it’s generally fragile. And code fragility and complexity are the arch-enemies of change. Fixing one bug or adding one feature can easily break something else. Add to that the lack of effective testing – meaning that a change that introduces a bug is less likely to be detected – and you can see how the implications of this rigidity are far-reaching.

A missed bug will likely be surfaced by customers eventually. This both affects customer satisfaction and introduces unplanned tasks for R&D, which then needs to shift focus from the planned product roadmap to regression fixing. This, in turn, causes R&D to miss roadmap deadlines or be unable to commit to development deadlines.

Although it may seem that legacy code is inherently problematic for implementing agile processes – this is thankfully not exactly the case.

Two first steps toward agility

Your legacy code may never be as flexible as fresh, new code written with the principles of agility in mind. But you can shift gently towards this direction.

The first step is simple: don’t make assumptions. Maybe it is bad code. Maybe you could have written it better. Maybe you’re tempted to go in with a hammer (a bad idea) when you should go in with a tweezer (probably a better idea). But the truth is, there’s generally a reason why the code evolved as it did – even if you don’t know it, and even if no one currently living knows it.

And then, start with:

• Regressions – Map your bugs, regressions, and new features to various areas of your code. Regressions are the most painful coding problems. They can prevent fixing bugs and creating new features. If you experience many regressions, it’s crucial to make sure you better understand the areas in the code that are responsible for them. This means you need to dedicate engineering resources in order to gain expertise on the most relevant code and focus first on test coverage and documentation in the areas that are most related to your regressions. These areas are the soft underbelly of your software – they’re the first stumbling block to becoming agile and quality-focused.
• Testing – With legacy code, the end justifies the means. Since your legacy code is an unknown entity, focus on staging and functional tests. Functional testing – which tests the end result of your software – is more practical than unit testing, where you test the code itself. Invest in making these tests part of your CI/CD, and strive for build per commit while running tests that matter automatically. Check which tests are failing most and consider shifting some of them left, to be executed by the developers even pre-commit. Investing in testing allows you to find regressions much sooner and provide developers with immediate feedback when they are still in the zone. And it’s no secret that the cost of finding and fixing bugs after release is far greater than before.

SEE ALSO: How Measuring DevOps Metrics Improves Software Delivery

The Bottom Line

Legacy code can be considered part of an organization’s heritage…or as a historical anomaly best forgotten quickly. But either way, it’s a fact on the ground. The temptation to rewrite an inherited codebase may be strong, but in many cases, the risks and resources commitments are simply too great.

Transitioning legacy code towards agile practices is the way to assure you’ll be able to continue to deliver competitively in the future. As Pierre Nanterme, the CEO of Accenture, put it: “Digital is the main reason just over half of the companies on the Fortune 500 have disappeared since the year 2000.” Today, we could just as easily replace “digital” with “agile.” It’s a mission-critical issue that will ultimately impact long-term business viability.

The good news is that legacy code and agility need not be mutually exclusive. With the right tweaks and a gentle hand, you can not only survive with legacy code, you can thrive with it.

The post Remaining Agile When No One Around Knows Your Code appeared first on JAXenter.