When I was at GOMAC in Albuquerque at the end of March, I ran into a couple of Cadence people and a couple of Green Hills people. Everyone left except one of the Green Hills guys, since he was staying in a different hotel. He turned out to be John Warther, who is their government guy based in Washington. We got to talking about software development and he asked me if I'd read the government report that had been released just a week or so before: Software is Never Done: Refactoring the Acquisition Code for Competitive Advantage. It is a huge 130-page document, but John sent me his own copy, where he'd highlighted what he considered the most important conclusions. I've since come across another summary document from a couple of weeks later: Software is Never Done: Refactoring the Acquisition Code for Competitive Advantage (yes, it has the identical name, but it's not the same document at the link).

This second document is only 15 pages long, so rather more approachable. To whet your appetite so that it is interesting, let me give you the contents:

Chapter 1. Who Cares: Why Does Software Matter for the DoD?
Chapter 2. What Does It Look Like to Do Software Right?
Chapter 3. Been There, Done Said That: Why Hasn’t This Already Happened?
Chapter 4. How Do We Get There from Here: Three Paths for Moving Forward
Chapter 5. What Would the DIB Do: Recommendations for Congress and DoD

How the Government Buys Code

It turns out that the government buys code the same way automakers do (except Tesla). I happened to read a Monday Note by Jean-Louis Gassée this morning (I'm writing this on Monday) that had the perfect quote:

To conventional automakers, software is a sourced component, often from the lowest bidder, a hard-to-control annoyance.

The government and the military treat software the same way. In essence, it purchases software like hardware. You produce a spec, the product is developed, and then you are done. But software is not like that. As the title of this report puts it succinctly "the software is never done". Automotive companies (OEMs in their terminology) and DoD organizations typically don't even have the source code, and can't even rebuilt a release. The subcontractors typically keep that.

I have been through some of this experience myself when I've worked for semiconductor executives who have been brought into companies like Cadence to get some of that "semiconductor discipline" into software development. But, as the title of this paper makes explicit, the software is never done. You tape out a chip and you are done. But you ship the first release of an EDA tool, and you are not done. I don't just mean that there will be bugs to fix. That source code will be the basis of tools in that part of the product line for ten years or more. Even though SoCs use a lot of IP and design-reuse, the corners you can cut are different. If a block of IP has an issue, you can fix it for your chip. If a software component such as timing engine has a problem, you have to fix the timing engine back at whatever team owns it. Otherwise, forevermore, you will have two timing engines with different behaviors. And since the software is never done, you'll have to maintain both of them forever.

The conclusion of the DoD report has three main themes:

1. Speed and cycle time are the most important metrics for managing software. To maintain an advantage, DoD needs to procure, deploy, and update software that works for its users at the speed of mission need, executing more quickly than our adversaries. Statutes, regulations and cultural norms that get in the way of deploying software to the field quickly weaken our national security and expose our nation to risk.
2. Software is made by people and for people, so digital talent matters. DoD’s current personnel processes and culture will not allow its military and civilian software capabilities to grow nearly fast or deep enough to meet its mission needs. New mechanisms are needed for attracting, educating, retaining, and promoting digital talent and for supporting the workforce to follow modern practices, including developing software hand in hand with users.
3. Software is different than hardware (and not all software is the same). Hardware can be developed, procured, and maintained in a linear fashion. Software is an enduring capability that must be supported and continuously improved throughout its lifecycle. DoD must streamline its acquisition process and transform its culture to enable effective delivery and oversight of multiple types of software-enabled systems, at scale, and at the speed of relevance.

There are four main recommendations from the report (the big report breaks these down into smaller actionable steps):

• Congress: Create new statutes streamlined for software, providing increased insight to reduce the risk of slow, costly, and overgrown programs, and enabling rapid deployment and continuous improvement of software to the field.
• OSD: Create cross-program/cross-service digital infrastructure that enables rapid deployment, scaling, testing, and optimization of software as an enduring capability; manage them using modern development methods; and eliminate the existing hardware-centric regulations and other barriers.
• Services: Establish software development as a high-visibility, high-priority career track with specialized recruiting, education, promotion, organization, incentives, and salary.
• Contractors: Adopt DevSecOps practices/culture; prioritize speed as the critical metric.

Timeline for action: We need to start now (FY19-FY20); inaction has serious consequences.

Summary

I realize that most readers of this post are unlikely to read a 130-page document on this topic, or perhaps even the 15-page summary. But there is also a 3-page TL;DR (TL;DR stands for "too long, didn't read" and I believe originated at Reddit, where people would put a one-line summary of a long post).  If you have any involvement in software development for defense, aerospace, or even automotive, this is three pages worth reading.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.