Zen and the Art of Software Maintenance

In most trades, there is no expectation that work will focus primarily on new construction. Most expected work is repair and maintenance. Software is a trade that has not embraced this looming transition. From our "Cambrian explosion" over the last twenty years through to maturing and consolidating markets, the coming decades will bring a lot of maintenance work.

Yet we really don't respect software maintenance work or dedicate resources to aiding it...we as an industry continue to focus on new construction as the primary task. I've dedicated some thought to some of the requirements for being a good software maintainer in hopes of motivating my own thought on the topic and hopefully yours.

So what can a software maintainer be expected to do? Roughly in order from first contact:

• Forensics. Take a pile of muck and know how to start dissecting it. This is far more art than science, but nothing else in software maintenance can be achieved if the ball of muck will not be approached. Forensics may also imply reading "dead" languages and formats.
• Triage. No progress can be made on other maintenance tasks until it is understood how to deal with emergencies. Initially, this may simply be brute debugging. Eventually, the other tooling that should emerge from good maintenance will make this easier.
• Logging. Code cannot be rehabilitated without telemetry. Indeed it is useful to permanently instrument the code to integrate timing and resource logging in a development branch along with the usual logging of issues and errors.
• Alerting/Observation. An extension of logging; automate delivery of bad news.
• Business Continuity. Formalize any other processes or instrumentation involved with keeping the system operation from a business perspective. In many cases this involves containing issues as opposed to fixing them.
• Bug identification. Identify real outstanding issues that require repair, not just containment.
• Documentation. More than just bug identification; this is about making sense of what is there short of reading the code.
• Harm Reduction. Fix what is realistic to fix without triggering a full rewrite.
• Paths To Scalability. Identify ways to get some more mileage out of the existing codebase. This may include options for cloud services, implementation of better version control, use of a container platform etc etc.
• Security Patching. These must be done outside of the scope of other software changes so it makes sense to develop a special process.
• Lifespan Estimation. Even rehabilitated systems can move past the point of no-return or induce unacceptable maintenance costs.

last update 2017-02-21