From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FROM_WORDY, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: "Ken Garlington" Subject: Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Date: 2000/08/01 Message-ID: #1/1 X-Deja-AN: 653039936 References: <8ipvnj$inc$1@wanadoo.fr> <397D8CC3.BB0C9001@ix.netcom.com> X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Complaints-To: abuse@flash.net X-Trace: news.flash.net 965095199 216.215.76.173 (Mon, 31 Jul 2000 20:59:59 CDT) Organization: FlashNet Communications, http://www.flash.net X-MSMail-Priority: Normal NNTP-Posting-Date: Mon, 31 Jul 2000 20:59:59 CDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-08-01T00:00:00+00:00 List-Id: "Kent Paul Dolan" wrote in message news:hwoh5.3977$ED.168424@news.wenet.net... > Ken Garlington wrote: > >"Kent Paul Dolan" wrote: > >> For those interested in how to write better software, the language is > >> not the issue. > > >Certainly, language is not the *only* issue, but it can have an effect on > >your defect rates. > > Software folk wisdom is that any programmer can write awful code in any > language; I most recently found that reiterated by Bjarne Stroustrup in > his special edition C++ textbook. I think neglecting language issues > to focus on process issues is going to pay off faster than the opposite > approach, and also that until you have some good process in place, the > best programming language in the world (since this is crossposted, I > won't mention her name right here) isn't going to offer much relief. There's two bad assumptions here: (1) "Software folk wisdom" is better than data from controlled case studies. This is CMM level 2 thinking at best. (2) Considering languages issues and "process issues" is mutually exclusive. Not true - you can (and should) consider all sources of error in an effective software quality program. (For example, although Brooks discusses a number of process issues, he also notes that "programming productivity may be increased as much as five times when a suitable high-level language is used.") > I'd rather think of it as a computer specialization of well known > management science approaches. What I was taught in formal education > as "computer science" had nothing to do with what these people used to > achieve their astonishing software error rate. Certainly, there may be formal computer science programs that don't offer software engineering courses. However, I'd guess that most programs today do not consider these as mutually exclusive. I've taken a number of courses in both management sciences and software engineering. Although there's some overlap (as there is with many other engineering fields, such as petroleum engineering and chemical engineering), I don't think you could honestly consider it as just as "specialization" of management science. > Yep, they spent about four times the industry average per SLOC for that > software. From my point of view, that just means the industry _way_ > underfunds software development, with the results we all know and > detest. However, there are groups that get the same results as the space shuttle program at significantly less cost. Again, when you look at the case studies vs. "folk wisdom," the results may be surprising. > Software _looks_ so simple, and the estimates are _so_ optimistic, that > the old well worn ideas: "you will always build a prototype, some > groups just find that out later than others", paraphrasing Fred Brooks, > get ignored in doing the up front cost estimates. This group as part > of its mandatory, customer funded process, builds and throws away one > complete prototype, just to assure that they know where the software > problems are going to arise, _before_ starting coding, or finalizing > architecture or design, on the deliverable software. Interestingly, Brooks withdrew this advice in the 1995 edition of Mythical Man-Month, as it tends to assume the waterfall model. He suggests in his revised book that an incremental-build model is better. In fact, one of the specific models he describes is the Microsoft "build every night" approach! > It's when you find out that software productivity, between competent > practitioners, can vary by 100::1, and that all the testing in the > world lets buggy software out the door, that you begin to realize that > software is not simple, not well understood, not well managed, and not > well accomplished, with vanishingly few exceptions, the one under > review being one of them. However, CMM level 4 companies are finding that they (a) can control variation in the software development process, putting the lie to the "100:1" variation that was seen when there was no attempt to control the process and (b) can use things such as formal inspections to significantly reduce error rates earlier in the process than traditional testing.