[This was originally posted at
http://timstall.dotnetdevelopersjournal.com/how_old_is_legacy_code.htm]
Most developers like to write their own, new exciting code. However, the reality is that often you deal not with new code, but rather existing "legacy" code. How old does code need to be before it's considered legacy? Some people say just a few minutes - you type code, you go get a snack, you come back, it's now legacy code. I don't think this is fully practical. Rather, here are some general guidelines that I personally find helpful in deciding if something is legacy code or not:
- Is the original author no longer available? - Nothing makes code seem more legacy than when you no longer know who wrote it.
- Is the code already in production? - Once code is in production, there is a definite contract and expectation that you need to adhere to.
- Is the code to big to just throw away? - If the code is small enough that you can just throw it out and restart, it's not really legacy yet.
- If it's your own code, have you forgotten it? - Even if you wrote the code yourself, if you've done several things since and therefore no longer remember it, it seems more legacy.
In summary, legacy code implies it's already in production, or it's too big to throw away, or you have to re-learn what the code does (because either the original author is gone, or you can't remember it). Throw-away code that you wrote five minutes ago which isn't used by anyone else isn't really legacy yet.