Most software-program risk is not in the code
Repositories, defect counts, and sprint velocity measure the code. In complex defense programs, the higher risk usually sits outside the editor: in requirements, interfaces, data models, and integration paths that were never built for iterative delivery.
Software program risk is easy to misread. Programs can inspect repositories, count defects, review pull requests, and measure sprint velocity. Those are useful signals, but they do not usually explain why complex software programs lose control.
In defense systems, the higher risk often sits outside the code editor. It sits in requirements that cannot absorb change. It sits in interfaces that are implied rather than owned. It sits in data models that drift across teams. It sits in timing assumptions, integration paths, test environments, toolchains, and evidence packages that were never designed for iterative delivery.
What the GAO findings actually say
GAO has made the same point in more formal terms. Its reviews of defense software acquisition do not frame the problem as a simple failure to write software. GAO has reported that defense software acquisition needs changes to requirements processes, oversight, and tools to better support iterative delivery. They point to requirements processes, oversight mechanisms, and engineering tools that have not consistently kept up with modern software delivery. Agile development depends on flexible requirements, regular user engagement, outcome-based oversight, and tools that help teams understand what is being built and what value has been delivered. When those structures are missing, Agile becomes a label rather than a delivery model.
That distinction matters. Adopting Agile or DevSecOps does not remove program risk. It changes where the risk shows up.
A waterfall program can hide risk in late integration. An iterative program can expose risk earlier, but only if the architecture, interfaces, test paths, and decision rights are built to support iteration. Otherwise, teams move faster through local tasks while the program accumulates integration debt. The code changes more often, but the system does not necessarily become easier to field.
Software delivery is a structural problem
This is why software delivery has to be treated as a structural and architectural problem, not just a coding methodology. The important questions are not limited to whether a team can implement a feature. They include:
- Can the requirement change without breaking the acquisition or engineering model?
- Can the interface be tested independently?
- Can the data flow be traced across system boundaries?
- Can integration happen continuously enough to matter?
- Can evidence be generated as a byproduct of engineering work rather than reconstructed at the end?
- Can the program tell the difference between shipped code and fieldable capability?
The answer to those questions determines whether speed compounds or creates rework.
Code quality matters, but it is not enough
For complex defense software, code quality still matters. It always will. But code quality is not enough when the surrounding program cannot manage change, verify behavior, or integrate capability at the pace the mission requires. The work is broader than writing functions. It is making system behavior explicit enough to test, integrate, secure, review, and change without losing control. When that behavior stays implicit, the missing structure resurfaces later as integration failures, test escapes, and authorization delays that no amount of clean code can prevent.
That is where software program risk usually lives.