I used to work with a company who bought other with legacy code and develop software using traditional approach (it means waterfall).
I recommended to the manager of IT department to read the chapter 18.
Reducing the Test Automation Backlog
Many companies with existing legacy code bases bump into a huge impediment when they want to get Agile: lack of test automation!
Without test automation, making changes in the system is very hard, because things break without anybody noticing. When the new release goes live, the real user discover the defects, causing embarrassment and expensive hotfix-or even worse, a chain of hotfixes, because each hotfix introduces new, unanticipated defects.
This makes the team terribly afraid to change code and therefore reluctant to improve the design of the code, which leads to a downward spiral of worse and worse code as the system grows.
The good news is that you can do something about it!
What to do About it?
Your main options in this case are as follows:
- Ignore the problem. Let the system decline into entropy death, and hope that nobody needs it by then.
- Rebuild the system from scratch using test-driven development to ensure good test coverage.
- Start a separate test automation project where a dedicated team improves the test coverage for the system until it’s adequate.
- Let the team improve test coverage a little bit each iteration.
According to the author´s experience the last one works better. However, I suggested to follow the second approach. Why? Well, if you have to work with some legacy code develop in an old platform such as Visual Fox you should have to take another huge impediment into account: the lack of developers that can deal with this old platform.