Legacy Code Is Life

I have banned my team from using the term “legacy code”. The term has such pejorative connotations. Using the word “legacy” indicates it is out of fashion and should either be replaced or given to the offshore group to maintain.

The problem is code becomes legacy the instant you deploy it to production. This means that at any given point only .001% of the code base is actually “new”. Having a negative view of brown-field code means you have a negative view of the majority of your job as a developer. Everything you work on is some form of old…and getting older.

We forget that the reason money shows up in our bank every couple Friday’s is because this old code is actually generating value right now in production. The green-field code is simply hypothetical. Maybe it will be valuable and maybe it won’t. For sure it won’t until we finish it. If I have a choice between working on new code or having cash in my wallet I am choosing the cash every single time.

We also forget how many years of testing effort have gone into this old code base. Yes it may be ugly but that ugliness is sometimes the scars of many hard-fought battles. This battle hardened code comes with years of baked in QA testing and bug removal. By throwing away the code and starting over you are ignoring this historical value.

Also, by throwing away legacy code and just starting over you are showing your hubris by believing you can just rewrite it and 1) make it pretty 2) make it work right out of the box. Look at something you wrote even a month or two ago and ask yourself how good is it really. My guess is it is not as great as you expect your new code to be.

Personally I prefer working on old code. It gives me an opportunity to show how much of a better developer I am than the previous guy. “Look I have reduced line count by 50% and increased throughput by 100%.” Just saying. 🙂

(originally posted as a comment to a .NET Rocks podcast episode: Taking Over a Brownfield Application with Scott Ford)