The Hidden Cost of “Move Fast and Break Things”

The article argues that the software industry's long-standing prioritization of speed over all else has normalized dangerous shortcuts, turning temporary fixes into permanent operational debt. This "move fast and break things" culture leads to complex, unmaintainable systems that resist change, ultimately harming both the software and the developers who must work with it. The author concludes that as software becomes critical infrastructure, the industry must shift toward valuing sustainable architecture and long-term maintainability over rapid, chaotic output.

For a long time, the software industry rewarded speed above almost everything else. Ship faster. Scale faster. Prototype faster. Iterate faster. And to be fair, that mindset helped create an incredible era of innovation. A lot of amazing products probably never would have existed without teams willing to move quickly and experiment aggressively. But over time, I think the industry accidentally normalized something dangerous: Treating long-term maintainability like someone else’s future problem. When you’re building something from nothing, speed matters. You need: Perfect architecture on day one is usually unrealistic. I don’t think most developers disagree with that. The problem starts when temporary shortcuts slowly become permanent operational realities. Because eventually: And suddenly the codebase everyone rushed together six years ago is now responsible for: That’s where the real cost begins appearing. One thing I’ve noticed is that bad architecture rarely explodes immediately. It accumulates. Slowly. Almost invisibly. At first it looks manageable: Then years later: Eventually the system itself starts resisting change. Not because the developers are bad. Because complexity compounds over time. One thing I’ve become increasingly cautious about is how often modern development culture rewards visible activity over sustainable architecture. There’s enormous pressure to: But sustainable systems usually aren’t built through chaos. They’re built through: A system surviving for ten years is often more impressive than a system shipping ten features in one month. But the industry rarely celebrates that kind of engineering patience. This is the part I think we underestimate the most. Poor architecture doesn’t just affect servers. It affects people. Eventually: I’ve seen situations where: At that point, the problem is no longer technical. It’s organizational. I actually think AI makes sustainable architecture more important, not less. Because AI is extremely good at producing: But speed without structure can generate enormous amounts of hidden complexity very quickly. Generated code still needs: Otherwise we risk creating systems that grow faster than humans can realistically understand them. That’s not acceleration. That’s architectural debt at machine speed. To be clear: I don’t think speed itself is bad. Some of the best engineering breakthroughs come from experimentation and momentum. The real issue is when: Because eventually every fast-moving system slows down. The question is whether the architecture supports evolution when that happens. The longer I work on systems like: the more I care about: Not because those ideas are trendy. Because systems eventually outlive the excitement phase. And when they do, maintainability becomes one of the most valuable engineering features imaginable. I think one reason this matters so much now is because software increasingly is infrastructure. It runs: We’re no longer just building experimental web pages. We’re building operational ecosystems people depend on daily. That changes the responsibility attached to architecture decisions. Interestingly, I think we’re already starting to see signs of a shift. More developers are talking about: Not just: I think people are starting to realize that sustainable systems matter. Especially as applications become larger and more interconnected. I still believe experimentation matters. I still believe iteration matters. I still believe speed matters. But I also think sustainable engineering deserves far more attention than it gets. Because eventually: And the longer software becomes part of everyday life, the more important long-term thinking becomes. Maybe the future isn’t: “move fast and break things.” Maybe the future is: “build clearly enough that things don’t have to break constantly in the first place.”