What is one of the biggest impediments to adopting agile development? It’s a bit of a rhetorical question because there are many answers, with cultural issues being high on the list.
For this post, I’d like to focus on legacy software. Every established company has software systems that are used everyday and may have been in use for years. Regardless of how those systems were developed, any company that decides to take the plunge into agile software development hits an immediate impediment — all that legacy source code.
I’ve witnessed many situations where the business stakeholders get excited about doing something new and different yet they want all the old features, functions and data carried forward. What appeared to be a simple and fun software project turns into a tangled web.
What is legacy code?
There is no standard definition of legacy software because code bases vary widely in structure and quality. Here are a few situations where the phrase legacy code applies.
- Any code base that was not written by the current software team is legacy code.
- A code base that has been around for years and serviced by many engineers.
- Code that lacks documentation, test cases, or is otherwise difficult to decipher.
When trying to enhance legacy software, immediate questions surface. Where should software changes be applied? How do we know the changes will work as intended? How do we know there will not be unintended consequences?
Some teams try to avoid making software changes unless absolutely necessary. While wanting to avoid breaking anything is admirable, avoiding change is not how businesses prosper.
How do agile teams deal with legacy code? There are two high-level approaches to the problem and a seemingly infinite number of variations.
1) Start over. Forget the legacy code.
This approach won’t sit well with many organizations, but think about it. How has Apple been so successful with the iPhone and iPad? Because they started over. Compatibility with legacy software was not the goal. Look at the result!
Now consider Microsoft. What has held them back and prevented them from achieving their full potential in the mobile space? Backward compatibility. Microsoft has gone to great lengths to preserve their legacy. The approach has helped them in many ways but it has also hindered their ability to respond to leaner and more agile competitors.
The only way starting over can work is by setting priorities and maintaining a sharp focus on what really matters. Most companies don’t have the fortitude to pull this off so let’s look at the alternative.
2) Refactor the legacy code before making changes.
Adding features to fragile software will likely make matters worse. You have to understand and stabilize the legacy code base first. One of the best ways to do that is to start by writing tests. You know what the software does. Write automated tests to dive deep and find out how the software behaves. (Sounds like TDD because it is.)
Consider a complete re-write of all or portions of the system that prove to be incredibly fragile. Focus on interfaces. Write wrapper classes to encapsulate legacy components. Eliminate unused and rarely used features.
None of this will be easy or quick and the pressure to deliver new features will be intense. Find an executive-level sponsor and get adequate levels of funding and staffing.
Legacy code is not going away. Replace it or refactor it. The longer you wait, the more difficult it will be.