Remember the last time you chatted with other tech folks about some unicorn hotness enterprise organization? With their global presence and legacy systems and broad customer base?
No one has that conversation. In tech, it’s about what’s new and sexy. Startups get investment based on projections of where they’re going, not how well they’re running existing things and their plan to keep doing that.
Maintenance? Not so sexy.
And yet, listening to this “In Praise of Maintenance” Freakonomics podcast recently, a lot resonated.
The podcast covered a lot of ground, including urban infrastructure. But there was also plenty about running companies. How focus and culture so often tend to favour innovation over maintenance.
It’s a struggle with which any software developer is familiar.
In tech we’re obsessed with innovation, but paradoxically, in that obsession we’re clueless about actual innovation. What passes is often divorced from creativity, and even from just solving real problems.
We even still cling to the idea that enough innovation, enough technology, will do away with the need for maintenance — nay, the very notion of work — almost entirely. From Jetsons-esque kitchens to self-repairing software, if we just build the right cool thing, we’ll never work another day in our lives.
Yeah … about that.
What actually happens is that technological innovation leads to more work, whether for 1950s housewives or engineering teams.
Basically, when something’s difficult and a lot of work, we do it as little as possible. When innovation happens, we end up doing it a lot more. This applies to code bloat as much as to laundry after the invention of the washing machine.
The cycle gets more vicious. When we don’t sufficiently invest in maintenance, what we have — code, products, etc. — becomes messy, shabby, and a pain to work with. We become disillusioned.
But hey, then someone has a great idea to replace whatever’s under-maintained with this shinier, newer thing. Hurray! It’s got the features to practically maintain itself! But guess what destiny that shiny new thing shares? It’s like a software version of Toy Story…
Bad maintenance situations somehow attract saviours like overripe melon attracts fruit flies. From code bases to school systems, some well-meaning parent company, executive, or billionaire will swoop in with a boatload of ideas, ego, and cash to make everything better and shiny again.
Except that doesn’t work.
Maintenance requires planning and intelligence, not just capital. Papering over problems with cash and consultants’ reports doesn’t actually fix them. People who don’t have any skin in the game aren’t going to know what actual customers or employees are banging their heads against daily.
Plus, shoveling resources at a maintenance debt that’s hit crisis point doesn’t work. It took a while for things to get that neglected. And it will take a while to fix them. 40-plus years on, Brooks’ law still holds true.
Diligent maintenance can help prevent all of this, and liberates those in charge of the existing stuff to work on planning new stuff well. Logically, incrementally. Fill important niches, solve real problems. Generate sustainable revenue and jobs.
I know, incrementalism isn’t sexy, either.
But I agree with the podcast comment that very few people are true innovators — those who can come up with brilliant ideas completely out of left field. There is, however, a lot of delusional iterators with fancy PowerPoint decks. (The next Freakonomics podcast was In Praise of Incrementalism, by the way.)
Thing is, innovation and maintenance are not mutually exclusive. Both are necessary in different amounts in different companies at different times.
Simplified, younger companies are better at innovation than maintenance. Plus they have less to maintain overall. So it makes sense that more of their money would be earmarked for growth initiatives (especially if they’ve taken investment).
But at the same time, were I doling out millions, I’d want to see how companies I invested in plan to maintain things.
What’s the plan for existing products to be improved? What about security? Keeping customers (and staff) happy? In general, how will maintenance debt be prevented?
That, to me, speaks of maturity.
Bigger, longer-established companies have more of the things listed above to manage, but also typically more resources. And good maintenance means more revenue, which fuels both continued maintenance and innovation ... in theory.
The bigger you get and the more you have going on, the slower you move and the less flexibly you think. What does innovation actually mean in your mature company or industry?
This is why we scoff at the idea of multinational behemoths being “agile” or “revolutionary”. Some of these big companies use investment or acquisition as a way to adopt innovative thought and practice rather than struggling trying to germinate it internally.
One of the biggest challenges with handling maintenance well is the question of whose responsibility it should be. Sure, there are people really well suited to it, but again, whether software or sewers, we’re indoctrinated that it’s not sexy.
That’s something we need to work on early, during STEM education. How valuable the work is and how much rests on the shoulders of people who get it done. I think it should be an intrinsic part of what the Iron Ring means, for example.
Once it’s determined who’s responsible for maintenance, the other big contention is who should pay for it. Should existing customers be paying for maintenance and improvement of what they’re already using? Should new revenue pay for both new shiny and old faithful?
It might seem obvious, but is it? The podcast’s airports comparison was a good one. Should the people living where the airport is pay for its maintenance and upgrades, or the people using the airport, no matter where they’re from?
Ultimately, though, maintenance is right up there with death and taxes. They can go down the easy (or at least incremental) way, or the hard way…
M-Theory is an opinion column by Melanie Baker. Opinions expressed are those of the author and do not necessarily reflect the views of Communitech. Melle can be reached @melle or me@melle.ca.
