Agile Zone is brought to you in partnership with:

I'm an Agile and Lean Strategist specialised in coaching and managing the transformation of IT departments, from startups to enterprise-scale organisations, to highly efficient, productive and energised environments. I also have experience as senior development manager and architecture governance in large enterprises, especially in the finance sector. Marco is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

Legacy code is not necessarily "ugly code"

  • submit to reddit

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.



Published at DZone with permission of Marco Tedone, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Ricky Clarkson replied on Mon, 2011/06/06 - 7:44am

So basically you're talking about unused code, or even if it's used, code whose effects are unused. That's a really easy problem to solve, delete the thing, whereas what Michael calls legacy code is more challenging.. how do you make fixes to it without breaking some other use of it that you might not even know about? I think you could do with reading more of his book, to get a feel for why he defines legacy code as he does.

Marco Tedone replied on Mon, 2011/06/06 - 3:32pm in response to: Ricky Clarkson

I wish it was as easy as removing the damn thing! The systems I'm referring to are still in production, but they not only lack in providing any business value; they represent a throw-away cost (that is it cannot be recovered) for the firm. These are, typically, systems that once provided business value but that with time became obsolete because of a new technology or a migration to a new architecture, or whatever...; the problem lies in the fact that there are still applications using (all or part of) them.

As for your question, automated testing is obviously the right direction to go to find out whether a change to the system will break some functionality. But, again, theory is sadly different from practice; if we are referring to "technical legacy systems" as I define them in my blog, then chances are that there will be a lack of tests anyway; how would one ensure that all the different scenarios can be regression-tested when a change is made? Even for systems originated from TDD a complete code coverage is often not a reality.

So Michael is giving an angle which defines "technical legacy systems" as systems without tests, but this does not mean that this is the correct definition nor that is the most effective one. I still think that business value drives the difference between "legacy" and "non-legacy".

Cloves Almeida replied on Mon, 2011/06/06 - 4:55pm

In simpler words, "legacy code" is code that gets in the way of the guys trying to make money out of this thing called business.

I consider that the old COBOL app doing the accounting is legacy code when it fails to deliver value. Ie. you have to jump through hoops in order to present a customers unpaid bills.

However,  say you have a nice COBOL dev team that can wrap the monster into nice HTTP services. In a much lower cost then replacing the whole thing. It's not legacy code.

Stephane Vaucher replied on Mon, 2011/06/06 - 8:33pm

I don't know what your backgrounds are, but please don't confuse terms. The term "Legacy" in legacy code comes from the fact that it is inherited that has business value and hence needs to be maintained (and not simply discarded). A large bank (e.g., Credit Suisse) might have >75M LOCS of legacy code (COBOL anyone?). This code runs the core of the business, but this is legacy code, not code with no value. I would recommend reading at least the introductory chapter of the book OO reengineering patterns: Otherwise, there are plenty of books on modernization that discuss legacy code.

Brian Reilly replied on Tue, 2011/06/07 - 1:37pm

Either the definition depends on your point of view or there should be two distinct terms with their own definitions. Rather than trying to redefine or expand the definition of legacy "code", I think you should say "legacy system", "legacy feature", etc. when talking about the business value. If you consider "code" to imply "technical", then "technical legacy code" is redundant and "business value legacy code" is an oxymoron.

That said, I'll confess that I (as a software developer) often say "legacy code" when I really mean "legacy system/feature", so it runs both ways. Now that I've been made to think about it, I'll be able to choose my words more carefully in the future. Thank you for that.

Lund Wolfe replied on Sat, 2011/06/11 - 6:37pm

To me "legacy" is a disparaging term implying a software or system that has been or should be replaced because it is now inadequate to it's purpose. It is ugly for technical reasons, directly or indirectly. Maybe it's slow or brittle or lacks needed new functionality, was originally poorly designed and implemented, too expensive to maintain/enhance, too hard to find developers, uses EndOfLifed technologies, frameworks, tools. It isn't a go forward solution.

If it wasn't useful we wouldn't be talking about it but it may be too expensive, too difficult, too risky to actually replace it so we just slap a pretty user interface or client facade on it and mostly leave the "legacy" system alone.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.