Legacy code is good for your business culture

Six years. That’s how old our little software company is this month.

Like most any company that’s no longer in startup mode, but has matriculated to a business that has lots-of-work-to-do and plenty-of-mouths-to-feed, ours has long since developed some business debt.

By this, I don’t mean anything monetary — we’re profitable, and have been since (nearly) day one. But, in many other areas of the business, we’ve developed a few nasty barnacles under our ship.

Here’s an example. Six years in, we still maintain codebases that are, now, nearing five years old. Five years in the web industry is a generation — Ken Burns could produce a whole documentary about the changes in our toolsets and standards just between 2007 and 2012. Our .NET 2.0 web forms app using Anthem on top of a hand-rolled data-access layer just doesn’t feel as good in our IDE anymore. They no longer look particularly fantastic on the mobile devices that — well — didn’t exist, when they were born.

Programming debt happens. What now?

As our business gets older, an increasing proportion of our codebase will be outdated. That’s the simple outcome of having more work behind you than you have currently on your plate. And, as more developers roll in and out of supporting these projects, the codebase gradually starts getting less elegant. In addition, that pristine code we think we’re writing right now will one day be legacy, too.

Legacy code sucks. And, for awhile, I cringed at the thought that, one day, in say 2017, we’ll simply have too much old, older, and oldest stuff lying around. We’d need an entire department of developers and designers stuck in various technological micro-eras to make sure we can maintain these old relics.

Always look at the bright side of…legacy

I’ve had a change of heart recently. Not a complete change of heart, but, I used to think legacy code was a severe crutch. Lately, I’ve discovered a very slight silver lining appearing from the slowly growing stinkheap of old code.

Legacy code really helps you hire the right programmers. It provides a quick way to see how well a new programmer can adapt to our company culture. While we continue to iterate every facet of our development process, bringing new developers on-board and starting them out working with legacy code helps highlight a few ways they approach working.

How quick can a new programmer learn a system?

When you break it down, diving into a legacy codebase isn’t all that different from learning a fancy new framework.

You typically start by making a few small tweaks, digesting just what you need to know, when you need to know it. After a few coding sessions, the old system starts to unfold on its own because you’ve had success modifying so many small parts of it. By the end of the week, you’re probably comfortable enough to implement a completely new feature abiding by the general approach of the old framework.

From that standpoint, ramping up to a legacy codebase isn’t far from the approach I’d take with learning a completely new framework. I’d probably start with a pre-written example, then, gain some small wins by successfully tweaking it. The new system will naturally unfold as I continue to make small tweaks. Pretty soon, I should be able to add small, then larger, features.

If a new developer can pick up a legacy project quickly, it’s a safe bet they’re good at learning any type of new thing. A good legacy code maintainer is probably also a good learner, in general.

How pragmatic is your new programmer?

The natural tendency of any programmer is to write perfect code. Ugly old code induces that natural fight-or-flight urge in all of us. Some of us would rather never touch it. Others of us want to rewrite everything from the ground up.

In our business, we have the luxury of neither. Old projects still work. People still use them. So we can’t just disregard them altogether. We also don’t have the time or budget for mass overhauls. Try telling your client that, for just $150,000, you can take your piece of software and essentially give you the same thing back, only everything you don’t care about has been updated! It doesn’t work.

There is a happy medium though. If you can budget a small padding of extra time for a newbie to work through legacy code, let them decide how much they want to refactor. It may just be small, teeny little bits of extraction and abstraction. But, giving them that liberty with constraints puts pragmatic decisions on them. I like seeing how much or how little they decide to change an existing codebase given only so much time to do it, and talk to them about how they came to those conclusions.

A capable programmer will be able to make and justify those decisions accordingly.

What’s your new programmer’s temperament like?

After years of interviews, I’ve deduced this: It’s very hard to really tell a programmer’s attitude just by having philosophical discussions and quizzing them over phone, or even in person. Interviews are great ways of seeing what a programmer knows, but poor ways of exposing their true in-the-heat-of-the-moment attitudes.

Legacy code can be maddening. It’s probably put on a bunch of fat and atrophied in other places. Parts of the code might make absolutely no sense, and you’re wondering whether it’s you or the code. It’s no fun to look at stale code supporting old projects.

How does your new programmer handle the imperfections of this system? Do they sit idly by when they should be asking question? Do they whine, curse, or complain? Or, do they handle it with calm perseverance, with Zen-like tolerance? How a programmer reacts to your oldest, (and very likely) worst codebases is a good indicator of attitude and temperament. It’s a good insight into how quickly (or slowly) they ask for help. In the end, it’s a good peek into how they’ll work with the rest of your development team.

If, after the first couple of days in LegacyLand, your newbie is throwing fits, re-writing systems without dissemintating any of that knowledge, and looking at version control logs to see whom to yell at — you’ve probably hired the wrong person.

Embrace your legacy

And so, as our company grows, I’ve learned to embrace the legacy-ness. It’s not only a sign of how far we’ve come, but also a way we can initiate new developers. And, if you can get your newest devs on your oldest projects, it’s an invaluable way of quickly evaluating your new talent.