Most software is poorly designed and built. This statement comes as no surprise to anyone in the software industry and is elucidated well by Charles Mann in his popular article "Why Software Is So Bad". I have proposed a framework for better software architectures in my article "Most Software Stinks", which served as one of the sources for Mann's piece. But even if everyone accepted my proposal for improving software design (which they don't), there is still a problem. How do we get software designers and programmers to raise the quality of their work? Because few people ever see their immediate product (the source code), what would motivate engineers to do better? The answer is that all source code should be open and included in every software release. This single policy change would have a profound impact on the quality of software systems worldwide.
When you drive across a bridge, its design is open for inspection. You can see the overall structure, the method used to anchor the cables, the thickness of the roadbed, and so forth. If you want a closer look, you can walk the bridge and see more detail. The same is true of housing construction and automobile design. You can see both the outward appearance and the inner structure of these engineering products. With a little effort and some background knowledge, it is possible to independently evaluate the design and construction of these objects. Some internal parts may require extra work to see, such as underwater bridge pilings, roof trusses, or automobile crankshafts. In principle, though, there is nothing to stop you from examining them, and experts routinely do so.
Software, on the other hand, is a crucial piece of engineering that is shrouded in secrecy. Experienced software developers cannot look into the source code of Raytheon's air traffic control system, Windows XP, or a dental X-ray machine to see how they are built. We cannot see the number and depth of comments in the code, the calling sequence of the routines, the clarity of the variable names, or the simplicity of the executable statements. This fact makes software vastly different from other important products. We cannot see whether we are buying junk or quality. The physical equivalent would be a new bridge with all structural parts encased in impenetrable black plastic, and the builders asking us to trust them that everything is okay. As a public safety measure, we never would allow this. Similarly, few people would buy a house if the contractor refused to allow a home inspection prior to the sale. Unfortunately, this is how we buy software. Software systems have a huge global importance, but their structures are hidden from independent inspection.
This secrecy is the key reason we have such lousy software. Software designers, programmers, and managers get away with bad code because no one outside their small workgroup ever sees it. Developers write code they are ashamed of because they are pretty sure no one will look at it. Managers encourage engineers to write "quick and dirty" code to meet the next project milestone, with confidence they will not be held accountable for their part in the poor result. I have personally witnessed these actions and suspect most other software professionals have as well. Commercial software is filled with bad design, horrible coding style, inefficient algorithms, and snide comments (or no comments at all).
The solution is to release all software with a copy of its source code. This is currently the practice with nearly every other engineering discipline, because their designs are open for visual inspection and physical testing. In addition, each software developer, designer, and manager should attach their name to the sections of code they work on. All code (good or bad) would be traceable to the people who created it. This sunshine policy would improve software quality for two reasons. Everyone involved in the software creation process would take more pride in their work because their names would be on the code. And any buyer who cared to could inspect the source code to make sure they were getting good quality. Of course, not every software buyer has the expertise to perform this inspection, but some do.
I can picture software executives everywhere clutching their chests in horror at this proposal. What about intellectual property rights? Wouldn't software companies engage in widespread theft of each other's hard work? No, they wouldn't, because this is already covered by copyright law.
Consider the novels of Tom Clancy. The implementation of his writing (the words on the page) and the underlying structure (thematic development, characterization, and so on) are fully open for anyone to inspect. There is nothing obvious to prevent me from stealing these items for my own novel. In practice, however, there are many barriers to my doing so. First, it is not easy to produce good writing just because I have read some. If it were so simple, everyone would write like Shakespeare or Steinbeck. Second, someone else's writing may not plug cleanly into what I am trying to accomplish in my novel. Finally, stealing Clancy's words as my own is illegal. Mr. Clancy has plenty of ways to punish me should I write a book that has the same story line or people as one of his bestsellers. The fact this system works is illustrated by the current problems of historian Doris Kearns Goodwin, whose career has been nearly wrecked by accusations of plagiarism.
Stealing software is just as difficult as stealing literature, for the same reasons. Reading Knuth does not make me as good a programmer as he. It is notoriously difficult to plug software fragments into another program, as is shown by the frustrations of the software reuse movement. And software companies have the same copyright protection for their source code as novelists do for their writing.
Note that I am not advocating open source licensing for commercial software. This is an important point. Companies and other organizations can still own their source code, just as Tom Clancy is the owner of his writing. The licenses for source code can be as restrictive or permissive as each company chooses. But the source code would be visible.
Software businesses traditionally protect their source code like family jewels. Companies claim they do this to guard their property. In fact, the real reason often is that the software is so bad it is embarrassing. If Raytheon, IBM, Microsoft, Oracle, and so forth are producing good software products (as they claim), let's see the code. Opening up commercial source code is a necessary step toward solving the widespread problem of poor software quality.
Biography
Charles Connell is president of CHC-3 Consulting, teaches software engineering to corporate and university audiences, and writes frequently on computer topics.
IE 7
Firefox 2.0
