How SpaceX does software for 9 vehicles with only 50 developers — and gov’t requiring 50x the staff

The biggest gap in the government today is enterprise services. You go to big companies, they have infrastructure cloud team, they have a platform team, you don’t have each software team building the entire stack from scratch. They can reuse all these existing enterprise capabilities in terms of testing, security.

 

You go to SpaceX, they have a team to approve software tools in 24 hours. They have a testing team to do full emulation of the rocket before you fire it. 17,000 times a day they can push software into production. I brought 50 key members of the Air Force software team to SpaceX to see how they build rockets and software. The fact that they have 50 developers at SpaceX to build the software for all nine vehicles, where we would probably have at least 2,500 in the government to do the same thing, it’s something where people have to open up and ask what are we doing things that are completely wrong.

That was Nicholas Chaillan, chief software officer for the Air Force on the Executive Perspective podcast. Chaillan estimates that SpaceX is writing working software for just 2 percent of the resources it would have taken the government to do, most likely through a cost-plus contract to industry. In other words, software developers are 50 times more effective at SpaceX than in the traditional way of doing business.

After all, nine launch vehicles would probably have been under nine separate contracts, each with its own estimate as to building the software full stack. This is part of the reason why Chaillan is excited about the JEDI enterprise cloud services, that it will reduce effort not just for cloud but the cybersecurity that can be inherited.

One of the problems with the weapon system concept is that the entire program effort is supposed to reside in a budget line item controlled by a single program office. It was meant to remove the need to coordination across the enterprise. It was not meant for multifunctional systems, and so we’ve seen a complex bureaucracy around shared services evolve but it doesn’t seemed to have worked out to a great extent. More effort, it appears, needs to go into enabling enterprise services which can dramatically reduce the effort for any given platform or application. But the program office was explicitly created to remove overlapping responsibilities.

Something else that comes to mind is how enterprise tools should normally be an indirect cost expensed to the current period, even if the fixed costs will benefit efforts on many contracts in future periods. In other words, government contracting actually discourages what SpaceX is doing for efficiencies, because these costs cannot be easily matched to specific contract revenues. A government auditor may come back later and incorrectly say, “hey, you’re making huge profits!” Cost accounting isn’t about facts necessarily due to the problem of matching expenses and revenues, and other subjective estimates. And so contractors are incentivized to build full stack because that is auditable, and in any case beefs up the costs upon which profits are based.

2 Trackbacks / Pingbacks

  1. How SpaceX Develops software - Coders Kitchen
  2. SpaceX and an agile mindset

Leave a Reply