I keep coming back to a story I’m not sure is true.

The story is that Roman engineers were required to live under the bridges they built, with their families, until the structures had proven safe. Apocryphal or not, the story has the right shape. It says: the people who design the work are personally accountable for what happens when it gets used.

Most professions have something like this. Not the bridge story, but the principle behind it. Medicine has malpractice. Engineering has licensure and codes. Law has the bar. Accounting has CPAs. Each of these emerged at the moment when an industry’s failures grew large enough that society demanded the people inside it take responsibility for the consequences of their work, not just the production of it.

Software didn’t.

That’s the gap.

What the data says about delivery

Software is the backbone of nearly every part of modern life. Transportation, healthcare, education, finance, infrastructure. And yet:

• Only 31% of software projects succeed (Standish Group’s CHAOS Report, 2020).
• Large IT projects routinely exceed budgets by 45% and deliver 56% less value than promised (McKinsey, 2012).

Imagine if Roman bridges collapsed at this rate. Imagine if aqueducts delivered only half the water they promised. We would consider it a public emergency. In software we consider it Tuesday.

This is not a tooling problem. It is an accountability problem.

What the older disciplines did

For more than a century, mature engineering fields have formalized their practices into Bodies of Knowledge: documented guides to what professionals in the field are expected to know, do, and answer for. A few of them:

• Mechanical Engineering (MEBoK, roughly 1880 onward). Thermodynamics, fluid mechanics, materials, mechanical design.
• Electrical Engineering (IEEE, roughly 1963 onward). Power systems, electronics, telecommunications.
• Civil Engineering (CEBoK, 2004). Structural, geotechnical, water resources, transportation.
• Systems Engineering (SEBoK, 2012). Designing and managing complex systems.
• Engineering Management (EMBoK, 1990s). Leadership, strategic planning, quality management.

Each one is a collective agreement: this is what we promise to know. This is the floor.

Software has one too. The Software Engineering Body of Knowledge (SWEBOK) has been around since 2004, currently at Version 3.0. Most software developers I meet have never read it. Few firms reference it. No state requires it. There is no licensure backed by it. There is no Standish-equivalent body that calls out shops that do not operate to it.

The Body of Knowledge exists. The standard of care does not.

Why this is a Change Energy question

I almost wrote this Field Note as a software piece. It still mostly reads as one. But the pattern underneath isn’t really about software. It is about what happens when an industry refuses to accept consequences for the things it produces.

A standard of care is, in the end, a behavior. It is what a professional does differently because they know they could be called to account for the result. Without it, effort gets spent on the work itself, not on whether the work was the right work, done well, that produced the outcome it claimed.

Effort is not work. A discipline without accountability is producing effort.

I don’t yet know what software’s equivalent of “living under the bridge” looks like. I have ideas. Some of them involve buyer-side leverage, some involve professional bodies, some involve the courts. Most of them require this industry to admit that the failure rates above are not acceptable, and that “software is hard” is not a defense.

The first step is naming it. So this is the naming.

If your industry produced 31% success rates in a field where the buyer could readily see the failure, the field would not exist anymore. The fact that ours does is a measure of how well we hide what we are producing, not of how well we produce it.