Keep Bringing the Juice Boxes

Sadly this book, “A Seat at the Table”, by Mark Swartz,  is the worst book I’ve read in a long time.  Heralded by the Chief Software Officer of the United States Air Force, Nicolas M. Chaillan, as a must read, I believe we are being led down the primrose path by the likes of personalities such as Swartz and Chalillan.  The buzz word in software is DevOps and whether or not we believe software is key to every business, and the business of most businesses, the tenants of DevOps are not new to the real business of innovation.  Recast as some sort of new  knowledge, when it comes to rapid development of anything, look through history at the companies who have found rapid ways to develop new things and get them to the marketplace, and the exact same rules will apply.  Nothing new here.  Even when applied to software.  What is new is the idea that the Chief Information Officer at a company should be in charge of it.  The danger, as I see it, is not with how the next Uber or Airbnb will get their app to market. The danger is that some companies are not strictly software development houses, They also do other things, like build cars, planes, and rockets.  Coming from a military background I’ll rephrase that as tanks, planes, rockets, and satellites.   Yes, the software development involved with these systems is extensive, 35 million lines of code and counting on programs such as the F-35 (including ground support systems), but so too must these companies also build the hardware that works, physically, and the hardware that supports and runs the software at the interface between the physical world and the digital logic inside..   The world does not consist strictly inside your desktop, laptop, and iPhone.  At least not yet.  The world is still a physical place.  And thus we must still interact with it in physical ways. Engineers build these physical systems.  Deeper still, is the need for these software driven physical systems to be secure.  This does not happen on the software side alone. Thus even if the CIO understands not only IT but software as well, they will not understand the other product development in other engineering disciplines.  They still are in a heavily supporting role.   

In the old days a company consisted of the CEO, COO, and CFO.  Typically, before the days where everybody wanted an MBA, engineering companies would advance, not necessarily the best engineers, but the good engineers who could communicate with the outside world.  Those smart folk would rise to the top and it was hard to compete with them because of their deep knowledge of what the company was actually in the business of producing. As the information age blossomed, companies began creating positions like the Chief Information Officer or CIO to run their Information Technology enterprise.  So let me just ask a question, who do the software developers work for?  Do they work for the CIO or do they work for the CEO?  In an information company, where software applications, games, webpages, shrink wrapped software are the products, do the software developers work for the CIO?  In a hardware company where the product is the next business jet, do the software developers work for the CIO?  The answer is no.  The fallacy here is that the CIO needs  a seat at the table.  The misunderstanding here is that the CIO drives the DevOps cycle.   What’s happening here is because of the surge in software development in every company, the CEOs and COOs understand less about the technology.  That is why if you put a software engineer in charge, like Elon Musk at Tesla, he is smart enough to speak all of the languages he needs to speak  in order to run the company.  The CIO can play his supporting role to keep the networks up so that everyone can do their job. The software engineers do not work for the CIO at Tesla, or SpaceX for that matter.

Hopefully you understand where I am going with this.  I like CIOs, don’t get me wrong, but giving them a seat at the table to drive DevOps when the software developers don’t work for the CIO is a dumb idea.  And it would be an even dumber idea to put them in charge of software development thus splinting the development of an integrated engineering solution.  Software might be the cool magic in any given hardware, who doesn’t love the artificial intelligence of a self driving car?  But the car can only drive because it has cameras that can see, radars that can feel, tires that can turn, and brakes that can stop the car. This is a fully integrated engineering hodgepodge of technology that must remain on the engineering side of the house under the CEO.  The CIO has other things to worry about, like making sure the engineers can communicate with one another and have sufficient juice boxes delivered.  Driving DevOps is for engineering management and whereas it may have arrived for commercial companies it is still not ready for primetime in the military...nor should it ever be.

The United States Air Force, as the foremost technology service,  has been enamored with this book and with other fantasies about Silicon Valley.  Thus the Air Force appointed a Chief Software Officer to drive software development into a DevOps future.  Yes, Chaillan has started a few software companies.  He has not, however, built a F-16, a B-2, or a MilStar Satellite.  Yes all companies can do better with their software development cycles, but  they still must build hardware.  They must build an integrated solution.  They still must test hardware and they still must secure everything from attack.   DevOps is antithetical to building defense systems that must work in a life and death situation while also under attack from both within (cyber) and from without (physical).  In this still highly relevant paradigm the CIO is still in a supporting role and should still just keep bringing the juice boxes.