Carlos Macedo Gomes wrote: > > I like these laws even better: > > George's Laws on Programming > > 1. There is no such thing as a programming bug. A bug was the moth that > Grace Hopper pulled out of her vacuum tube computer. What programmers > like to call bugs are defects - defects in workmanship - defects in > quality.
A rose by any other name... Why do you feel it is important that defects are not called bugs? > 2. There are two types of defects: Design and Implementation. > a. Design defects are a direct reflection on the Software Architect's > inability to properly design a robust program, or to interpret Business > Requirements. > b. Implemetation defects are a direct reflection on the developer's > inability to either do what he/she is told, or his/her inability to ask > questions about requirements they do not understand. I'd add: c. "Features" or design requirements that are not reasonable to implement and yet are demanded by people in charge. I include in this unrealistic deadlines, limited time budget for testing or other work and other decisions made by those not doing the work. > 3. When software defects kill people, the Software Engineering industry > will have no choice but to become a credible engineering discipline like > mechanical engineering, electrical engineering, and architecture with > the accompanying reviews and professional certifications. I don't believe this will ever happen, in general. Let me explain. A. Software used in places that could kill people is already covered under various standards of scrutiny and "credible engineering discipline." Quick examples: Aircraft software: http://www.faa.gov/aircraft/air_cert/design_approvals/air_software/what_is_air_software/ Defense: http://en.wikipedia.org/wiki/MIL-STD-498 replaced in 1998 by http://en.wikipedia.org/wiki/IEEE_12207 Medical devices: http://www.ieeeboston.org/edu/2007spring/course_sw_for_med_dev.htm (The above are just quick hits that point or infer to various standards of development process and documentation for these industries.) Software engineers who work in these fields are already required to follow various disciplinary practices while creating their software. There is little incentive to bring all software engineers into such practices. B. Software is a commodity. MS has used it's market dominance to maintain it's high prices but the reality is that every day software is more and more of a commodity. Except for specific niche products, it is no longer a viable business model to use "traditional" high discipline practices to create software. It would cost far too much for the market value. FS/OSS is embracing this reality and continues to drive general market pricing downward. Even with out FS/OSS, this trend would still occur because the production cost of software, once written, is almost nothing. C. The value of harnessing "chaotic" software development is huge. Witness the Linux kernel. The cost to develop the 2.6 version of the Linux kernel is estimated at between $176M and $612M (http://www.dwheeler.com/essays/linux-kernel-cost.html for one report). And that is just the value of only the kernel! Full engineering discipline required of all software developers would be a barrier to harnessing such value. I can think of a few other minor reasons, like: The high changeability of both the requirements and software. Or that software development is more about communication that it is about hard processes. But the above are at the top of the list. With the continued growth of FS/OSS, I think the software development profession will continue to proceed down the path toward something like plumbers or carpenters. There will be "stars" in the field that create new and interesting "pipe fittings" or "truss braces." And there will be some who are "real engineers" with full discipline because of how the software they write will be used. But most people working as software developers or software engineers will simply be earning a decent living putting the known pieces and processes together for people who need something out of the ordinary. And that is not a bad way to make a living! Alan
signature.asc
Description: OpenPGP digital signature
--------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
