Dr. Dobb's Journal March, 2005
Licensing & Such
Dear DDJ,
The same day I read Jan Galkowski's letter in the January 2005 issue of DDJ, I watched a TV news story that included the following information:
When the Insurance Institute for Traffic Safety crash-tested the 2005 Hyundai Elantra, the driver's air bag failed to deploy. According to their press release, "Hyundai engineers will modify the software that determines whether and when to fire the airbags in 2005 models built after December 2004. The company also will recall cars manufactured earlier to fix this problem." (To refresh my memory, I looked this up at http://www.hwysafety.org/news_releases/2004/pr121904.htm.)
Why do you suppose the Hyundai "engineers" didn't get the software right the first time? I suspect they wrote it the same way most software is written, waiting for (to use Jan's words) "end-user critiques, complaints, and bug reports" to reveal "incorrect expectations or documentation."
I agree with Jan that this typical software-development process is not desirable, but I don't think we necessarily have to tolerate it. I think we can make the case that there are times when software-development standards should take precedence over our employers' need to be successful. I also believe that adopting standards will, ironically, make many businesses more successful in the long run.
Software that is intended to help people make decisions usually comes with a disclaimer that the vendor is not liable for the users' bad decisions. However, software that actually makes decisions, such as when to deploy an airbag, should be held to a higher standard. The owner of a construction company would expect a building engineer to refuse to proceed if appropriate specifications weren't available. Otherwise, they both might get sued for violating well-established standards, i.e., building codes. I agree with Brent Fulgham (DDJ, August 2004. "Letters") that the public will eventually demand standards for the development of software that affects public safety. I don't think these standards should be required for other software, but they should be strongly recommended.
I agree that we would have to grandfather existing software. Automakers, for example, would not be required to recall every car that uses old software, just those that turned out to be defective using current testing methods. However, I don't think it is ridiculous to expect them to start using standards to write or rewrite any software used in new cars. As for outsourcing, it wouldn't matter where the software was written. If the car were driven in the U.S. (or any country that adopted standards), the standards would apply.
There is a precedent for holding companies accountable for their software-development process. In my June 2004 DDJ letter to the editor, I noted that the FDA inspects the software specification and documentation procedures of medical equipment manufacturers. (See http://www.eweek.com/article2/0,1759,1543652,00.asp?kc=EWNWS030804DTX1K0000599 for more information.) However, as Jan points out, there's not much hope of finding acceptable procedures as long as the people who are supposed to know what the software is expected to do cannot describe these expectations in sufficient detail.
I have colleagues who believe that users are so stupid that they deserve the lousy software they get. I disagree. It has been my experience that business people can be taught how to create sufficiently detailed specifications. Accurate and complete specifications not only lead to better software, but often lead to business improvements that have nothing to do with software. However, accurate and complete specifications are time consuming to create and have little short-term benefit. Since decision makers are usually unwilling to wait for long-term benefits, I don't expect most of them to adopt this approach unless they are forced to (which they should be if they produce products that affect public safety). Once standards have been established, however, some businesses that have nothing to do with public safety will realize the long-term financial benefits of standards-based software development. Unfortunately, many will continue to be short-sighted; and I will continue to point this out whenever I encounter them. My long-term goal, by the way, is that someday I will be able to say, "my code is up to code."
Jim Wiggins
jwiggins@ifbf.org
Dynamic Caching
Dear DDJ,
I enjoyed the article "Dynamic Caching & ADO DataSet" by John Cheng and Hong Rong (DDJ, December 2004), which was a useful introduction to smart caching of larger datasets and pointed out some of the drawbacks of the relatively simple default behavior of ADO.
However, I would like to pick up on an error in the example in the text for an incremental query. If a partial set of employee data ordered by fname and lname is retrieved and the last record is "Joe Smith," then it is incorrect to request incremental data by adding the clause where fname > 'Joe' and lname > 'Smith' to the original query.
Alas, a few seconds thought should demonstrate that neither the original query nor the subsequent one would locate my record, given my first name is "Roger" and my last name is "Orr." The incremental query needs to be more carefully thought through if more than one column is used for the ordering: one solution would be: where (fname = 'Joe' and lname > 'Smith') or fname > 'Joe').
Roger Orr
rogero@howzatt.demon.co.uk
Strange Bedfellows
Dear DDJ,
I enjoy Dr. Dobb's Journal a great deal. In particular, I read Jonathan Erickson's "Strange Bedfellows" editorial (DDJ, December 2004) and I don't get what he doesn't get.
IBM and Open Source are not an unlikely pair—they are the most likely pair. IBM, according to publicly disclosed financial results, is now about 75 percent services and hardware, making it the largest hardware and the largest services company in the world rolled into one. Based on this profile, IBM is the most likely company to ally itself with open-source software. Joel Spolsky expounded on this more than two years ago (http://www.joelonsoftware.com/articles/StrategyLetterV.html) and what he wrote then is still basically true now: IBM is commoditizing the complement to its core business.
Imagine a hypothetical future world, 15 years from now, where through twists of fate, there is no software except open-source software. Which of IBM's competitors of 2004 remain in that hypothetical world? Come on, IBM has every reason to embrace and endorse open-source software today. That this fact still surprises people surprises me.
Dino Chiesa
dinoch@microsoft.com
DDJ