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'.
Regardless of the actual reason the end result is the same: Legacy software is software you no longer wish to maintain
> Legacy software is software you no longer wish to maintain who are we referring as 'you' here? the dev or the product owner?
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.
nice definition! btw, I'm loving the BDD way of structuring my unit test. Look at this example: https://morten.lyhr.dk/2008/07/doing-bdd-with-rhino-mocks-aaa-syntax.html
this is cool