Saturday, January 23, 2016

Legacy Code

The noblest pursuit of our weekdays

I make the “joke” that any given company is either currently fixing legacy code, or generating it. It’s not a great joke.

Whatever is rightly done, however humble, is noble.

— Henry Royce

Royce was the “Royce” of “Rolls-Royce”. I can’t speak to his nobility, but because he worked on a flour mill and was bone broke for a lot of his life I assume he was forced to be humble for at least some of it. Unlike hubris, laziness, and impatience, humility is not a developer virtue.

Originally, I was going to implore programmers to be humble, and to take on the work that no one else will do because it is wrongly perceived as being boring and painful. I don’t want to convince anyone of that though, because it’s hard and kind of pointless. Instead, I’m going to defend that maintaining legacy code is some of the best work a coder can do. Legacy can and should be valuable, interesting and healthy.

Another flaw in the human character is that everybody wants to build and nobody wants to do maintenance.

— Kurt Vonnegut

Greenfield projects used to fill me with a sense of freedom and opportunity, like a half-day Wednesday. These days, instead I have dread of all the utter bullshit work that I’ll definitely have to deal with. In my heart, I know that starting a new project has the following steps:

  1. Schedule a meeting
  2. Fight about framework choice
  3. Fight about the build system
  4. Fight about coding style guides
  5. Fight about everything forever
  6. Wake up in a cold sweat at 5am and dread going to work
  7. Write some code, maybe

Every new project immediately has baggage. Starting something new is hard because we start making all the important decisions ahead of time in the abstract, and this inevitably becomes a series of long meetings about nothing and/or profanities. All we can do it talk at length at how we can keep our non-existent codebase forever young.

Working on old code is chicken soup for the programmer soul, because it’s about programming. All the bike-shedding is done, all the yak-shaving is either done or irrelevant. There are bugs, there are features, and there is refactoring. There is some real honest, modest, humble work.

More importantly, 9/10 times if you’re working on legacy code, you’re fixing something that’s making company X something like Y dollars per Z, instead of wondering if having a digest cycle in your front-end framework is a good idea or not. I personally take solace in knowing that when I put time into a piece of code, the code will make enough money to pay my salary. It’s not such a bad thing to be invested enough in the success of a company to work on something less fun and be useful. I consider “workhorse programmer” a great compliment in an industry of hackers, painters, bespoke code, and so forth.

Also, I’m a cleaner. I clean things, almost perpetually. Refactoring crufty code bring me the same zen satisfaction as cleaning, and I get a lot more happiness mileage in cleaning up something that really needed cleaning than sitting there and trying to figure out how to keep something clean in its pristine condition forever. Put it this way: Sisyphus is a role model.

Lastly and most importantly, legacy is some of the dumbest and therefore hardest, most interesting, and most rewarding coding a programmer has access to. Programmers tend to pride themselves on being problem-solvers and puzzle-solvers and trying to make changes to an old, brittle, and confusing codebase is a seriously hard problem. It’s fiddly, sweaty, painful work that hurts my brain and makes me really work to find a solution.

I consider this to be one of the truest tests of my ability as a programmer, and finding a great solution to a problem under duress of bad architecture is the most satisfaction I get at work. Work like this forces me to really understand a codebase, with all its warts. It makes me learn new patterns, seek novel approaches, and think outside the box. I start to understand why certain architecture decisions are made. Changing old code is fascinating because it’s hard in a way completely different from why writing new code is hard.

Next time you’re looking at 2,000 lines of undocumented JavaScript nested sixteen levels deep, don’t flip a table. Volunteer. It’s a challenge and an opportunity to do some honest-to-goodness programming, the way it should be. Programming was never supposed to be easy, and it’s not. I just prefer my programming to be hard for better reasons, like context, constraints, obfuscation, logic. I’m tired of programming being hard because of arcane trivia, factoids, inconsistencies, unknown unknowns, untenable rate of change, distractions, stress, etc… “Legacy Code” should never have been a bad word, and it deserves better.