Weekly Musings 168

Welcome to this edition of Weekly Musings, where each Wednesday I share some thoughts about what’s caught my interest in the last seven days.

In this edition of the letter, I’m continuing to go off on a slightly different tangent. While I’m looping back in the direction of writing about technology, the subject of what you’re about to read is an aspect of technology that many of us tend to overlook or ignore.

With that out of the way, let’s get to this week’s musing.

On Maintenance

Innovation. That’s the big byword and buzzword these days, isn’t it? Innovation, we’re breathlessly told, is the key to our futures. It’s where the cool kids play. It’s the forge in which the heroes and rock stars are formed. It’s the space that’s most interesting, most challenging, most cutting edge. It’s where you want to be if you want to make a difference.

The drive for innovation also clouds our perceptions. It warps our view of things. Everything must be innovative. If it isn’t, it’s boring. It’s destined to fail. It’s not worth mention or attention. If something’s not innovative, it’s worth our derision.

Stemming from that mindset, for example, are all the however many negative reviews of releases of software or apps I’ve read over the years. Reviews bemoaning that there was nothing new in those releases. Reviews that unleashed a torrent of negativity because developers had the sheer temerity to fix long-standing bugs, to make sure that software or app was stable, that it kept running smoothly.

How wrong those reviewers were.

I’ll put it out there: innovation isn’t everything. Maintenance is just as important as innovation. I’d go so far to say that, in many cases, maintenance is more important than innovation. Sadly, it’s rarely viewed that way.

What prodded my thinking about maintenance versus innovation was a recent recollection of a conversation I overheard a few years back. A couple of the developers at a previous The Day JobTM were discussing maintenance just after 7:00 am one morning, during some quiet moments before the rest of the team filtered into the office. The application they were working on was, at the time, over 20 years old. In addition to adding new features, they had to worry about how those features and any bug fixes would potentially break some of the older code.

Which happened more often than anyone cared to admit. Up until a couple or three years before that conversation, the coding standards for that application were … well, let’s say they were rather loose. There was a lot of spaghetti code in the mix, and it was difficult to follow the strands to determine what touched what else.

On top of that, the older code wasn’t well documented. If it was documented at all. Worse, many of the developers who wrote that pasta-like code were no longer with the company, and I doubt many of them would remember writing that code.

That conversation reminded me of a simple truth: maintenance is hard. It’s time consuming. It can be painstaking, precise and have small margins for error. Maintenance requires a broader view of a system, a broader scope, a broader way of thinking around how all of the bits and pieces fit together, about how all the moving parts move in relation to each other.

Maintenance, any maintenance, is also vital. Often, there isn’t an alternative to conveniently (or not) switch to. There isn’t a way to immediately move whatever’s being kept going into a more modern form, into a more modern way of doing things.

Is it any wonder, when faced with the daunting prospect of those difficulties, that so many people shy away from maintenance?

And it’s not just in the wacky world of software development, either. The need for maintenance isn’t limited to the code that runs on just about everything in the world these days. The need for maintenance also applies to our infrastructure, to the devices and machines that are woven into our daily lives. Maintenance, in many of those cases, goes hand in hand with sustainability.

Few people want, for example, to hear about how dozens of kilometers of a sewage or water system were repaired and upgraded. They don’t want to hear tales of workers knee deep in muck and surrounded by the dank, plugging holes and shoring up supports and replacing pipes. Instead, people want to hear about the dozens or hundreds of kilometers of new pipes, crafted from the latest wonder material and 3D printed on the spot, being laid by robots driven by AI. While not as exciting as all of that cutting edge tech, those maintenance efforts help ensure our lives are a bit cleaner, a bit healthier.

Then there are the computers and tablets and phones that we use daily. You probably don’t think much about what goes into making, say, a smartphone. In a recent edition of his weekly email, Gerry McGovern points out that:

To make a smartphone requires 50-60 materials and 1,000 substances: 25% silicon, 23% plastic, 20% iron, 14% aluminium, 7% copper, 6% lead, 2% zinc, 1% tin. 90 kg of stone, gravel, and tailings are mined for every smartphone.

Add to that the countless litres of water used in the mining and manufacturing processes, and the toxic sludge that’s created when dealing with all of those materials. You get a scary, toxic mix and mess that we really can’t sustain at the scale at which we’re trying to sustain it.

If we had the right to repair all of our devices, to keep them alive for five or 10 or more years rather than replacing them every two or three, we might be able to step back a bit from those environmentally destructive processes. We might be able to give the boffins a bit more time to come up with cleaner, more sustainable alternatives. Maintenance, even on small scale, can be a force multiplier that has the potential to go a long way towards making all of what we use last longer.

Maintenance isn’t glamorous. It isn’t fun. It isn’t cool. But it is necessary. And we need to acknowledge that. We need to put more effort and energy and funding into keeping what we have going. And not neglecting what we have in hopes that something newer will quickly take its place.

Something to ponder.

Scott Nesbitt