Why code rots?

08 May 2017

It’s not uncommon for non-tech entrepreneurs or MBA-grads to think of software as a one-time-and-done solution to a problem. In other words, once you “solved” that problem you don’t need to do anything else, like adding a door to a house or building the kitchen in a restaurant. Hence, the myriad of requests for a “cheap” developer to build a “clone of X” or build an app (and not maintain it).

Software projects are never done. There is no point in time in which you can say you don’t need a developer anymore because the software is finished. No matter if you are building the most boring code in the world to manage a steel mill inventory or the most sophisticated AI to replace doctors. The work never stops. Here are a few reasons why:

The needs change

This should be obvious, but many people believe they can map an entire process, collect the exact requirements, and deliver the “perfect specification” for a developer to build a piece of software. This is pretty much the definition of a “waterfall” process, and the reason too many millions and billions were spent in overly ambitious and overly specified projects that ultimately failed to either ship or, once shipped, weren’t used.

The changes can be as small as the size of a field that was originally determined to be up to 30 characters need to be 50 characters to more dramatic changes in how the data is encrypted or which database software is being used, to everything in between, particularly in the UI and user experience (who could predict that putting the Cancel button at “that” location would cause some much pain?)

Platforms and infrastructure change

Your software must run in some operating system, some firmware or some cloud infrastructure, and those might change. It’s even more dramatic if it runs as an app on a mobile device or a website because mobile OSes and browsers change a lot faster, and something that used to work just a month ago might not work anymore. Not necessarily the new browser broke your code; maybe the browser itself had a flaw that got fixed, but your software was mistakenly using that flaw, and once the browser got fixed it broke your site. It’s also not uncommon for Apple or Google to make breaking changes to their mobile OSes (iOS and Android) to make it more secure, to improve users’ privacy, or to prevent abuse by some app developers.

The Web of APIs’ changes

It’s nearly impossible to build a piece of software nowadays that doesn’t rely on some external API: Facebook Connect, Sendgrid, Google Analytics, AWS/Azure/Google services like Machine Learning, Twitter, NewRelic, etc. APIs get upgraded with different authentication mechanisms to make them more secure; new error codes are added to represent previous unreported issues, or they change the way errors (or success) are returned.

A single endpoint might get deprecated, or an entire version of an API might get deprecated at once. These are not unusual at all. You might not hear about it, but your friendly developer next door knows it very well. The “good” API providers will give you 6-month notice or more once a change is about to break your code, but some of these changes are not notified to you at all, and you learn the hard way by catching errors on your logs in production or, worse, by a customer telling you something is not working.

The Market Changes

If you are selling your software product, it’s very unlikely there isn’t a competitor out there pushing you to update your product often for you to keep it relevant. It’s also not uncommon for new players to come to the market, that even though don’t compete with your product, your customer expects both products to work well together.

Even government regulation is changing at a faster pace than ever before. A new EU privacy rule, a new US encryption export law, or a new Brazilian data governance policy can throw a wrench at your existing product. And before you say that those don’t apply to you, your software is likely to rely on other components and frameworks those laws and regulations do apply to, so as a side-effect your product needs to change.

The unexpected and unplanned for

There is a much bigger pattern of problems in software that will affect your need to have a developer updating it all the time. That’s when the unexpected happen. It can be a log file that grew too big, and suddenly your computer, server, website, or app is acting strangely: crashing, returning errors, being super slow or just “misbehaving.”

Maybe your software was working perfectly well when you had up to 5,000 users a day, but due to some engineering decision made eons ago, as soon as you got to 5,001 users the caching system built to speed up the site started trashing itself. Or a database table that used to fit in memory grew just one extra row too big and you’ll need to upgrade the memory on your server or change the way the code and database work.

If you don’t have a developer working at least part-time on your product and up-to-date with the code you are at risk. When one of these issues happen, it could bring your product down and make it unusable for days to weeks. You’ll need to find a developer with the right skills; she’ll need to understand your infrastructure and code; she will figure out what’s going on; and, finally, she will figure out how to fix it, test it, and deploy it again. It could be many days if you are lucky, potentially a week or two. In the meantime, you lost sleep, money (in the form of a significant expense and the form of lost revenue), and likely you lost customers.

My point is that you should not fall into the trap that you’ll invest a fixed amount of time or money into building the product, then the product is ready to be sold, and you don’t need to build anything else anymore. Each software product (actually, each feature inside of that product) will have an ongoing maintenance cost.