[ACCEPTED]-What makes code legacy?-legacy

By using hardware, software, APIs, languages, technologies 5 or features that are either no longer supported 4 or have been superceded, typically combined 3 with little to no possibility of ever replacing 2 that code, instead using it til it or the 1 system dies.

What is it that makes code, legacy code?

As 4 with plain legacy, when the author is dead 3 or missing, you as a heir get all or some 2 of his code.

You shed some tears and try 1 to figure out what to do with all this rubbish.

Michael Feathers has an interesting definition 3 in his book Working Effectively with Legacy 2 Code. According to him legacy code is code 1 without automated tests.

It is a very general (and oft abused term) but 30 any of the following would be legitimate 29 reasons to call an app legacy:

1. The code base 28 is based on a language/platform which is 27 entirely unsupported by the manufacturer 26 of the original product (often said manufacturer 25 has gone out of business).

2. (really 1a) The 24 code base or platform on which it is built 23 is so old that getting qualified or experienced 22 developers for the system is both hard and 21 expensive.

3. The application supports some 20 aspect of the business which is no longer 19 actively grown and for which alterations 18 are extremely rare, normally to fix it if 17 something entirely unexpected changes around 16 it (the canonical example being the Y2K 15 issue) or if some regulation/external pressure 14 forces it. Since both reasons are pressing 13 and normally unavoidable but no significant 12 development has occurred on the project 11 it is likely that those people assigned 10 to deal with this will be unfamiliar with 9 the system (and it's accumulated behaviours 8 and intricacies). In these cases this would 7 often be reason to increase the perceived 6 and planned for risk associated with the 5 project.

4. The system has/or is being replaced 4 with another. As such the system may be 3 used for much less than originally intended, or 2 perhaps only as a means of viewing historical 1 data.

Legacy generally refers to code that is 7 no longer being developed - meaning that 6 if you use it, you have to use it on its 5 original terms - you cannot just edit it 4 to support the way the world looks today. For 3 example, legacy code has to run on hardware 2 that may not exist today - or is no longer 1 supported.

According to Michael Feathers, the author 20 of the excellent Working Effectively with Legacy Code, legacy code is a code 19 which has no tests. When there is no way 18 to know what breaks when this code changes.

The 17 main thing that distinguishes legacy code 16 from non-legacy code is tests, or rather 15 a lack of tests. We can get a sense of 14 this with a little thought experiment: how 13 easy would it be to modify your code base 12 if it could bite back, if it could tell 11 you when you made a mistake? It would 10 be pretty easy, wouldn't it? Most of the fear 9 involved in making changes to large code 8 bases is fear of introducing subtle bugs; fear 7 of changing things inadvertently. With tests, you 6 can make things better with impunity. To 5 me, the difference is so critical, it 4 overwhelms any other distinction. With 3 tests, you can make things better. Without 2 them, you just don’t know whether things 1 are getting better or worse.

Nobody is gonna read this, but I feel the 1 other answers don't get it quite right:

1. It has value, if it wasn't useful it would've been thrown away long ago
2. Its hard to reason about because either of
   1. Lack of documentation,
   2. Original author cannot be found or forgot (yes 2 months later your code can be legacy code too!!),
   3. Lack of tests or typesystem
   4. Doesn't follow modern practices (ie no context to hold on too)
3. There is a requirement to change or extend it. If there isn't a requirement to change it, it isn't legacy code since nobody cares about it. It does its thing and there is nobody around to call it legacy code.

A colleague once told me that legacy code 6 was any code that you hadn't written yourself.

Arguably, it's 5 just a pejorative term for code that we 4 don't like any more for whatever reason 3 (typically because it's not cool or fashionable 2 but it works).

The TDD brigade might suggest 1 that any code without tests is legacy code.

Legacy code is source code that relates to a no-longer 2 supported or manufactured operating system 1 or other computer technology.

http://en.wikipedia.org/wiki/Legacy_code

"Legacy code is source code that relates 2 to a no-longer supported or manufactured 1 "

Any code with support (or documentation) missing. Be 1 it:

• inline comments
• technical documentation
• spoken documentation (the person who wrote it)
• unit tests documenting the workings of the code

For me legacy code is code that was written 5 prior to some paradigm shift. It may still 4 be very much in use but it is in the process 3 of being refactored to bring it into line.
e.g. Old 2 procedural code hanging around in an otherwise 1 OO system.

Code (or anything else, really) becomes 3 "legacy" when it has been replaced by something 2 newer/better, and yet despite this it's 1 still used and kept alive "in the wild".

Preserving legacy code is not so much an 6 academic ideal as it is keeping code that 5 works, no matter how poorly. In many conservative 4 enterprise situations, that would be considered 3 more practical than throwing it away and 2 starting again from scratch. Better the 1 devil you know...

Legacy code is code that is painful/expensive 30 to keep current with changing requirements.

There 29 are two ways that this can happen:

1. The code is unsuitable for change
2. The semantics of the code have been swapped out to silicon

1) is 28 the easier of the two to recognize. It is 27 software that has fundamental limits making 26 it unable to keep up with the ecosystem 25 around it. For example, a system built around 24 O(n^2) algorithm won't scale beyond a certain 23 point and must be re-written if requirements 22 move in that direction. Another example 21 is code using libraries that are not supported 20 on the latest OS versions.

2) Is harder to 19 recognize, but all code of this kind shares 18 the characteristic that people are afraid 17 to change it. This could be because it was 16 badly written/documented to begin with, because 15 it is untested, or because it is non-trivial 14 and the original authors who understood 13 it left the team.

The ASCII/Unicode chars 12 that comprise living code have semantic 11 meaning, the "why's", "what's" and to some 10 degree the "how's", in the minds of people 9 associated with it. Legacy code is either 8 un-owned or the owners do not have meaning 7 associated with large portions of it. Once 6 this happens (and it could happen the next 5 day with really poorly-written code), to 4 change this code, someone must learn it 3 and understand it. This process is a significant 2 fraction of the time it takes to write it 1 in the first place.

The day you're afraid to refactor your code 1 is the day when your code has become legacy.

I consider code "legacy" if any or all of 22 the following conditions apply:

• It was written using a language or methodology that is a generation behind current standards
• The code is a complete mess with no planning or design behind it
• It is written in outdated languages and in an outdated, non object-oriented style
• It is difficult to find developers who know the language because it is so old

Unlike some 21 of the other opinions here, I've seen plenty 20 of modern applications that work decently 19 without unit tests. Unit testing still has 18 not caught on with everyone. Perhaps ten 17 years from now the next generation of programmers 16 will look at our current applications and 15 consider them "legacy" for not containing 14 unit tests, just as I consider non object-oriented 13 applications to be legacy.

If few changes 12 need to be made to a legacy codebase, it's 11 better to simply leave it as-is and go with 10 the flow. If the application needs drastic 9 functionality changes, a GUI overhaul, and/or 8 you can't find anyone who knows the programming 7 language, it's time to throw away and start 6 over. A word of warning, however: rewriting 5 from scratch can be very time-consuming, and 4 it's difficult to know if you've replicated 3 all functionality. You'll probably want 2 to have test cases and unit tests written 1 for the legacy application and the new application.

Quite honestly legacy code is any code, framework, api, of 11 other software construct thta's not "cool" anymore. For 10 example COBOL is unanimously regarded as 9 legacy while APL is not. Now one can also 8 make the case that COBOL is consideed legacy 7 and APL not because it has about 1m times 6 the install base as APL. However, if you 5 say that you need to work on APL code the 4 reply would not be "oh no, that legacy stuff" but 3 rather "oh my god, guess you won't be doing 2 anything for the next century" see the 1 difference?

This is a general term thrown around quite 6 often (and quite generically) in the software 5 ecosystem.

Well, I like to think of legacy 4 code as inherited code. This is simply code that was written 3 in the past. In most cases, legacy code 2 do not follow new/current practices and 1 is often considered archaic.