A Call for a Standard of Care in Software Product Development

Introduction: Why You Need to Care

It’s astonishing and yet unsurprising, given the last few decades of rapid technological growth, that the software industry remains so vulnerable to failure. Despite being the backbone of nearly every facet of modern life—transportation, healthcare, education, finance—software development is plagued by alarming inefficiencies and inconsistencies.

We’re at a critical juncture: software has scaled exponentially in both complexity and influence, but the profession itself hasn’t evolved to keep pace. Unlike established engineering disciplines, software development lacks the standardized principles and accountability necessary to meet the demands of the systems it creates.

This isn’t a new problem. History provides a clear roadmap for what must come next.

Learning from Roman Engineering

Let’s look back nearly 2,000 years to the Roman Empire, renowned for its engineering prowess. Roman engineers were not just builders—they were pioneers who combined creativity with accountability. Using innovative materials like concrete and careful attention to structural principles, they constructed aqueducts, bridges, and roads that have endured for millennia.

One striking (if apocryphal) story underscores their ethos of accountability: Roman engineers were allegedly required to live under the bridges they built until the structures proved safe. Whether or not this actually happened, the story highlights an enduring truth about engineering in ancient Rome: failures were personal. Accountability wasn’t an abstract concept—it was a matter of survival.

As Rome’s infrastructure expanded, so did its understanding of the trade-offs inherent in engineering. Early Roman engineers made calculated decisions about where to allocate limited resources, focusing on foundational elements and structural integrity over decorative excess. This relentless prioritization of the essential allowed their projects to withstand the tests of time and use.

In essence, they practiced early forms of what we now know as:

• Cost-Benefit Analysis: Ensuring the value outweighed the resources spent.
• Systems Thinking: Understanding how infrastructure like aqueducts and roads supported interconnected societal needs.
• The Pareto Principle: Focusing on key investments (e.g., strategic roads) that delivered the greatest public good (sometimes over-simplified to the 80/20 rule).

These principles, formalized centuries later, emerged instinctively in Roman engineering and remain vital today.

The Accountability Gap in Software Development

Fast forward to today, and it’s clear that software development has yet to embrace this kind of professional rigor. Consider these alarming statistics:

• Only 31% of software projects succeed, according to the Standish Group.¹
• Large IT projects routinely exceed budgets by 45% and deliver 56% less value than promised, according to McKinsey.²

For an industry so central to modern life, these failures are unacceptable. Imagine if Roman bridges collapsed at this rate or if aqueducts delivered only half the water they promised.

Yet, software developers rarely face the same level of accountability as their engineering counterparts. The absence of standards, professional licensing, and clear frameworks makes it far too easy for failures to be dismissed as inevitable. But history shows us a better way forward.

Joining the Professional Standards of Other Disciplines

For more than a century, engineering fields, including Software Engineering, have developed comprehensive Bodies of Knowledge (BoKs) to formalize their practices and guide professionals. These BoKs provide the foundation for consistent standards, shared knowledge, and accountability. Here are just a few examples:

• Civil Engineering Body of Knowledge (CEBoK)
  • First Enacted: 2004
  • Latest Version: 3rd Edition (2019)
  • Details: Published by the American Society of Civil Engineers (ASCE), the CEBoK outlines the knowledge, skills, and attitudes necessary for entry into the practice of civil engineering. It includes domains like structural engineering, geotechnical engineering, water resources, and transportation.
• Electrical Engineering Body of Knowledge
  • First Enacted: ~1963
  • Latest Version: Continuously updated by IEEE
  • Details: Spanning sub-disciplines like power systems, electronics, and telecommunications, the IEEE’s standards provide detailed guidance to ensure reliability and innovation.
• Mechanical Engineering Body of Knowledge (MEBoK)
  • First Enacted: ~1880
  • Latest Version: Continuously updated by ASME
  • Details: MEBoK covers thermodynamics, fluid mechanics, materials science, and mechanical design, ensuring a disciplined approach to creating physical systems.
• Systems Engineering Body of Knowledge (SEBoK)
  • First Enacted: 2012
  • Latest Version: 2.5 (2021)
  • Details: SEBoK focuses on designing and managing complex systems, emphasizing interactions, reliability, and scalability.
• Engineering Management Body of Knowledge (EMBoK)
  • First Enacted: 1990s
  • Latest Version: 5th Edition (2020)
  • Details: The American Society for Engineering Management (ASEM) covers leadership, strategic planning, and quality management, bridging technical and organizational skills.
• Software Engineering Body of Knowledge (SWEBOK)
  • First Enacted: 2004
  • Latest Version: Version 3.0 (2014)
  • Details: Developed by IEEE, SWEBOK outlines the key knowledge areas in software engineering, from requirements and testing to design and maintenance.

These BoKs formalize a standard of care in these fields. They balance innovation with discipline, ensuring that engineers understand the trade-offs necessary to deliver lasting value.

Our “Living Under Bridges” Moment

Software developers may not literally live under their bridges, but the failures of our industry are just as consequential. Healthcare apps can jeopardize patient safety, financial systems can cause real financial harm to individuals and economies and erode trust in our institutions, and critical infrastructure can become vulnerable to attack. The stakes couldn’t be higher.

The time has come for software engineering to join the ranks of other disciplines in professionalizing its standards. The Romans understood that innovation wasn’t enough—it had to be paired with accountability and rigor. We must learn from that lesson.

A Roadmap for Change

This blog series will explore how to bring professionalism to software development using SWEBOK as our guide. Through historical context and practical applications, we’ll make the case for adopting a Professional Engineer (PE) role in software.

Upcoming posts include:

1. You are a Quantitative Analyst (but likely not very skilled) – How economics and cost-benefit thinking can guide better decision-making.
2. Move with Intent and Make Quality Things – Why disciplined processes are the key to quality in fast-paced environments.
3. Less Simplification, More Organization – Building resilient foundations through engineering principles.
4. It’s the Requirements, Stupid! – Understanding how clarity in requirements can prevent catastrophic failures.
5. Teach Your AIs Well – Models that are built upon well-engineered, thoughtfully architected, properly decomposed software predicates produce more predictable AI outcomes.

Join us as we unpack these challenges and lay the foundation for a better future in software engineering.

References

1. Standish Group. CHAOS Report 2020. Standish Group International, Inc., 2020. ↩︎
2. McKinsey & Company. (2012, October). Delivering large-scale IT projects on time, on budget, and on value. ↩︎

Bill Udell Chief Operating Officer

Bill is happily creating a groundswell of change and innovation in the Silicon Prairie ecosystem with his buddies at Don’t Panic Labs. He can be found regularly at community events or busily working in coffee shops and boardrooms to create opportunities for collisions of entrepreneurs, community leaders, and the ecosystem.

See Full Bio