The Balance Problem: When Safety-Critical Teams Over-Focus on Documentation and Under-Focus on Working Software

In software engineering, few slogans are quoted—and misunderstood—as often as the Agile Manifesto’s value: “Working software over comprehensive documentation.”

Importantly, Agile never advocated eliminating documentation. Instead, it warns against allowing documentation to overshadow the real product: the software itself. In safety-critical domains, however, the reality is often reversed. Because compliance frameworks such as DO-178C, ISO 26262, IEC 62304, and others emphasize artifacts and traceability, teams may inadvertently over-prioritize documents and under-invest in producing robust, verified, high-quality code.

This blog explores why this anti-pattern emerges, how it harms software quality, what DO-178C and Agile actually say, and what a healthy balance looks like for high-assurance environments. Ultimately, it is the software itself—rather than the supporting documentation—that executes within the production system.

Documentation in DO-178C: Evidence, Not a Substitute for Engineering

DO-178C requires extensive documentation — requirements, design, traceability matrices, test plans, test results, reviews, analyses, tool qualification data, and configuration management records. These artifacts are part of the certification evidence and make the safety case visible.

However, DO-178C never states that documentation alone assures software quality. In fact, it requires rigorous verification activities including:

• Code reviews and conformance to coding standards (e.g., MISRA C/C++)

• Structural coverage analysis (statement, decision, and MC/DC)

• Static and dynamic verification

• Complexity analysis

• CPU/memory profiling and timing verification

Thus, while documentation is essential for traceability, auditability, and certification, it does not replace the fundamental need to build reliable, predictable, high-integrity software.

Figure: 61% of DO-178C objectives relate to software verification process, highlighting the importance DO-178C gives to ensuring software quality through rigorous verification and standards compliance.

The Anti-Pattern: Excessive Documentation, Insufficient Working Software

In many safety-critical organizations, the pendulum swings too far toward documentation. Requirements refinement loops, design reviews, specification discussions, and paperwork dominate the development phase. Meanwhile, the software itself remains under-tested, inadequately reviewed, or sometimes poorly implemented.

Why This Happens in Actual Teams

Several common factors contribute to this imbalance:

1. Lack of Software Engineering Expertise

Many avionics and embedded software teams are composed largely of electrical or systems engineers whose core expertise lies in hardware design, integration, and understanding system-level behavior. While these skill sets are essential, they do not always include deep training in rigorous software engineering disciplines such as formal verification, unit-testing methodologies, static and dynamic analysis techniques, or managing software complexity through architectural patterns. Moreover, modern development workflows—code reviews, branching strategies, CI/CD pipelines, automated testing frameworks, and other best practices—may fall outside their traditional engineering background. As a result, these teams often gravitate toward documentation-heavy approaches, focusing on specifications, interface control documents, and system descriptions, because these artifacts align more closely with their comfort zones. This can unintentionally lead to an underestimation of the engineering rigor, precision, and iterative refinement required to develop high-quality, dependable software for safety-critical systems.

2. Dominance of Systems Engineers in the Workflow

Systems engineers often adopt a documentation-centric approach because their responsibilities revolve around defining requirements, managing interface control documents (ICDs), specifying functional behaviors, and overseeing validation and acceptance testing. When such roles take the lead in software development activities, the emphasis can naturally shift toward producing and refining requirements and design documents. While these artifacts are essential, this imbalance may inadvertently reduce attention on software craftsmanship, code quality, and the intermediate verification steps necessary to build robust, certifiable software.

3. Unrealistic Schedules Reduce Verification Activities

When teams operate under tight delivery pressures, the natural response is to prioritize activities that create rapid, reviewable outputs—such as completing requirement documents, finalizing design artifacts, and ensuring that formal milestones can be passed. While this approach helps meet short-term deadlines, it often leads to the unintentional non-prioritization of critical engineering tasks like static analysis, unit testing, performance profiling, and MC/DC coverage assessment. These activities take time, require technical depth, and do not always produce immediately “visible” deliverables, making them easy targets for compression or omission. The result is software that may be formally certifiable—because the documentation stack is complete—but not necessarily of high quality or operationally safe. In safety-critical environments, this imbalance can introduce subtle defects, performance issues, and integration risks that only emerge much later, when they are far more costly and dangerous to address.

4. Misinterpretation of DO-178C

A recurring misconception among some engineering managers is the belief that DO-178C compliance is achieved simply by producing documentation—summarized by the flawed notion, “If it’s documented, it’s compliant.” This interpretation fundamentally misrepresents the intent of the standard. DO-178C does not reward paperwork; it requires objective evidence that the software is correct, safe, and reliable. Documents alone cannot prove correctness—they merely describe engineering intent. True compliance stems from measurable verification activities such as requirements-based testing, structural coverage analysis, robustness validation, traceability demonstrations, and conformance to approved development and configuration processes. DO-178C treats documentation as supporting evidence, not as a substitute for engineering rigor. Without the underlying technical verification, even the most comprehensive documentation stack fails to meet the certification expectations for safety-critical software.

5. Lack of Tooling or Automation

Without access to modern engineering tools—such as automated testing frameworks, coverage measurement solutions, static analysis engines, continuous integration pipelines, and robust configuration management systems—teams often revert to documentation-heavy workflows to manually demonstrate compliance. In such environments, engineers spend significant time producing and maintaining evidence on paper rather than letting tools generate objective, repeatable verification results. This limitation forces organizations to rely on human-driven, error-prone processes that meet certification formality but fail to leverage the efficiency, precision, and consistency that modern toolchains provide.

Figure: The qualified tools for verification tasks of safety-critical software have very expensive licenses and are difficult to acquire. Furthermore, they may not be compatible with all IDEs.

Where Agile Actually Helps

Agile does not reject documentation; rather, it repositions it within a workflow centered around working software. Its principles emphasize the continuous delivery of functional increments, rapid feedback cycles, collaborative communication, iterative refinement, and early defect detection. Agile ceremonies such as daily stand-ups, sprint reviews, and retrospectives strengthen team alignment and significantly reduce misinterpretations—an essential advantage in safety-critical environments where multiple vendors, subcontractors, and cross-disciplinary teams collaborate on complex avionics or defense programs. Within such domains, Agile adds value by ensuring that software evolves in small, verifiable increments, issues are uncovered early instead of during certification, and communication gaps are minimized as engineers engage regularly with the software rather than interacting solely with documentation. However, Agile must be thoughtfully tailored to remain consistent with DO-178C objectives. This adaptation includes integrating incremental testing, maintaining continuous traceability, and producing documentation as a natural output of each sprint. Thus, Agile does not discard documentation; it ensures that documentation is purposeful, accurate, and organically aligned with the evolving software rather than overshadowing the development process.

Figure: SafeScrum model is an adaptation of Scrum for safety-critical systems.

The Middle Ground: Balanced Documentation and High-Quality Software

The strongest safety-critical organizations adopt an integrated approach that blends Agile pragmatism with DO-178C rigor.

1. Documentation Supports the Software, Not the Other Way Around

In high-assurance environments, documentation must serve the software—not overshadow it. Its purpose is to clarify requirements, justify design decisions, support certification audits, enable long-term maintainability, and ensure end-to-end traceability. However, the engineering focus must remain firmly on the correctness, reliability, performance, and safety of the operational software itself. Documents provide evidence and context, but they do not replace rigorous engineering. The most capable safety-critical teams treat documentation as a necessary output that enhances understanding, while keeping the core effort centered on producing robust, verifiable, and certifiable software.

2. Verification Is a Non-Negotiable Core Activity

In safety-critical development, verification activities—not documents—provide the real assurance of software integrity. Organizations must invest significantly in unit testing, integration testing, boundary and robustness testing, resource-usage analysis, MC/DC structural coverage, and static and dynamic code analysis. Equally important are code readability, in-code documentation, and clear commenting practices, all of which support maintainability and reduce safety risks. These activities form the true safety net of the software lifecycle, ensuring that the delivered product behaves correctly under all operational conditions and complies with certification standards.

3. Competency in Software Engineering Must Improve

To achieve balanced excellence, organizations must strengthen the software engineering skills of their teams. Engineers should be proficient in embedded programming best practices, test-driven development, formal verification methods, automated testing technologies, and principles of concurrency and memory safety. Strong foundational competence reduces the over-reliance on documents and elevates the team’s ability to produce high-quality code. When system engineers, electrical engineers, and software developers all share a mature understanding of software craftsmanship, the quality of the final product increases dramatically.

4. Use Modern Toolchains to Reduce Documentation Burden

Modern automation frameworks reduce manual documentation overhead while improving both accuracy and compliance. Continuous integration (CI) pipelines automatically generate test logs and reports. Coverage analysis tools produce structural coverage and traceability evidence. Static analysis platforms document coding-standard compliance without human intervention. Requirements management systems auto-link artifacts across lifecycle phases. When teams adopt these toolchains, documentation becomes richer, more reliable, and far less labor-intensive—allowing engineers to focus their efforts on building and validating the software rather than generating paperwork.

Why Balance Is Essential

Excessive documentation often leads to software that is technically “certifiable” yet lacks genuine assurance of correctness, whereas insufficient documentation results in software that may function but cannot be certified, audited, or reliably maintained. In safety-critical engineering, neither extreme is acceptable. The real objective is to produce provably correct working software, and achieving this balance requires integrating three complementary strengths: the clarity and traceability provided by documentation, the rigor of DO-178C verification activities, and the practical, iterative delivery focus of Agile methods. Only by harmonizing these elements can development teams ensure that aircraft, medical devices, industrial controllers, and automotive systems behave safely, predictably, and consistently under all operational conditions.