Maintenance Compulsion

Why Things Bite Back by Edward Tenner is an awesome blast from the past (maybe Windows 95 will save the world?), but it’s also a great deterrent from the idea that we can achieve all of our aims if we just author more and more systems. The idea that sticks with me is that of the Maintenance Compulsion: More advanced technology and systems require more skilled maintenance and vigilance, not less.

Take for example, in-house scripts and add-ins to automate repetitive tasks. In my last role I inherited responsibility for an AutoCAD script (hilariously enough, it was downloaded from Lee Mac and the downloader removed the copyright comments to pass it off as their own work) which automated the filling-in of title block revision schedules. And fair enough, it can take five or ten minutes to fill out the title blocks for a large set of sheets, which then need to be checked against the drawing index. This is brainless work with well-defined input and output, why not automate it?

The reason, it turns out, is that in order to save five or ten minutes per sheet set (an acute problem), you divert hours of billable time per week for one of your technical staff to become a volunteer champion, troubleshooter, programmer and staff trainer for the hacked-together system (a chronic waste of resources and attention). And take it from me, this troubleshooter is perfectly happy to be diverted for as long as possible, because nothing is so intoxicating to an amateur IT support person as fixing the same easy problem over and over and receiving glowing praise each time. I believe this system survives to this day, chewing up days of time per year. I even wrote a manual on how to troubleshoot it (stop feeding random f’ing commas into the CSV file!!!) and emailed it in after I resigned, out of sympathy for whoever had to pick up the mantle.

This experience gave me a new rule on my way out of that company: a total ban on voluntary part-time software development and maintenance. Leave it to software companies. If the need to make our own proprietary software ever becomes severe enough, it will justify a proper addition to our business operations and to someone’s written job description.