Writing Legacy Code

The stuff I'm currently working on was written in a week as an experiment in productivity... it ended up with over 300 bugs, though probably only 200 were in the code itself.

One week of coding, six months ago, who'd have thought that something that 'fresh' could be considered legacy - but it has certainly left a legacy behind.

My last posting at my last job had me writing legacy code. I was stuck in a code base that felt legacy and required legacy hacks to get it to do what you wanted. I should have thrown my toys out of the pram, but didn't have the kahunas. That code was 3 months old when I started hacking on it.

It seems that age doesn't have much to do with the definition of 'legacy code'. If this is the case, what is a good definition of legacy code...

Code without tests

Simplez, yes? If your code has no tests:

• You don't know what it should do
• You can't trust it does what it should do
• It's probably highly coupled
• etc, etc

This means that if you are writing against a codebase that has no tests, you are writing against a legacy codebase. If you are writing code and not writing tests, you are writing legacy code.

(Just for the record, your tests should be automated, and they should be at least unit tests. If you are doing otherwise, you are wasting a lot of time sitting there manually testing every codepath in your codebase)