The Penguin Ping.
Want on or off? Just holla!
Posted on 08/27/2002 5:07:42 AM PDT by ShadowAce
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.
Charles Connell is president of CHC-3 Consulting, teaches software engineering to corporate and university audiences, and writes frequently on computer topics.
How do you get furniture makers to raise the quality of their work?
By demanding it, or shopping somewhere else.
Think different.
Copyright (C) 2002 - isthisnickcool
Want on or off? Just holla!
Copyright laws would prevent someone from reusing the EXACT same code, but wouldn't a few minor changes here and there constitute a whole new program? Example: a famous chef has his own recipe for grilled salmon. He will not publish the recipe because other chefs would use it and simply substitute or add one ingredient and thus have a "new" recipe.
Complicated programs are made up of many smaller bits of code. Would the copyright protect each of these smaller bits of code individually? Or could they be taken and used elsewhere?
By opening the source of software, we (as a society) can examine, critique, and improve it. However, the author would still retain all ownership, with all the commercial benefits that entails.
And we will have the Party Central Committee FORCE those who continue to resist this universal truth. If their source isn't open, let them be sure that the Gulags ARE.
I test drove the cars to get my own impressions, and checked information widely available in the market on the pros and cons of each car.
Why do you think there is information widely available? Cars are, essentially, open-source. If they were welded shut, with no access to the internals, how could you trust a test-drive or two? How would you know how well they are built? They might last for five years then just fall apart.
In that vein, you, personally, wouldn't be requireed to look through the source code for SQL Server, but you would know others have. And if no one raises a fuss over it, or if they praise it, you would know from an independant source that it was a good product.
Oh, bullsh*t. Now he's talking about something that I, as a bridge engineer for some years, know about.
The fact is that very little of a bridge's "health" can be readily discerned by the casual observer.
The bridge in Oklahoma that collapsed earlier this year, did so only months after an inspection by trained inspectors. If he wants to use some kind of analogy, this ain't it.
Oh, and I have no idea how my CD player works. I squint a bit, and I can see some doohickeys and thingamabobs in there, some of which appear to go round and round, but I couldn't tell you if the thing's working correctly or about to give up the ghost.
Note that I am not advocating open source licensing for commercial software.
And, as someone who knows very little of bridges, even I knew that one was weak.
Couldn't be that much. You responded, afterall.
Cars are cars. Software is software.
The analogy doesn't hold up.
No one on the OSS side is asking for leaving commercial software code wide open. Isn't it amazing how the detractors will misconstrue the argument anyway?
Of course, this expense is onerous, not only for designing and writing, but for testing and deployment. We have tried changing our philosophy more and more away from the "give the user what he wants at all costs" to "give the user a bulletproof tool that works WELL." Feature bloat is a problem (see the "office suites" whose every addition is probably useless and only adds to unreliability and user confusion), especially if a competitor says, "I can do this and Jammer cannot!"
However, I have a problem with distributing source code. The ultimate test is whether the software is adequately tested before deployment to ensure reliability and with enough error trapping (both user and program) to prevent disaster. Other than that, how can a user evaluate software? I cannot evaluate Windows source code. But, I can tell something is sucking wind when, for example, Win2K has to be reloaded when it capriciously loses the administrator and user passwords.
Constructive negative comments are welcome.
Yep, it's a fair cop. You got me there.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.