Software Development: How We Can Beat the Odds
The failures we stopped accepting and the answers we found
Everyone in technology knows the number: two-thirds of software projects fail. The Standish CHAOS reports, consulting surveys, academic studies — they all converge on the same grim statistic. Some projects never deliver a usable system at all. Others limp into production late, bloated, and compromised, haunting their organizations for years
For too long, companies have treated this like the weather — unfortunate, but unavoidable. Executives pad budgets, managers lower expectations, and developers joke about “death marches” as if collapse were a natural law.
But failure is not destiny. One-third of projects succeed. That fact, so often ignored, is proof enough. Success is possible. The real question is why it remains the exception instead of the rule.
The answer is painfully clear: systems don’t fail because silicon fails. They fail because meaning fails. Business leaders describe one thing, developers implement another, and by the time anyone notices, it’s too late.
That cycle of mistranslation has been treated as inevitable. We need to prove otherwise.
From scars to skepticism
Ask any CIO or CTO and you’ll see the scars. They’ve watched money evaporate in projects that delivered systems nobody ever got to use. They’ve stood before boards explaining why transformation programs fell apart. They’ve carried the blame when ambition turned into disaster.
And yet, despite all the pain, software technology keeps offering the same pitch: faster, cheaper, more automated. Cloud horsepower. Agile rituals. AI assistants. All useful in their place, but none touch the root cause of failure: the loss of meaning between business intent and system behavior.
That silence is an opening. Daring to name the problem earns the right to propose a different solution.
A lifetime of counter-evidence
I have spent more than fifty years building systems across industries, continents, and technologies. And in all that time, I have never presided over the kind of catastrophic project collapse that fills postmortems and ends careers. Not because I was lucky, or because my teams or I were flawless, but because we refused to let meaning drift.
We built habits and tools to ensure that when business people said what they needed, developers captured exactly that — not an approximation, not an interpretation. And when meaning held steady, failure stopped being inevitable.
The following was born from those lessons.
The first step: assertion modeling
The cycle of failure begins at the start. Projects launch with conversations and documents that quickly become unrecognizable as they move through the machinery of analysis, design, and code. What seemed obvious in a meeting turns into something alien months later.
We can break that pattern by starting with assertion modeling.
An assertion is a simple, structured statement of business meaning. Assertions define the data people work with, the responsibilities that bind them, the flows of information, and the rules that govern decisions. They are captured in a guided application that organizes meaning and displays it in business-friendly diagrams.
These diagrams are not technical blueprints. They are visual maps of the business itself. Executives, managers, and staff can look at them and say: “Yes, that’s what we mean.” They can spot contradictions before a line of code is written. They can confirm intent in plain sight.
For the first time, mistranslation loses its hiding place.
From assertion to execution without drift
Capturing meaning is necessary. But preserving it is decisive. History is full of projects that began with clarity and collapsed as soon as development began.
We can close that gap. Assertion perspectives can be formalized as bounded contexts (and executable components) — the backbone of Domain-Driven Design. From there, we can also define the Java records that implement DDD entities and aggregates.
They execute within federated service nodes with their message moderators that manage messages between them: synchronously, asynchronously, or as pub-sub events. Bindable components are stateless, REST-compliant, and predictable. They are pure message processors — supporting real-time load-balancing, scaling, and failover.
The crucial point: there is no semantic drift. What a business user approved in a diagram is the same rule the system enforces in execution. What you approve is what you get.
The second step: independence and resilience
Even when meaning is preserved, most systems remain brittle. Business logic gets tangled with technical scaffolding: database quirks, vendor dependencies, performance hacks. Every change risks shattering the foundation.
We can reverse the equation with a runtime that insulates business logic from technical disruption.
- Scaling: When traffic rises, the federation can stand up new nodes automatically.
- Failover: When a node fails, others reroute instantly and can replace it without manual intervention.
- Performance: Message Moderators monitor response times and optimize throughput on the fly.
- Persistence: A DataSet interface abstracts away the database. Developers never write SQL. They work with defined entities and aggregates, whether the system runs on Oracle, PostgreSQL, or even (noSQL) MongoDB.
The result is freedom. Swap databases without rewriting business logic. Replace messaging protocols without touching application code. Let the platform handle resilience while business rules remain untouched.
For executives, that is insurance: the business rules you invest in today will still run tomorrow, no matter how the technical landscape shifts.
The third step: selling certainty
In a world where everyone else normalizes failure, we can promise something radical: certainty.
- Reduced project risk: Meaning is captured, validated, and preserved. No surprises at delivery.
- Faster transformation: With mistranslation eliminated, projects move from agreement to execution without endless churn.
- Resilient investment: Business rules survive database swaps, vendor fights, and infrastructure churn.
This doesn’t mean projects run on autopilot. Leadership and discipline remain essential. But the risk shifts to where it belongs: business decisions, not failed communication.
That shift is liberating. It is why CTOs and CIOs, weary of scars, lean in when they hear this story.
Why this matters now
Software development has lived too long under the myth that failure is unavoidable. Two-thirds of projects collapse, executives are told, as if that were the weather. But these are not acts of nature. They are acts of mistranslation, neglect, and resignation.
We can offer a different path:
- Start with clarity.
- Preserve meaning without drift.
- Insulate business rules from technical turbulence.
This is not another tool in the stack. It is a new architecture for alignment — between business and technology, between intent and execution.
A final reflection
Systems are not machines alone. They are living ecosystems, with feedback loops that reinforce failure if left unchecked. The conventional cycle of software — misheard requirements, bloated projects, brittle systems — is one such loop. It has been running for decades, grinding confidence out of business leaders and talent out of development teams.
We can design to break that loop.
By unifying assertion modeling, Bindable components, and a resilient runtime, it rewrites the odds. Failure is no longer the expectation. Alignment becomes the norm. Business rules endure. Technology churn becomes survivable.
In a world where resignation has become cliché, selling certainty is the boldest move we can make.
Because software should not be a gamble. It should be what it always promised to be: the faithful execution of what the business actually meant.
