Legacy code

In the book Working Effectively with Legacy Code (2004), Michael Feathers defines legacy code as code without unit tests. I like the simplicity of this definition and, as someone who writes code using test-driven development, this definition works well for me.

J. B. Rainsberger elaborates: Legacy code is profitable code that we feel afraid to change. Fear of changing code arises from insufficient unit tests. Also, we can’t just throw away legacy code because it is profitable to the company paying us to maintain it.

For two months now, I’ve had the pleasure of working with legacy code in one of my projects. From the beginning, I noticed my coworkers’ fear of refactoring, concerned that something might break, and their frustrations with the code’s design. I could see why. As I explored the code, time was wasted by being led down paths that seemingly went in circles. At every turn, the code shamelessly violated the principle of least surprise. Nevertheless, I’m glad to be involved with this project for the experience. Encountering legacy code is inevitable, so I might as well get better at working with it.