I’m attempting to strengthen a weakness in my knowledge, that weakness is working with legacy code or really being able to confidently change legacy code. Legacy code as Michael Feathers puts it in his book Working Effectively with Legacy Code, is simply code without corresponding tests. It doesn’t have anything to do with when the code was written or what obsolete language it was written in, legacy code is code without tests, often poorly implemented code without tests.

The concept of changing this kind of code with any level of confidence is something I’ve struggled with, in fact I’ve had to work on legacy code that was written this year, again proving that legacy code is not necessarily old code. As Feathers puts it, someone may be writing legacy code on your project right now. The amount of legacy code far out numbers the amount of new code.

You know you need unit and functional tests but the biggest problem is how to implement such tests on a system that wasn’t designed with that in mind in the first place. To introduce tests it seems you have to change code, sometimes lots of code, but if you don’t have tests already then how can you do that with any degree of confidence? I would say the current strategies I’ve learned over the years only cover about 20% of the cases, leaving about 80% to slow coding and repeated and mostly redundant manual testing and in the end a little of just hoping for the best outcome. Legacy code sucks, it drains the productivity out of you and cost the stakeholders money with slow development and and increased number of bugs with even the simplest changes.

I’ll let you know what I’ve learned in a full review I will write after finishing this book.