Not all code should be plastic

I recently read the first volume of Maintenance: Of Everything by Stewart Brand. It's a fascinating look at human progress through the lens of maintenance. Naturally, one can read everything in this book as a metaphor for software. (This is not stated explicitly in the text, which is to its credit.) One of the points made by the book is that there is more than one way to do maintenance: accepting that you will need to do it, and calmly thinking through each problem as it comes up; or reaching a holistic understanding and designing for maintenance upfront so that you may achieve a zen state of mind while operating. But you cannot ignore maintenance.

Certainly, not everything in the world that's useful is designed to be maintainable. There is a large market for cheap disposable goods for a reason. Crucially, that is not all things! Imagine if we built houses out of plastic. It might work, but at a cost of more frequent replacement, likely leading to higher overall cost as time marches on. You need to decide what your goals are for a thing and pick the solution that best matches that.

But a lot of code will outlive its intended throw-away lifespan. A while ago I was reading another book, Broad Band by Claire L. Evans, which talks about Grace Hopper's work on COBOL (among many other things—I learned about a lot of parts of tech history I hadn't known about—give it a read!) COBOL is the result of a session run by the Department of Defense aimed at creating a business-oriented language to combat the increasing maintenance cost of programming work. They set out to create three steering committees to create three programming language specifications: one for the short term, one for the medium term, and one for the long term. The short-term one produced the spec for COBOL. The medium- and long-term ones never produced languages to replace it. COBOL outlived its intended lifespan by decades.

Right now it feels like the software industry is ignoring maintenance. There is more and more pressure to build code with plastic instead of brick and mortar. Inevitably, we are going to end up spending more time and effort and money keeping a sizeable chunk of that code alive and running for years to come. So next time, perhaps push back on some of the pressure to ignore maintenance.