I was recently surprised when, at the question: "What is legacy code?" someone answered: "According to Michael Feathers, legacy code is any code without automated test." (Michael Feathers is, for those who don't know, the author of "Working effectively with Legacy Code").
I laugh when at questions like these people answer with quotes taken from a book. Don't get me wrong, I'm a technologist and a scientist, and to me books carry the same importance the sun carries for all the living things. We build our knowledge of the shoulders of our forefathers; but books should be used as tools to form our own opinions and not as containers for sentences to repeat mechanically. The fact that someone who wrote a book said that legacy code is any code without test doesn't make it true; it just makes it debatable, in fact I don't share one bit of Michael's opinion about legacy code.
So let's examine what I mean by legacy code.
I think there are two types of legacy code to consider, depending on whom you are talking to:
- Business Value Legacy Code
- Technical Legacy Code
The majority of people you will be talking to about this stuff will probably be technologists: in this case they will see "Technical Legacy Code" and answers will be along the line of:
- Legacy Code is code for which we haven't got the source code
- Legacy Code is code written by someone else who was the only one knowing how it worked and now this person has left.
- Legacy Code is code hard to understand and hard to maintain
- (You can put Michael's definition here if you want)
I bet some of you feels familiar with the definitions given above. Although legitimate, however, these answers represent just a minimal part of what should be considered legacy code. I have got a different opinion and with this post I'd like to draw the attention to what I think is the true meaning of the term "legacy code".
I see software in general as a tool to produce business value. Even if software is being written for research purposes, sooner or later someone will use it to make money. I would go as far as saying that if software does not deliver business value it's useless.
So to me "legacy code" is any software which does not deliver business value.
I see software from a business value point of view, not a technical point of view. What some consider legacy code (what I call technical legacy code) to me is just ugly code.
For instance, one could have cutting-edge software, whose API has been driven by TDD, with full test coverage, SOA architecture, clean code and the whole lot, but if such software does not deliver business I would still consider it as legacy.
Similarly, but on the opposite side, one could have ugly code which delivers an enormous business value (say, a legacy auto-trading system which generates 30% of the entire revenue of a firm). Such code might be against all coding standards, it might lack tests, the source code might not be available and maybe it's a nightmare to maintain, but would I consider it legacy code? Not at all; I would consider it very valuable code in need of heavy maintainance.
The technical view of legacy code tends to lead to the conclusion that "legacy code" should be replaced by more modern and shiny code. I'd say that "legacy code" should be replaced only if it does not deliver business value, otherwise it should be maintained and improved (from a technical point of view) when possible and left alone otherwise. If some software system does not deliver business value any more it should be disposed of as soon as possible, because every minute spent with the lights on represents cost for the firm and therefore a loss in competitive advantage.
Recent Comments