“The Department of Defense (DOD) must be able to develop and deploy software as fast or faster than its adversaries are able to change tactics,” the document reads. To this end, the board made up of private sector and academic tech leaders has 10 suggestions for how DOD should approach and think about software acquisition.
Each commandment “builds on the lessons learned in the software industry,” bringing what the board, led by Alphabet technical adviser Eric Schmidt, considers to be best practices from the private sector to the attention of the Pentagon.
“These principles are not universal and may not apply in all situations, but they provide a framework for improving the use of software in DOD operations going forward that we believe will provide substantial improvements compared to the current state of practice,” the document states.
Richard Murray, a professor at the California Institute of Technology, delivered the contents of the commandments:
- Make computing, storage, and bandwidth abundant to DOD developers and users.
- All software procurement programs should start small, be iterative, and build on success‒ or be terminated quickly.
- Budgets should be constructed to support the full, iterative life-cycle of the software being procured with amount proportional to the criticality and utility of the software.
- Adopt a DevOps culture for software systems.
- Automate testing of software to enable critical updates to be deployed in days to weeks, not months or years.
- Every purpose-built DOD software system should include source code as a deliverable.
- Every DOD system that includes software should have a local team of DOD software experts who are capable of modifying or extending the software through source code or API access.
- Only run operating systems that are receiving (and utilizing) regular security updates for newly discovered security vulnerabilities.
- Data should always be encrypted unless it is part of an active computation.
- All data generated by DOD systems – in development and deployment – should be stored, mined, and made available for machine learning.
“We anticipate updating these as we go and we learn more,” Murray said. “The point is to say these are the types of things that the Department of Defense needs to be thinking about in the context of software.”
The DIB got to work “updating” almost immediately,
“I have a proposed additional commandment,” Schmidt quipped at the end of the list delivery. “Which is, ‘thou shalt count the number of programmers you actually have.'”
Apparently, this is a common issue of concern for Schmidt.
“It seems to me that in our meetings so far we’ve seen many many helper-types — supporters, planners, document writers, and so forth,” he went on. “But it’s a very rare event when we have a meeting with what I would consider to be programmers. One of my most fun questions is to sit in a room with 20 executives, shall we say, and say how many programmers and it turns out there’ll be two — of which one is being transferred for some stupid reason to some other base.”
The issue of the military not having a defined career path for those with technical skills is something the board has talked about before — at a January meeting the group adopted two new recommendations, one of which was that the DOD create a new “Innovation plus STEM” (or I-STEM) career field. The current career structure, DIB member and Instagram COO Marne Lavine argued at the time, doesn’t really have a place for these people, so the department is missing out on hiring them.
To the individuals on the board, this is somewhat baffling. “You can be a doctor, a lawyer, a musician for your career [in the military], but you cannot be a software engineer for your career,” board member Michael McQuade noted on Thursday. The DIB wants to spark change here because, as several members noted, software is nothing without engineers.
The board will meet next July 11 at the Defense Innovation Unit Experimental offices in Silicon Valley. There may be more commandments.