I found this piece at U. S. Naval Naval Institute by Captains Scot Miller and Charles Deleot and Manfred Koethe thought-provoking. I think they’re looking at the right problem—bad software:
According to the Consortium for Information and Software Quality (CISQ), in 2020 the United States wasted $2.08 trillion on bad software and its effects—nearly 10 percent of U.S. gross domestic product! The naval services’ estimated budget for fiscal year 2021 is about $207 billion, suggesting the Sea Services may lose $20 billion in 2021 to the effects of bad software. If the Navy was wasting $20 billion per year in fuel, then command dismissals, inspector general investigations, and Congressional inquiries would follow.
If read their analysis correctly, they point the finger at the following culprits:
- Agile development
- Software developers’ guilds
and propose a dedication to Model-Based Systems Engineering as a solution. I think they’re pointing in the wrong direction and, should their proposal be adopted, it will ultimately prove disappointing.
The authors quote one old wisecrack (“garbage in; garbage out”). Let me quote two more:
- A camel is a horse designed by a committee
- An elephant is a mouse built to military specification
“Agile development” can be summarized as the ability to respond to changes in requirements. I have seen good agile developments and bad ones. The difference is generally due to the “product owner”—the individual responsible for determining the scope of the development. Scope creep is impossible when the requirements and specifications of a development are rigidly enforced and that’s true regardless of the development methodology. Scope creep is all too easy when the needs are poorly defined and the product owner has deep pockets. Military projects, whether building a jet fighter or invading Afghanistan, are all too subject to scope creep. If you try to tell me otherwise, I’ll have some of what you’re having.
The authors provide no examples of these “guilds”. There’s a good reason: they don’t exist. There have been attempts at creating such things many times over the last 70 years but they’ve all failed. If they had succeeded there would be no such thing as offshoring software development or staffing companies like Tata.
What do exist are corporations with proprietary products. That has been true since computers were invented and it will inevitably frustrate the authors’ vision. As soon as the MBSE generators they imagine have been developed, those corporations will all change their products to elude them. That, too, is the history of computers.
Software development tools are already evolving to solve the problem the authors identify in a different way. The latest approach is called “low-code/no code”. See also “digital transformation”. While effective those tools are proprietary, too. Their promise is to bring software development closer to the end users and reduce its costs. That has been tried under different guises a dozen different times over the years. The latest strategy will founder for the same reason past approaches have: not everybody wants to be a programmer or has the required mental equipment.
