Software isn’t a skycraper

Michael Daconta at Government Computer News has posted a brief call to arms for the software industry. Here’s the gist:

Although I am a believer in free markets and the benefits of competition, industry has a responsibility to work together on the foundational layers to build security, quality and reliability from the ground up to advance the professionalism of the field. In essence, the information technology industry must emulate other engineering disciplines, or technological disasters and cybersecurity holes will worsen.

Daconta is uneasy with the number of platforms and methods available to software developers, and sees ever-more options and disruptions in the near future; IPv6 and 64-bit computing seem to trouble him particularly. We’re already balkanized and disorganized, how can we possibly expect to produce reliable and useful software with all this messy innovation happening?

The answer, of course, is control. Lots of it. Specifically, three proposals:

  • Licenses for software developers
  • A new, reliable, layered software platform developed by the NSF and DARPA
  • Treat software like engineering, not art.

Gracious. I barely know where to start. Let’s try to imagine the software development world in five years, with these proposals in place.

Software development is now a licensed activity. Like an architect or a mechanical engineer, you have to pass an exam and perhaps post a bond to practice the discipline. There’s probably a professional association, like the America Bar Association or the American Medical Association, to administer the credentials.

This licensing regime is actually a pretty good idea, because all software has to be developed according to some very specific methods, with plenty of testing and documentation to back it up. So rather than letting any fool with a compiler write software, they’ll have to spend a year or two learning the right way to write code. The process is cumbersome, but every piece of software that gets compiled is perfect. At least, as perfect as we know how.

The licensing and formal methods are only possible, of course, because we have a government-directed platform that we must build on. Anyone who wants to run software in the government must do so on this stack.

It sounds as though Daconta would like a broad mandate for NASA-style code development. You can probably see where I’m going with this. Another way to tell the story might be:

There is now a government-owned platform that every government program is mandated to use, from clouds to mobile phones. Any software built on that platform must submit to rigorous, independent testing before it is deployed. Imagine ISO 9000 and Common Criteria having a baby with teeth. Anyone writing software must be licensed to do so in the United States. As a result, the pool of available programming talent is decimated. The costs of developing software for government rise, naturally.

The pool is further diminshed because developers who want to work with the latest hardware or software no longer work for agencies or contractors — they’ve wandered back to the private sector, where they can enjoy the fruits of the free market. The government software platform quickly begins to show its age, since the only developers on the platform are those that are paid to use it. Platforms that people truly want to use are in the open market, innovating at their leisure, out of the reach of government agencies.

As the government is no longer able to consume most commercially available software, it is now back in the business of writing software itself. More accurately, it is back in the business of hiring system integrators to write that software on its behalf. It’s the 1970s all over again. Budgets explode, and innovation grinds to a halt. It’s all the agencies can do just to tread water. System integrators, of course, are delighted. They’re now commanding outrageous salaries for the few programmers trained and willing to work on this mandated government platform.

Let’s hope there’s a better way.

This doesn’t diminish the problem that Daconta is hinting at, of course. Software reliability is certainly something to worry about. But there is no single solution or set of policy prescriptions that will solve the problem. I don’t think that imposing additional controls on the development of software makes sense, certainly not for all cases. There are already robust certification regimes and methods for software that does very important work: fly an airplane, control a nuclear reactor, and so forth. We don’t need that kind of scrutiny on my game console or desktop.

It’s important to note that these robust certifications only evaluate the software itself, not the people who make it. This is what’s great about software: we can examine the final product before it’s distributed. I don’t really mind if my software is written by a clever 7 year old. If it’s doing the job it’s supposed to, that’s fine with me.

This focus on ends, rather than the means, is something you can’t do with a building or an airplane. With software, we can change our minds with far fewer consequences. We can thoroughly test and scrutinize before it’s in a customer’s hands. When we do find a flaw, it’s easier to patch software than it is a 777 or a skyscraper. We should take advantage of that fact, not try to make software rigid and inflexible just because we know how to manage rigid and inflexible things. Because software has these unique properties, we have the freedom to bring more or less scrutiny to bear, depending on the circumstances. Which is what we’re doing already, through programs like the federally-funded Software Engineering Institute at Carnegie Mellon.

So where Daconta sees mayhem and chaos, I see creativity and innovation. There are many opportunities to improve the reliability of our software, but none of them have to do with the process by which we arrive at a particular piece of code. Projects like David Wheeler’s OpenProofs, for example, can provide the tools we need to be mathematically sure software is doing what we intended. The Linux Test Project does this for Linux, and it was inspired in no small part by governments’ Common Criteria mandates.

This is, in fact, how the process should work. The government should set the requirements for reliability and assurance, and allow the private sector to innovate its way toward those requirements. If we only create software that we can understand perfectly, we lose the ability to be creative, to innovate, and to take advantage of the collective intelligence and cleverness of millions of software developers. We will never eliminate risk in software, but we can manage that risk, not through more stringent controls, but by encouraging as many smart people as possible to address the problem.

About Gunnar Hellekson

I’m the Chief Technology Strategist for Red Hat’s US Public Sector group, where I work with systems integrators and government agencies to encourage the use of open source software in government. I was recently named co-chair of Open Source for America and one of Federal Computer Week’s Fed 100 for 2010. I’m an active member of the Military Open Source working group, the RHCE Loopback, and a GTO-21 commissioner. I also help run Red Hat’s gov-sec mailing list. I perk up when people talk about cross-domain security, edge innovation, and interagency collaboration through the open source model. Prior to joining Red Hat, I worked as a developer, systems administrator, and IT director for a series of internet businesses. I’ve also been a business and IT consultant to not-for-profit organizations in New York City. During that time, I spearheaded the reform of safety regulations for New York State’s electrical utilities following the tragic death of Jodie Lane. When I’m not spreading the Good News about open source, I’m wishing I had a dog. You can find what I’m reading on Goodreads, what I’m saying on Twitter, and what I’m listening to on

2 Responses

  1. Gunnar,

    Great post with excellent, cogent points. I’d also point out that the current acquisition, development and C&A processes are ALREADY deeply flawed, as they come out of a mentality of rigorous ‘up-front’ requirements management and testing, which leads to long, slow software projects which are out of date technically long before they are ever fielded. This may work well for buying missiles and tanks, but it is far too slow for software development.

    One can argue a lot of things about what we are doing with, but one of the fundamental things we are trying to push is a change in the software development culture to one that is closer to what is represented by Agile software development (to wit: early and continuous involvement of the customers and other stakeholders).

    The days of attempting to ‘read the minds’ of the users for government software need to stop. The most powerful part of Open Source is not necessarily the fact that you can see the code (though that helps). The success of projects like Linux, Apache, etc. is largely due to their use of continuous collaboration/discussion/debate about what features and requirements need to be addressed.

    Government contractors will soon have to start living in this world, with the recent passage of HR 2647 (specifically section 804), which reads in part:

    “The Secretary of Defense shall develop and implement a new acquisition process for information technology systems…to be designed to include:

    1. early and continual involvement of the user;
    2. multiple, rapidly executed increments or releases of capability;
    3. early, successive prototyping to support an evolutionary approach; and
    4. a modular, open-systems approach.”

    We’ve already proven this out on a small scale with itself, which was built from the ground up in 180 days, a feat that still makes government folks sit up and take notice.

    I’m under no illusion that successful implementation of this (and the ideas you put forth above) is going to require anything but a huge sea-change in both government and contractor behavior. However, I don’t believe we can continue to carry a mentality of ‘business as usual’ in the software space. We are up against adversaries who *DO* understand the value of true collaborative software development.