The Half Life of Code

Code does not decay. Once written, barring a catastrophic hardware failure, code will continue to function exactly as written. But don’t try to tell Eddie that. Several years ago, my company did a project for Eddie (not his real name.) Eddie wanted a web app built to handle an aspect of his business that he had previously done over email. Once the project was completed, I mentioned the possibility of a maintenance agreement. Eddie looked at me like I was a Radio Shack employee pushing the “extended warranty.” Eddie was too smart for maintenance agreements. “Your website broke. You need to fix it.” This was Eddie calling, years after the project was completed. As he explained it, the web app had been breaking down for the past six months, but now it wasn’t working at all. It goes without saying that Eddie believed I should complete the “repairs” free of charge because the product I had sold him broke. Where to start? Let’s start with Ernest Rutherford. Rutherford was (arguably) the greatest physicist of his generation. Among many other accomplishments, Rutherford discovered that radioactive elements lose half their mass at a given rate – a rate he called the “half life period.” After one of these half life periods had elapsed, the radioactive element would be 50% of its original size. After two of these periods, it would be 25%. After three, 12.5%. And so on. The element experiences exponential decay. Naturally, whenever physicists come up with something exceptionally cool, it gets misused in unrelated contexts. So “Half Life” has come to describe any process of exponential decay. But code does not decay, so there should be no half life of code, right? Well, yes and no. During 2015, 329 updates to the Chrome browser were released. That means that the Chrome browser you use today is different from the browser you used a year ago in at least 329 ways. Mozilla released 25 updates over the past year for Firefox. Apple had only 8 updates for Safari. By any measure, all of these browsers have changed in the past year despite not introducing a new generation. Browsers aren’t the only things that changed. PHP, the scripting language that is fundamental to the web has released 31 updates. WordPress, the most commonly used content management system has released 25 updates. These numbers are not unique to 2015. Every layer of the standard web development stack is undergoing constant updates. Those updates can be simple security patches or they can be a fundamental refactoring of the entire underlying technology (as was the jump to PHP 5.) The result of all of these constant small and large changes to the overall technical ecosystem of the internet is that code written to work today will soon become slightly out of date. The code does not decay, but the environment changes at an exponential rate; giving code its half life. Once upon a time, code was more stable. A mainframe running a FORTRAN program changed very little over its life cycle. Now, systems are built upon interrelated ecosystems of code, written in different languages and changing at unpredictable intervals. The positive aspect of these changes is to democratize computing and speed up innovation. But the speed of change also drives the accelerated aging of the codebase. The better things get, the worse the past becomes. The only way to prevent your codebase from aging (and eventually breaking) is to pay someone to maintain it. A good developer will know all the details of your development stack and make the constant tiny tweaks and updates that will keep everything in good working order. But Eddie is not alone in loathing maintenance contracts. Once you’ve paid someone to build something, continuing to pay them so it won’t break feels a bit like a protection racket. I get that. No one can tell exactly when code will break. The changes to the environment are constant, but their frequency and importance for a codebase are unpredictable. But here are some rough guidelines for how a web app’s codebase ages over two years: 1. The Day of Launch. Assuming the development team is up to date, this is the one perfect day the app will have. 2.Three Months after Launch. A good developer would look at the app and see things that need fixing. It’s unlikely that anything is broken, but small changes to the underlying technologies have already made the codebase slightly anachronistic. Getting the app updated would take one or two days of work. 3.Six Months after Launch. At this point, the app probably relies on some software that has at least one publicly discovered security vulnerability. Some pages might look slightly “off” in certain browsers. Basic functionality remains satisfactory. Getting the site updated would take about a few days of work. 4. One Year after Launch. Your app is now legacy code. There may be security vulnerabilities in the stack. Pages may be displaying incorrectly. Basic functionality may begin to break down for people using Chrome or the latest version of other browsers. Getting the site updated would take at least one week. 5. Two Years after Launch. If the site hasn’t broken by now, it may soon start breaking. The site probably uses anachronistic versions of a framework or library. At this point, it’s an open question whether to update the site, or rewrite it from scratch. The more time passes, the further towards obsolescence your codebase creeps – slowly at first and then catastrophically. This process is unlikely to slow down in the foreseeable future. In fact, the half life period of code is likely to speed up over the next five years, as the increasing prominence of open source in web development accelerates release cycles and diversity. That’s not your developer’s fault. They cannot slow down innovation.