9. Working with legacy code

Starting Paragraph

A few years back I was consulting for a (very) large development shop that did Billing software. They had over 10,000 developerts with .NET, Java and C++ mixed products, sub products and intertwined projects. The software had existed in one form or another for over 5 years and most developers were tasked with maintinaing and building on top of existing functionality.   

Myjob was to try and help several divisions (of all languages) to learn Test Driven Development techniques. For about 90% of the developers I worked with, this never became a reality. There were several reasons:  

·Once I left it was really easy to go back to the “old” mode of work  

·There was too much pressure to do other things than to devote time to this learning task  

·It was proving really hard to write tests against existing code  

·It was next to impossible to refactor the existing code (or not enough time to do it)  

·The learning curve was too high for most people  

·Some people didn’t want to change their design  

·People did not see clear and quick results from doing this  

·Tooling was getting in the way (or lack thereof)  

·We didn’t know where to begin.  

How do we approach existing code? What issues are there to solve? Where do we start? Tough questions that most of us have to deal with. This chapter will try to tackle some of the problems associated with approaching legacy code bases to begin with, listing techniques, references and tools that might help.

Comments? Errata?