The Holy Java

Building the right thing, building it right, fast

What Do I Mean by a Legacy Code?

Posted by Jakub Holý on April 18, 2011

I’m using the term “legacy code” quite a lot, what do I mean by it? I like most the R. C. Martin’s description in his foreword to the Michael Feathers’ book Working Effectively with Legacy Code:

It conjures images of slogging through a murky swamp of tangled undergrowth with leaches beneath and stinging flies above. It conjures odors of murk, slime, stagnancy, and offal.

M. Feathers himself first repeates a common definition:

Legacy code is code that we’ve gotten from someone else.

He then acknowledges that in programmer’s mind the term legacy code means much more, something that has nothing to do with who wrote it:

If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don’t really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about making it better. It seems unworthy of your efforts.

In summary, legacy code is “used as a slang term for difficult-to-change code that we don’t understand.” But M. Feathers sumes up with a different definition he’s arrived to over the years:

To me, legacy code is simply code without tests.

He justifies his definition by explaining:

Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.

I pretty much agree with all the descriptions and definitions. We could expand them a lot, talk about dependencies, insufficient abstractions etc., but I think that though not very scientific, the descriptions express very well what we mean by legacy code and Mike provides us with a very simple and easily verifiable definition.

Update: To get a better grasp of what legacy code is, check the “best comments ever” – some of them express it pretty well.

About these ads

3 Responses to “What Do I Mean by a Legacy Code?”

  1. Tristan said

    Recent experience leads me to suggest a modification of Michael Feather’s definition to ‘code without tests you trust’. You can have tests, but if you don’t trust them to actually detect bad changes then they’re possibly worse than having no tests.
    If you cannot tell what the test is meant to be testing or if the tests are dependent on previous tests and break when you run them slightly differently then you cannot work with the codebase with any confidence.

  2. Good point! Perhaps Michael’s definition should actually read: the code is not legacy when it has tests that are not legacy either – but then we’re stuck for it doesn’t tell us what a legacy test is :-) Having tests indeed isn’t enough, they must be of a good quality too – including readability, maintainability etc.

  3. [...] to modify third party, closed-source classes and actually even JVM classes. Most of us work with legacy code and code for which we haven’t the source codes and inevitably we occasionally hit the [...]

Sorry, the comment form is closed at this time.

 
%d bloggers like this: