Build and Repair

Every new platform eventually becomes creaking scrap metal. Every once in a while, an innovative product turns into a critical system that someone has to keep alive with duct tape and 3 a.m. Slack messages. The dirty secret of the digital age? The future runs on maintenance, not on shiny new things.

It’s worth looking at this year’s article by Ron Bronson “Design as Repair.”  He calls this phenomenon “Designing Through Repair.” Systems don’t fail in spectacular explosions - they rot quietly from within, continuously bandaged by the people stuck inside them. Real creativity happens in the cracks between procedures, where frontline workers and underpaid maintenance specialists keep the whole mess from collapsing. Bronson puts it plainly that one needs to design so that things can be fixed, and stop pretending you can always start from scratch.

On the one hand, we keep repeating the myth that the lion’s share of the IT budget goes to maintenance, as if we should find that embarrassing. In reality, maintenance is hard, tedious, and, to some, boring work, but it is by no means a waste of time. It is through constantly pushing fixes, updating features, and adapting systems to business reality that true innovation emerges. A system that can evolve and improve without downtime proves that maintenance and development are not opposites - they’re two sides of the same coin. Want innovation? Make sure maintenance is done well. This part of managing IT infrastructure is unavoidable. The only choice is whether we botch it spectacularly.

Werner Vogels, Amazon’s Chief Technology Officer, doesn’t sugarcoat things and has been repeating the same mantra for years: “everything fails, all the time.” You’d think the CTO of a massive company and the steward of an equally enormous cloud would preach perfection… Not at all. Vogels insists that failure is the natural state of things. Build systems that heal themselves, reroute traffic, recover functionality, and do it all without human intervention. Redundancy, automation, and isolation aren’t wishful thinking. Chaos Monkey should be your coworker, not a problem to be fixed.

Combine these authors and you get a brutal but liberating truth - maintenance is real innovation. We don’t need preachers with TEDx, we need people who make sure nothing falls apart. Every new feature is a maintenance debt wearing a hoodie. Every MVP is a future headache waiting for an incident report from a test that spontaneously turned into production.

So let’s stop pretending deployment is the finish line. It’s only the beginning of a long, bloody repair process. Software ages. Infrastructure rusts. Organizations decay. The question isn’t “can we avoid entropy” but “can we manage it without hysteria”.

If you listen closely to the industry, you can see the culture shifting toward the triumph of the maintenance worker. Theoperations engineer designing for resilience. The service designer builds tools that bend but don’t break. The product team treats stability as a feature, not a fundamental flaw that kills creativity and innovation. Maintenance isn’t the boring part of the job, it’s the part that keeps civilization alive.

Maybe it’s time to stop mindlessly fetishizing novelty and finally learn to take proper care of what’s already built. For years, we’ve lived in a culture of deployment, ADHD, everything must be new, better, more innovative, ideally cloud-native, and real-time. In this race toward perpetual tomorrow, we’ve forgotten that technology, like people, needs care, not just constant cosmetic surgery. Zero-downtime deployment isn’t magic, it’s simply a sign of competent maintenance, discipline, and humility in the face of system complexity. But of course, that doesn’t sound as sexy in marketing as AI-powered disruption.

Meanwhile, breaking things in the name of innovation is not just expensive, it’s deeply irresponsible. In a world where every startup promises a revolution, stability has become a true luxury. It’s increasingly clear that the next big wave of technological progress won’t emerge from labs full of shiny prototypes but from the quiet spaces of maintenance and repair. From the places where system resilience matters more than glitz. From environments built on self-healing, autonomous upkeep, and teams who know how to care for what they built, not just how to launch it.

Anyone can build today, from a student with a tutorial to a corporation with a half-billion-dollar budget. But repairing, maintaining, and improving with respect for the user and the infrastructure, only a few can do that. And they, quietly, without fanfare or keynotes, are the ones who truly run the IT world.