Legacy software

I recently heard an interesting podcast about the definition of legacy software. i agree that the attribute that we put onto a piece of software and marked one as legacy is a debatable one. The definition is subjective and comes from personal values.

Is a piece of software becomes legacy as newer technology arise?
Is a piece of software becomes legacy as the authors moved on from the team?
Is a piece of software becomes legacy as we learn better technique and practices.

Those values we often use as yard sticks to which then we apply the 'legacy' attribute to a piece of software. Which soon after, we often look back at it as a mental burden, a personal anchor to our creativity.

From a state thinking that a piece of code is a masterpiece, to 'I could've done that better', which finally lead to 'This is something that I can't work with'.

  1. Code Monkeh says:

    Regardless of the actual reason the end result is the same: Legacy software is software you no longer wish to maintain

  2. ronaldwidha says:

    > Legacy software is software you no longer wish to maintain who are we referring as 'you' here? the dev or the product owner?

  3. Hery Hope says:

    quoted from the book: working with legacy code. legacy code is a piece of software that doesn't have (lack of) unit test and code coverage.

  4. ronaldwidha says:

    nice definition! btw, I'm loving the BDD way of structuring my unit test. Look at this example: http://morten.lyhr.dk/2008/07/doing-bdd-with-rhino-mocks-aaa-syntax.html

  5. web development services says:

    this is cool