Why Building Software Feels Broken

I've been in the software business for about three decades now. That's long enough to see all sorts of trends come and go. Lately, though, I feel that the industry has lost sight of what is truly important. Instead of solving real problems in a simple way, we keep piling on new frameworks and buzzwords. We seem more interested in following the latest fad than in producing software that helps people and businesses.

The Rise of the “Problem Machine”

Everywhere I look, someone’s inventing a new problem to solve. And the more trivial the problem, the more over-engineered the solution. It’s like we’ve built an entire ecosystem around fixing things that didn’t need fixing. Just so we can use the latest framework, architecture, or buzzword. Somewhere along the way, solving real problems got replaced by proving how modern our stack is.

And it’s costing us. Recent industry reports show that nearly 70% of software projects go over budget. Almost a third miss their deadlines. In enterprise environments, that translates into millions lost on delays, rewrites, and features nobody asked for. We’re not short on tools. On the contrary, we have more than we know what to do with. What we are short on is clarity. It feels like we’re tangled up in our own complexity.

The irony? All these tools, all this ceremony, were meant to make things faster. Instead, they’ve added layers of abstraction that slow us down. Sprints filled with backlog grooming for features that get changed mid-cycle. Planning sessions to plan the next planning session. Every new tech decision spawns more meetings, more training, and more dependencies. And with each new dependency, the system becomes harder to understand, let alone maintain.

It’s no wonder projects run late and over budget. We've turned the act of building software into managing the chaos we created ourselves. Somehow, we’ve created a process that feeds on itself.

Here some data:

• 70% of projects go over budget
• 29% are delivered late
• The average cost overrun is 27%
• For large-scale IT projects, the overrun jumps to 45%

This data reflects exactly what I have been observing for years in projects at large companies. It feels like implementation has never been so slow and expensive.

The Age of Cargo Cults

Cargo cult development means copying techniques or tools from successful teams without understanding their context, hoping success will magically follow. Teams choose a popular framework because it worked for someone else, even if their needs are completely different.

You know the stack: React wrapped in Next.js wrapped in Vite, TypeScript sprinkled with decorators, talking to a NestJS backend that queues messages via Kafka through a Saga orchestrator, all dockerized, deployed to Kubernetes with 17 microservices each running Polly, MediatR, and custom logging middleware nobody asked for. All to serve a contact form.

Design patterns and architectural styles have also become sacred texts. Everyone wants to push microservices or CQRS or some other big idea. While these concepts can work well, they're often applied where they're not needed. The result is more layers of abstraction, more dependencies, more everything but clarity.

This obsession with the “right” frameworks and patterns can lead to months of refactoring code or re-engineering systems that were working just fine. I’m not opposed to continuous improvement, quite the contrary. But when improvement becomes an endless cycle of rework, it feels like we’re seeking problems instead of solving them.

This isn't engineering anymore. It's theater. Patterns such as SOLID, or this religion of Clean Architecture, have become sacred. Tools are chosen before problems are understood, and developers are rewarded more for stack conformity than for delivering value. We've built an industry optimized not for results, but for rituals.

The Disconnect Between Tools and Usefulness

We have so many tools at our fingertips: containerization, cloud services, sophisticated IDEs, automation pipelines, and more. You’d think with all these advancements, developing software would be smoother and cheaper. Instead, we often see ballooning budgets and longer timelines.

It might be because we’re not focusing on the most important parts of software development: understanding the domain, the core problem and building just enough software to address it. We often get lost in the overhead of our chosen stack, spinning our wheels trying to fit a solution into the shape of a fashionable tool.

Sometimes, we forget to ask: “Who really needs this feature?” or “Will this tool actually improve our workflow?” We stop evaluating what’s genuinely useful, and we focus on shipping the next shiny piece of tech. The human aspect, asking questions, working closely with users, iterating on real feedback, gets drowned out by hype.

The goal should never be to use “more tech". The goal should be to use just enough of the right tech to solve the right problem, and then get out of the way.

A Call for Simplicity

I don’t think frameworks or patterns are bad on their own. They are powerful and effective when used wisely. But the industry seems to have drifted into a frenzy of chasing trends, as if the sheer number of integrated frameworks is a badge of honor. We spend millions without a second thought, all in the name of “adopting best practices.”

Often I see posts on LinkedIn listing the “9 essential libraries” every .NET project should have, or similar. Serilog, MediatR, FluentValidation, Polly, EFCore, Dapper, MassTransit and more. All packaged up as must-haves, no matter the context. It’s not that these tools are inherently wrong. They’re well-built and solve real problems. But somewhere along the way, we stopped asking whether we actually need them, or if we’re just reaching for them out of habit, or worse, to keep up appearances.

My hope is that more teams will step back and think carefully about what they’re building. Does every product need microservices? Do we need 50 libraries for the simplest tasks? Are we automating processes that no one actually wants or needs? These are the kinds of questions we should ask.

1. Start Small – Implement features in the simplest possible way.
2. Validate Real Needs – Make sure there’s a genuine need behind each problem you decide to solve.
3. Choose Tools Wisely – Pick frameworks and patterns that match your actual requirements, not just today’s trends.
4. Refine, Don’t Reinvent – Improve existing solutions incrementally instead of constantly rebuilding from scratch.

Conclusion

Software development should be about creating real value. It should solve real problems in a sensible, cost-effective way. But we’re surrounded by examples where projects go off the rails, budgets balloon, and new frameworks multiply without a clear reason.

It’s time to cut through the noise. By focusing on simplicity and genuine usefulness, we can avoid becoming part of a “problem machine.” Instead, we can build products that actually help people, without burying ourselves in unnecessary complexity.

That’s the software industry I’d like to see: one where technology serves us, not the other way around.

Cheers!