Technology has had a cult of newness for centuries. We hail innovators, cheer change, and fend off critics who might think new and change are coming too fast. Unfortunately, while that drives the cycle of creation, it also creates biases that damage what we create, reducing the benefits and increasing the costs.
Formerly new things rapidly become ordinary “plumbing,” while maintenance becomes a cost center, something to complain about. “Green fields” and startups look ever more attractive because they offer opportunities to start fresh, with minimal connections to past technology decisions.
The problem, though, is that most of these new things — the ones that succeed enough to stay around — have a long maintenance cycle ahead of them. As Axel Rauschmayer put it:
“People who maintain stuff are the unsung heroes of software development.”
In a different context, Steve Hendricks of Historic Doors pointed out that:
“Low maintenance is the holy grail of our culture. We’ve gone so far that we’re willing to throw things away rather than fix them.”
That gets especially expensive. Heaping praise on the creators of new things while trying to minimize the costs of the maintainers is a recipe for disaster over the long term.
I’ve contributed to this disaster. I love starting new projects on open fields, full of visions for creating from scratch. I can choose my own tools, tackle problems from the angles I prefer, and, perhaps most important, choose the order in which I add new features. In the books I write, I assume the reader is starting from scratch, able to learn features in isolation and slowly develop a sense of how it all fits together.
Even as I’ve spent years telling the story of starting from a clean slate, though, I’ve spent most of my programming and Web time on maintenance, updating my own and other people’s content, code, servers, and networks. Maintenance constantly calls me out of my comfort zone, forcing me to remember things I did long ago or focus on parts that used to just work. Maintenance forces me to rely on other people — the real heroes — on a regular basis, often in emergency situations.
So how can we fix it?
This is a cultural problem, not a technical problem. More precisely, the problems have technical aspects, but those aspects vary wildly from project to project. Maintaining AngularJS projects is very different from maintaining COBOL projects. The cultural stories, though, may be more similar.
Someone at CSSDevConf last fall took the first step on that path, asking the audience how many of them moved from new project to new project and how many stayed on projects for a long time going forward. That prompted some blunt conversations about the differences among Web developers and their priorities, though it was clear that it was just a first step.
DevOps — I think because it values operations — takes maintenance seriously, insisting on covering the whole lifecycle of a product rather than the waterfall vision of perfection at the deployment of a project. Iteration and continuous development models put a gloss of new and fresh on what used to seem old and blocking.
DevOps eases the problem and gives some of us a place to talk about it. Most of us, though, work in places whose projects have not been and likely will never be under the DevOps umbrella. It’s also possible that projects that start in full DevOps mode dwindle and find themselves in more traditional maintenance. While I hope DevOps approaches will prove contagious, something smaller seems like it might be more important.
We need to place a much higher value on maintenance and maintainers. We need to worship maintainers with the same fervor we worship creators. We need to recognize that not having emergencies can mean more, despite being less visible than a well-handled emergency. We need to value continuity (in a bumpy world) as much as we value growth. We need to recognize that growth is pointless unless we provide it with a solid foundation.
Editor’s note: if you’re interested in finding out if a DevOps approach will prove to be contagious within your organization, you’ll want to check out the Effective DevOps training session at Velocity in Santa Clara May 27-29, 2015.
This post is part of an ongoing exploration into cross-pollinating Web communities.
Cropped switch image CC BY-SA 2.0 Andrew Hart via Flickr.