alex@am.sublink.org (Alex Martelli) (03/17/91)
I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature frenzy" around, products are sold mostly on feechurs, secondly on time-to-market, thirdly on price, and QUALITY just does not seem to be on the list. I am trying to redirect the discussion to c.s-e, because it does not really seem peculiarly relevant to the world of 386 Unices: I estimate that I spend between 25% and 40% of my time fighting with bugs, BAD bugs, in compilers on all sorts of workstations, in debuggers, in linkers, in system libraries, in RDBMS's, in utilities of all descriptions... I'm TIRED! of this, but it does not seem to be getting any better as time goes on: everything keeps getting faster and shinier and richer - but quality stays low. I do NOT need umpteen extensions to language standards, which I will NOT use anyway since I want to write PORTABLE software; I do NOT need compilers pushing the envelope in hyperdimensional crosseverything optimization for a 7.2% speedup, when the hardware itself is yearly doubling in performance; I do NOT need linkers that will rearrange my code, inline called-once procedures, and make coffee in the morning; I DO need BUG-FREE, *STABLE* software tools, an ar that will not silently munge my archive if it's over 512 entries, a dbx that won't throw me into a wild goose chase by showing the WRONG address for a symbol, a vi that won't dump core when i hit ^D to cancel autoindent and enter some text... What can be done about it? I believe there is a whole shift in emphasis needed throughout the market: magazines and consulting organization should put benchmarks and feechur-lists into the second tier and start ferreting around for BUGS; customers should insist on followup releases to make software SOLID, rather than add chrome (such followups are today ignored as "just a bug-fix release"...); marketing teams should figure out a way to sell based on QUALITY - "our product does NOT dump core, it does NOT munge your data, it does NOT show wrong results"... CAN it really be so hard as all that??? In other markets, after all, there ARE at least a portion of suppliers that do well by selling high-quality, durable goods, where the buyer can rely on their not breaking unexpectedly, rather than the "latest fads"; why, even in our own 'hardware' field there are such markets. Why not in sw too? -- Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).
EGNILGES@pucc.Princeton.EDU (Ed Nilges) (03/19/91)
In article <1991Mar16.171033.380@am.sublink.org>, alex@am.sublink.org (Alex Martelli) writes: >I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature >frenzy" around, products are sold mostly on feechurs, secondly on >time-to-market, thirdly on price, and QUALITY just does not seem to be >on the list. I am trying to redirect the discussion to c.s-e, because Amen, Alex: but as to why quality is so little valued in software, look at the recent discussion on counting "lines" of C code. This discussion took a badly-defined goal (counting lines of code in a free-form language) and provided several solutions, none of which worked. The only solution that does work is to count statements according to the strict Backus-Naur form definition of the language but the attitude appears to be that this is "too complicated" and that pseudoclever one-line sed or awk "tools" are more useful. It's not just marketing that's at fault: it's an unholy alliance of marketing, impatient for software that sells, and managers who have forgotten that software is difficult and takes time. It's also the time-honored anticompetitive practises of the industry, in which the big boys announce software, then run to the back room, chain the programmers to their desks, and start cracking the whip. Although IBM pioneered this, Microsoft is now under FTC investigation for exactly the same sort of practises (New York Times, 3/13/91, p. D1.) >tools, an ar that will not silently munge my archive if it's over 512 If I had ten dollars for every time a programmer said, that number will never exceed n, I'd be as rich as Billy Gates...the address width of the IBM 360 is a good example. It is easy to avoid magic numbers and to use malloc in place of static allocation, but these techniques don't seem to be taught. >-- >Alex Martelli - (home snailmail:) v. Barontini 27, 40138 Bologna, ITALIA >Email: (work:) martelli@cadlab.sublink.org, (home:) alex@am.sublink.org >Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; >Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only). Ah, that explains it: the guy's from a foreign country. Here in the United States many of the concerns Alex raises are simply beyond the ken of many programmers, since the educational system does such a poor job in teaching students how to read/think/do math. In the States we laugh at the Soviets and their lag in technology. When I give seminars in C programming at a company in Chicago that has hired Russian emigres, the performance of the emigres is MUCH MUCH better than that of the US students. This is because (1) these students learned real math including the calculus in grade school and (2) the very lack of personal computers taught these students how to think critically about their code, as "desk-checking" is still a prized skill in Soviet research institutions where Behemoth is still the machine of choice. It was a joy to teach these students C based on Backus-Naur syntax and hand-execution in preference to "put it on the machine and see if it breaks." If programming is going to survive as a profession, programmers need to design in quality even when management doesn't ask for it. Why? Because when the lawsuits begin when the software fails, managers will point to the programmers as being at fault. And, like the guy peddling oatmeal on the boob tube says, writing quality code is "the right thing to do." +--------------------------------+ Edward G. Nilges | Child support, tax-deductible | Princeton University | to payer AND receiver: an idea | Information Center | whose time has come. | Bitnet: EGNILGES@PUCC +--------------------------------+ (609) 258-2985
chip@tct.uucp (Chip Salzenberg) (03/21/91)
According to alex@am.sublink.org (Alex Martelli): >In other markets, after all, there ARE at least a portion of suppliers >that do well by selling high-quality, durable goods, where the buyer can >rely on their not breaking unexpectedly ... A recent RISKS article (comp.risks) quotes an IBM paper to the effect that 30% of the bugs in a widely-used OS did not show up until an average of 5000 running years. High-quality software is difficult. Given that bugs will constantly be discovered, I think the best we can reasonably ask is a serious effort to fix bugs NOW instead of saying, "Wait until the next release." Of all the vendors I've worked with, the one that comes closest to the ideal in this respect is (gasp) IBM. We just got an RS/6000, and each and every bug that I've reported has been dealt with. Some are still pending (gotta love bureaucracy), but two bugs were solved with fixes sent by overnight express. More significantly for this discussion, they have never said, "Fixed in the next release," unless they said in the same breath, "and let me send that to you now." Whatever you want to say about IBM, they take support seriously. -- Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip> "All this is conjecture of course, since I *only* post in the nude. Nothing comes between me and my t.b. Nothing." -- Bill Coderre
alan@tivoli.UUCP (Alan R. Weiss) (03/22/91)
In article <12600@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: [much good flaming deleted ... lots of stuff to chew on]. >If programming is going to survive as a profession, programmers >need to design in quality even when management doesn't ask for it. >Why? Because when the lawsuits begin when the software fails, >managers will point to the programmers as being at fault. And, >like the guy peddling oatmeal on the boob tube says, writing >quality code is "the right thing to do." >+--------------------------------+ Edward G. Nilges >| Child support, tax-deductible | Princeton University >| to payer AND receiver: an idea | Information Center >| whose time has come. | Bitnet: EGNILGES@PUCC >+--------------------------------+ (609) 258-2985 This actually raises a different but related question: when the lawsuits begin, WHO IS AT FAULT? Can we distiguish between "at fault" and "legally liable?" Possible culprits: 1. Marketing people 2. Senior management (i.e. officers of the firm) 3. Development management 4. Developers/programmers 5. Quality Assurance management 6. QA engineers 7. The customer In keeping with the spirit of Usenet and news, I'll make my choices after I hear *your* input :-) OK, I'll give in a little: it sure as hell isn't the customer's fault (i.e. "the market made me do it"). _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 "No business would dare say these things!" _______________________________________________________________________
jerry@TALOS.UUCP (Jerry Gitomer) (03/22/91)
alan@tivoli.UUCP (Alan R. Weiss) writes: |In article <12600@pucc.Princeton.EDU| EGNILGES@pucc.Princeton.EDU writes: |[much good flaming deleted ... lots of stuff to chew on]. ||If programming is going to survive as a profession, programmers ||need to design in quality even when management doesn't ask for it. ||Why? Because when the lawsuits begin when the software fails, ||managers will point to the programmers as being at fault. And, ||like the guy peddling oatmeal on the boob tube says, writing ||quality code is "the right thing to do." ||+--------------------------------+ Edward G. Nilges |This actually raises a different but related question: when the lawsuits |begin, WHO IS AT FAULT? Can we distiguish between "at fault" and |"legally liable?" Possible culprits: |Alan R. Weiss TIVOLI Systems, Inc. Whoever the judges and juries elect to find at fault! Like marketing issues this has nothing to do with logic, but is a matter of perception. Jerry -- Jerry Gitomer at National Political Resources Inc, Alexandria, VA USA I am apolitical, have no resources, and speak only for myself. Ma Bell (703)683-9090 (UUCP: ...{uupsi,vrdxhq}!pbs!npri6!jerry
jls@rutabaga.Rational.COM (Jim Showalter) (03/24/91)
>This actually raises a different but related question: when the lawsuits >begin, WHO IS AT FAULT? Can we distiguish between "at fault" and >"legally liable?" The corporate entity, as is true in any other product liability case. -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."
thayne@unislc.uucp (Thayne Forbes) (03/26/91)
alex@am.sublink.org (Alex Martelli) writes: >I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature >frenzy" around, products are sold mostly on feechurs, secondly on >time-to-market, thirdly on price, and QUALITY just does not seem to be >on the list. I don't profess to be any kind of authority on this, because my experience has been somewhat under protest. However, allow me to espouse a trite philosophy that I believe is original. (If not, someone point me to a reference). That is: Software evolves into the product that is being tested in QA. I was stuck at a vendor sight for several months testing a product that 'they' thought was ready to go any day now. I consistently found bugs that they had never seen (4-5 a day). And the telling response was "Well why would anyone want to do that" >What can be done about it? I believe there is a whole shift in emphasis >needed throughout the market: magazines and consulting organization >should put benchmarks and feechur-lists into the second tier and start >ferreting around for BUGS; That was part of the problem with this product. Our customer (DoD) had already decided what the features were going to be, and our vendor had the attitude that all they had to do was meet that criterion. And meet it on schedule. And without spending so much time that they lost all their profit on our prearranged price/unit. Do you see how quality got to be fourth on their list?? Thayne Forbes (Unisys, Salt Lake City, Ut) thayne@unislc.UUCP || {att, hpda, sun, uplherc}!unislc!thayne || (801) 594-4826 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- # The opinions expressed above are my wife's, but she said I could use them.
alan@tivoli.UUCP (Alan R. Weiss) (03/26/91)
In article <jls.669769186@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >>This actually raises a different but related question: when the lawsuits >>begin, WHO IS AT FAULT? Can we distiguish between "at fault" and >>"legally liable?" > Hiya, Jim. You kind of begged the question, but your point is valid. However, in many negligence cases the officers of the company are also held personally liable (the unfortunately classic example is the Union Carbide Bhopal disaster).. Anyway, back to my main concern: who is at fault? _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 ObDisclaimer: I speak for myself, not my company _______________________________________________________________________
kambic@iccgcc.decnet.ab.com (03/26/91)
In article <497@tivoli.UUCP>, alan@tivoli.UUCP (Alan R. Weiss) writes: > In article <12600@pucc.Princeton.EDU> EGNILGES@pucc.Princeton.EDU writes: > > [much good flaming deleted ... lots of stuff to chew on]. > > This actually raises a different but related question: when the lawsuits > begin, WHO IS AT FAULT? Can we distiguish between "at fault" and > "legally liable?" Possible culprits: > > 1. Marketing people > 2. Senior management (i.e. officers of the firm) > 3. Development management > 4. Developers/programmers > 5. Quality Assurance management > 6. QA engineers > 7. The customer > IMHO I believe that there is something called "strict liability" coming into play here, like if you did the code, you did it, and you had better be able to say why and show that it was the best possible code that could be done that way. Then find a lawyer. Preferably a software lawyer. How about a legal knowledge assistant? GXKambic standard disclaimer
egnilges@phoenix.Princeton.EDU (Ed Nilges) (03/26/91)
In article <1991Mar25.171643.3461@unislc.uucp> thayne@unislc.uucp (Thayne Forbes) writes: > >That was part of the problem with this product. Our customer (DoD) had >already decided what the features were going to be, and our vendor had >the attitude that all they had to do was meet that criterion. And meet >it on schedule. And without spending so much time that they lost all >their profit on our prearranged price/unit. Do you see how quality got >to be fourth on their list?? > >Thayne Forbes (Unisys, Salt Lake City, Ut) Thayne, this illustrates my point that software designers have a dual responsibility. They are of course responsible to management and they must in some sense do what they are told. But they are also responsible to themselves as a profession, if only to avoid liability when mission-critical software breaks. In the New York Times for March 24th, a group from your own company (UniSys) comes in for criticism because of the nonworking status of a new weather radar system. The article, on page a1 and with no byline, states that a consultant from the Patents and Trade Marks office (Thomas Giammo) claims that "Air Force testers had given Unisys's computer programming office its lowest rating." The article did NOT make clear that a company such as Unisys has many computer programming "offices": but imagine agreeing to management demands for down-and-dirty, bug-ridden products and several weeks later opening the paper to read that the quality of the system you worked-on has been decried to the extent that the Unisys system was decried. Or worse, getting a letter from a lawyer accusing YOU of poor practices after you fought for quality and lost.
jls@rutabaga.Rational.COM (Jim Showalter) (03/27/91)
>In article <jls.669769186@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >>>This actually raises a different but related question: when the lawsuits >>>begin, WHO IS AT FAULT? Can we distiguish between "at fault" and >>>"legally liable?" I didn't actually write that. I responded to it. Sigh: aren't BBS's fun? -- ***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd ever be able to find a company (or, for that matter, very many people) with opinions like mine. -- "When I want your opinion, I'll read it in your entrails."
alan@tivoli.UUCP (Alan R. Weiss) (03/29/91)
In article <1991Mar25.171643.3461@unislc.uucp> thayne@unislc.uucp (Thayne Forbes) writes: >alex@am.sublink.org (Alex Martelli) writes: >>I agree with Dick Dunn's lament on c.u.sysv386 - there is a "feature >>frenzy" around, products are sold mostly on feechurs, secondly on >>time-to-market, thirdly on price, and QUALITY just does not seem to be >>on the list. >I don't profess to be any kind of authority on this, because my experience >has been somewhat under protest. However, allow me to espouse a trite >philosophy that I believe is original. (If not, someone point me to a >reference). That is: Software evolves into the product that is being >tested in QA. I was stuck at a vendor sight for several months testing a >product that 'they' thought was ready to go any day now. I consistently >found bugs that they had never seen (4-5 a day). And the telling response >was "Well why would anyone want to do that" Thayne: Does Unisys still have a Product Assurance and Support (PA&S) function? Long ago, I worked in PA&S at Burroughs (later Unisys)-Camarillo plant. Or, has Unisys gutted THAT like they've destroyed most things? (For those of you who are hard at work at a Unisys facility, my sincere apologies for sounding so negative. But I remember when the Burroughs name MEANT something, dammit, and when quality really mattered. Yeah, the engineers bitched about Phase Review, and Corporate Systems Management was something to be a little feared. But schedules were met, and quality was good, and profits were at least a *little* bit present. Then the political hacks took over: Blumenthal especially.... Again, nothing personal). _______________________________________________________________________ Alan R. Weiss TIVOLI Systems, Inc. E-mail: alan@tivoli.com 6034 West Courtyard Drive, E-mail: alan@whitney.tivoli.com Suite 210 Voice : (512) 794-9070 Austin, Texas USA 78730 Fax : (512) 794-0623 "I speak only for myself, not for TIVOLI" _______________________________________________________________________