Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We've all done it, we've labelled some code (often stuff we've inherited) as "legacy"? But it's still used in the production systems - so is it really legacy? And what makes it legacy? Should we shy away from this unwarranted labelling of perfectly functioning code; where the labelling is a pure convinience which allows us to push through new stuff and keep upper management nice and happy?


Summary of answers

Looking through the answers I see four general themes. Here is as I see the breakdown:

  1. Any code that has been delivered: 6
  2. Dead systems: 2.5
  3. No unit tests: 2
  4. Developers are not around: 1.5
share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

closed as too broad by gnat, Bart van Ingen Schenau, Martijn Pieters, MichaelT, Dan Pichelman Feb 24 at 19:06

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
1  
It's legacy code as soon as it's delivered and is working. –  Martin Beckett Jul 18 '11 at 21:51
18  
it's legacy code if you didn't write it ;-) –  Steven A. Lowe Jul 18 '11 at 23:25
18  
It's legacy code if everyone that wrote it is retired or dead, and if those that continue to maintain it wish they were. Otherwise, it's just called the existing code base. –  Mark Mann Jul 19 '11 at 5:42
3  
@StevenA.Lowe, given enough time, it's legacy code even if I did write it. –  Kyralessa Dec 26 '13 at 18:43

10 Answers 10

up vote 27 down vote accepted

I'm rather partial to Wikipedia's summary myself:

A legacy system is an old method, technology, computer system, or application program that continues to be used, typically because it still functions for the users' needs, even though newer technology or more efficient methods of performing a task are now available.

A lot of what other people are describing in their answers are reasons why code becomes "legacy". But the essential question itself is this:

But it's still used in the production systems - so is it really legacy? And what makes it legacy?

The fact that it is still used in production is precisely what makes it legacy. If the code does not work properly, or is no longer used in production, then that code is "broken" or "retired", respectively. Legacy means that it is still in use and works fine, but incorporates designs or techniques that are no longer in common use.

Any code or system that you either (a) would like to upgrade/update, but can't, or (b) are still in the middle of upgrading, is a legacy system. This doesn't mean refactoring or general code cleanup, it means significant changes to the design, possibly using a new framework or even a new platform.

There are any number of reasons why systems or code might become legacy:

  • Lack of regular maintenance or software rot. Clearly if the application is not maintained regularly, it will not keep pace with major changes in the software world. This might be due to simple neglect or it might be a deliberate choices based on business priorities or budgetary constraints.

  • Lack of testing. Another answer references a popular author's hyperbolic claim of any code not covered by tests being legacy code. This really isn't an accurate definition but it is a possible root cause; without good tests (automated or manual), developers become timid and afraid to make major changes because they worry about breaking something, thus leading the "software rot" above.

  • Rev-locking, an often-overlooked factor which is particularly insidious in projects using large open-source libraries or frameworks (although I've seen it happen with commercial tools as well). Often there will be major customization done to the framework/library, making an upgrade prohibitively difficult or expensive. Thus the system becomes legacy because it runs on an older (and possibly no-longer-supported) platform.

  • The source code is no longer available, meaning that the system can only ever be added to, never changed. Since these systems have to be rewritten in order to upgrade - as opposed to incrementally/iteratively revised - many companies won't bother.

Anything that slows or stops updates to a code base can lead to that code base becoming legacy.

Now the separate, unstated-but-implied question is, what's wrong with legacy code? It's often used as a pejorative term, hence the question:

Should we shy away from this unwarranted labelling of perfectly functioning code?

And the answer is no, we shouldn't; the labeling is warranted and the term itself clearly implies functioning code. The point is not that it's function, but how it's functioning.

In some cases there's nothing wrong with legacy code. It's not a bad word. Legacy code/systems are not Evil. They've just collected some dust - sometimes a little, sometimes a lot.

Legacy becomes obsolete when the system can no longer serve (all of) the client's needs. That label is one that we need to be careful of. Otherwise, it's simply a cost/benefit equation; if the cost of upgrading would be lower than the cost of its benefits (including lower future maintenance costs) then upgrade, otherwise, leave it alone. No need to spit out the word "legacy" in the same tone you normally reserve for "tax audit". It's a perfectly OK situation to be in.

share|improve this answer
    
That said, tax audit should be a perfectly OK situation to be in too. –  Florian Margaine Feb 24 at 15:11

Usually it means it's written in a language, or based on a system that you don't typically do new development in.

For example, most places don't write new programs in Cobol. However, a large part of their business may run on apps written in Cobol. Hence, those apps, are labelled "Legacy".

share|improve this answer
    
I agree with this answer most. Legacy is more about being stuck on an obsolete platform than being annoying (yet modern) code that you don't want to support. Legacy code is often quite good (otherwise no one would care if you left it behind!) but it's usually wedded to obsolescent hardware and antiquated languages/libraries/databases/etc. –  Satanicpuppy Jul 18 '11 at 21:40
3  
@Satanicpuppy: I simply can't agree -- I've dealt with (for one example) some Java that was definitely not tied to any particular hardware, library or database -- but was as "legacy" as it gets (and was being rewritten in Java, so the language wasn't the issue either). I've also dealt with some code that was tied to specific hardware, but was still only barely edging into the "legacy" category. –  Jerry Coffin Jul 18 '11 at 21:59
4  
@jerry: So what made it legacy? Legacy isn't a synonym for "bad". –  Satanicpuppy Jul 18 '11 at 22:03
1  
In the case I'm thinking of, it was a fairly large distributed system (built around BEA Tuxedo). The design seemed based on text book scenarios that are intended to teach about synchronization by maximizing the number of times/places synchronization is needed. That (sort of) makes sense for a text book, but it's horrible for real designs. It was large enough that even architecting a replacement was a multi-year project. The replacement had to be done in phases with no down time, because the system was utterly necessary to the business. –  Jerry Coffin Jul 18 '11 at 22:17
1  
@Cawas: It appears to me that @Chad's answer would apply when/if the new system was being done in a different language, or using different hardware, etc. This was being re-developed still using Java, still using Tuxedo, etc. I don't see it as applying. –  Jerry Coffin Jul 19 '11 at 4:26

Legacy means any code you'd rather replace than work with. Given the attitude of most programmers toward most existing code, that usually includes nearly everything except what you're actively writing at the moment (and on a large project where you have to code to a frozen design, even what you're writing at the moment can be included as well).

  1. The emphasis "rather" is intended to convey that legacy code also means you're stuck working with it even though you'd rather not. I'm not sure the emphasis was sufficient though. Reasons for that can vary. Some really are just too big and complex to replace. Others are interfaces to other systems. Still others are driven by politics and personalities (for example, the code is horrible, but the booth babe was amazing).
  2. Another point I may not have emphasized sufficiently is that while code quality can be a factor, it's rarely (if ever) the sole factor -- and often not even a particularly important one.
  3. I think the people pushing unit tests as the sole determining factor are like the guy looking under the streetlight for the earring his wife dropped a block away. The light may be better, but you're still looking in the wrong place. Think before you drink the Kool-Aid.
  4. (A corollary to 3.) It seems to me that some people are talking more about how they wish things were than how they really are. If John Conways' Game of Life for an Apple IIc Plus isn't legacy, it's because it's sufficiently small and simple that it's easy to re-implement from the ground up. The most perfect unit testing ever written won't change that a single iota.

The last point does lead to two other points I think are often true.

First, code is often retained as legacy, even when it really shouldn't be. Higher level managers generally assume re-implementing a system will cost as much or more than the initial implementation did, which is rarely true.

Second, unit tests are a two-edged sword. They make it all too easy to think that localized changes in the implementation are what really matter. To make significant improvements in a larger system, you frequently (usually?) have to change enough of the overall design that many (if not most) of the unit tests become irrelevant. Unfortunately, the presence of unit tests and the attitude they engender can make it all too easy to ignore the changes that are really necessary.

Perhaps an example of that would help: let's assume a program has a UI library with great unit testing, and several programs that use that library. Somebody in upper management becomes convinced that "web enabled" is important (and, just for the sake of argument, let's assume that in this case he's actually right about that). After careful review, the middle managers find that their current unit testing is sufficient that they can change from a user interface displayed via the local operating system's windowing capability to being displayed remotely via HTML/CSS/AJAX, while retaining all the original input validation.

That's great isn't it? It shows how useful unit testing can be. We've swapped out the entire implementation of the whole UI, but ensured that the look, feel, and functionality remains virtually consistent, and all user input is validated to ensure data integrity. Unit testing has saved the day!

Or not! That great, highly flexible, carefully unit tested UI library has helped blind everybody involved to the fact that for this program in its market with its users, a web-based UI is entirely the wrong thing to work on at all. What's really needed is a web service with a RESTful interface, and absolute no UI of its own at all.

Now, it's certainly true that unit testing does not, in and of itself remove people's ability to understand their market or realize that's really needed. At the same time, the old line about hammers and nails virtually leaps to mind. It can be even worse when you not only have a hammer, but have a lot of experience with this hammer, and know it's a really a high quality hammer that works incredibly well in many different situations. The very fact that it's so good at so many things in so many situations makes it even harder to recognize when it's entirely the wrong tool for the job at hand.

share|improve this answer
2  
See, now I don't know whether to mark this up or not, sadly this is true, but I wonder if it's an attitude we need to get away from... –  Nim Jul 19 '11 at 8:11
    
+1. I was about to answer something to the same extent. Legacy is any code that is used rather than actively maintained. –  Denis de Bernardy Jul 19 '11 at 8:11
    
@Nim: I don't think it's an attitude that "we" need to get away from. It's a mere statement of the obvious. :-) Think about it for a moment and wonder what you'd consider to be legacy code if you were to arrive in a new environment; it'll be everything except the new & cool stuff that is being actively developed. –  Denis de Bernardy Jul 19 '11 at 8:14
    
@Jerry, so you don't like unit tests then? ;) –  Nim Jul 19 '11 at 22:31
    
@Nim: Not so -- I think they're useful, but far short of the panacea as which they're frequently portrayed. –  Jerry Coffin Jul 20 '11 at 1:19

Legacy code is usually orphaned in some way. The lead developer, the only guy who understood it, got hit by a bus, and his notes were written in his native Ukrainian dialect, which is now a dead language. Or, alternately, anything written in Visual Basic 6.0.

I work on legacy code all the time. I would say the characteristics are:

  • It cannot be extended without massive effort
  • It cannot easily be migrated to new hardware
  • It is too business critical to be easily replaced

If it doesn't have those characteristics, then it's probably not legacy. If you don't like your predecessors' Perl scripts, I sympathize, but I don't think it's legacy. I recently modernized some 15-year-old Perl script that was wedded to an obsolete Sybase database. That was cake compared to making even the smallest change to our god-awful COBOL accounting system.

share|improve this answer
    
Scary, our lead developer is Ukrainian too... haha... I agree with the middle bit of your answer, the first point - not so much - I think it depends on how your dev team is setup. –  Nim Jul 19 '11 at 8:14
1  
lol, you have probably managed to offend (bus drivers, the Ukrainian language, and VB6 devs) all in one paragraph. But damn did I laugh :) –  Darknight Jul 19 '11 at 8:32
1  
+1 for anything written in VB6 –  Peter Jul 19 '11 at 19:45

In his book, Working Effectively with Legacy Code, Michael Feathers defines legacy code as code that is not covered with unit tests. That's one definition, which I agree with. I also see legacy code as old, yet still usable.

share|improve this answer
23  
This strikes me as a case of attempting to define "anything that doesn't follow my chosen methodology" as "legacy". It's nothing more or less than a cheap debating tactic, basically just taking Godwin's law and softening the language (barely) enough to keep readers from instantly recognizing that it's nothing more than an unsupported (and often insupportable) attack any everybody who doesn't follow his preferences. –  Jerry Coffin Jul 18 '11 at 21:54
3  
@Jerry: I agree with Feather's definition. Code without Unit-Tests is an horror to work with. If you decide you want to refactor some parts of it so it gets easier to reason about it, forget it! you may be introducing bugs and the code probably the way it is is untestable, anyway! I find Feather's definition to be unconventional, yet he is someone that made a living working with legacy code. –  devoured elysium Jul 18 '11 at 21:58
9  
@devoured: unit tests are not an accurate litmus test for ability to work with code. I've dealt with code that lacked unit tests, but was a breeze -- and with code that had unit tests, and was still a nightmare. Ultimately, unit tests don't solve anything in themselves. Unit tests for a design in which (for example) the division into units was poorly done can still be utterly worthless, and the whole design (including tests) needs to be thrown out an replaced to produce anything useful. –  Jerry Coffin Jul 18 '11 at 22:07
5  
I agree with Jerry's comments. The absence of unit tests is just one of a bunch of code smells which might (or might not) indicate badness. –  smci Jul 18 '11 at 22:47
3  
I again agree with Feather's definition as well as devoured. Absence of unit test is everything as this mean that even the most beautiful code snippet is missing it's specifications. Unit tests are 51% of the documentation and 100% of the specification of the code. A code missing most of it's it's documentation and all of it's specification should rightly be classified as legacy. –  user14336 Jul 19 '11 at 9:22

Technically, legacy is any code that is ready written. So as soon as it is in production, it's legacy. Because there is already value there, you can't just throw it out... You have to deal with it.

It's "before your time" but "still your headache".

share|improve this answer

Legacy code is code that's only remains in the code base because a lot of things would stop working otherwise. In other words: it's only reason for being is backward compatibility.

You'd rather change it or even throw it away, but you can't because you will break all code relying on it (which might be code that you cannot adapt accordingly). Therefore you have to keep it (and sometimes even maintain it), but you wish all new code not to be written against it.

An example are deprecated methods of a library's API. They're still there, so that if whoever updates the library can still build his project, but they are marked as deprecated and you compiler should give you a warning.

Another example are all those weird tricks Microsoft does to make programs run that were written for versions of their OS they have completely deprecated. The pinnacle of this being:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
-- Joel on Software

share|improve this answer

Legacy entails inheritance. Legacy code is simply code that you inherit from the past. It's legacy code even if you wrote it yourself before!

All other considerations descend basically from the fact that you did not write it specifically for your current project. It's not necessarily a bad thing per se.

share|improve this answer

My opinion is that what is considered legacy code is dependent on multiple things, and the tag 'legacy' is probably organisation-specific.

If the hardware/OS it runs on are old and have been discontinued by the vendor - strike 1.

If it's more work to try to fix it, than to rewrite it, for any reason because

  • the original developer/s are gone
  • the program is badly written
  • it can be done better on a newer platform, and is still worth it to the company

to do so

  • original source is no longer available and/or missing pieces

Strike 2.

A merging of multiple organisations into one - Strike 3 - one side is probably going to get tagged as legacy.

Is there a better, cheaper alternative sold as a third-party application and/or service - strike 4.

Is the organisation something like a hospital or a school district where consistency is valued over new tech when it comes to daily operations? It'll take longer for an application to be considered legacy compared to the same application in a commercial/competitive organisation.

If the company is a small development company that keeps enhancing/supporting the application to do what the customers need, is it considered legacy code, or just 'old' code. I know a company named Mc2Ok - they developed the software on what seems to have been Windows 3.1, and have just kept carrying it forward. It still very much has a Windows 3.1 look and feel, but they added a web interface to it as well. It is a two-man developer company (my guess), and I'd say when they quit working on it, then it'll be considered legacy, and time to migrate a year or two after if using it. But that could be another 10 or more years.

Sometimes when management changes, it can change in waves that have many trickle effects... Depending on the clout of the new management, it can render many applications legacy that might otherwise be just fine.

Each organisation, I believe, has to define what 'legacy code' means to them. I used to look through The Sunday Times classifieds every week to see what organisations were looking for. That used to be my barometer for what was no longer relevant (that is, legacy). Well, The Sunday Times is no longer relevant :-) And we can generalize that COBOL is legacy, ASP Classic is legacy, etc... But I believe each organisation has to decide when an application is considered legacy for it.

share|improve this answer
    
+1, nice answer - better to consider something legacy from the perspective of the org... –  Nim Jul 19 '11 at 9:06

Code is legacy when one is afraid to change it, because he may break it. It is even more painful when the whole system may be knealed by changes to that code.

This is why I also agree with Michael Feathers' definition. Code that has good unit tests can be changed fearlessly.

I also think that legacy code has nothing to do with how old it is. One can write legacy code from the start.

share|improve this answer

protected by Yannis Rizos Feb 23 at 15:46

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.