In defense of awful legacy code

Like most programmers, I hate working with legacy code. A reeking pile of unloved gunk, creaky frameworks and aged programming languages, and an absentee author long ago lost to the wilds; it’s a story as old as time.¹

However I find that attitudes often transgress into believing legacy code is low value; or that the original author deserves blame!

No!, I say. Legacy code has earned its keep.

It’s a well known axiom that smart engineers are lazy; we maintain code only because it’s worthwhile. If something is unused, it will be deleted. If it’s useful but excessively costly, it will be rewritten. Every day, legacy code validates its worth; its existence outweighs the real and emotional costs of maintaining it.²

An old house need not be torn down. Maybe it needs a new coat of paint, some caulking around the floorboards, or even a gut renovation. These are tiresome chores, especially when you compare to your friends in gleaming luxury condos with grills on roof deck patios. But a home is a home, so long as you keep it.

We don’t attribute the decrepitude of the aging house and its antiquated construction to the original framers. So too it’s usually senseless to throw old authors under the bus for poor design choices. Look I get it, they probably are poor design decisions now. But they were decided with the needs and understanding and resources of then. What was built worked well enough to get us to where we are.

Case in point: git. It’s got confusing commands and doesn’t scale to large repositories. Yet any programmer worth their salt uses it on a daily basis. It’s too valuable to give up!

Another example: JavaScript. Famously created in 10 days, it’s now one of the most widely used programming languages.³

Responsibility for legacy code lies not with the dead but the living. You are both the problem and the solution! Software engineering can be a difficult trade, and working effectively with legacy code is a technical skill.

There’s a rant here about our collective obsession with frameworks. Frameworks are monoliths! While it’s cool to have React/Svelte/Vue components, they don’t even work across the same ecosystem of HTML/CSS/JavaScript. They are uncompromisingly dialectal.⁴ Maybe the problem is not that our old Rails codebase doesn’t support React components, but that our new technologies don’t fit into old codebases.⁵

Having spilt all this digital ink, it’s undeniable there’s an unburdened joy working with a well designed and modern codebase. Enjoy it while it lasts!