Our boss asked us developers for our preferred developer books and we submitted our wishlists, weeks later they ordered all 20+ of them, whoa! all the books that we wished for, nice!  I'm currently browsing through Michael Feathers' Working Effectively with Legacy Code.

So what is legacy code?  I overheard an officemate that one of our biggest projects was the best legacy code that he was assigned to, I thought to myself, is it really considered legacy code?  I've been a part of it in it's early stages so it kind of hurt me too since the adjective has a negative connotation.

Quoting the Preface from the book:

If you are at all like me, you think of tangled, unintelligible structure, code that you have to change but don't really understand. You think of sleepless nights trying to add in features that should be easy to add, and you think of demoralization, the sense that everyone on the team is so sick of a code base that it seems beyond care, the sort of code that you just wish would die. Part of you feels bad for even thinking about making it better. It seems unworthy of your efforts.

Ouch! Been there done that, cursed all the way (ako pa!).  But he later gave his own definition of legacy code as simply code without tests. 

Code without tests is bad code. It doesn't matter how well written it is; it doesn't matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don't know if our code is getting better or worse.

Truly agree!  But i disagree when my officemate said that "the project" is a legacy code.  It is the only .NET project here with enough unit/integration tests compared to all the others.  Maybe some are not well written tests but it's better than nothing.