Reader Comments

Subscribe: RSS

View by: Time | Thread

• 

  Adam Barr, 17 Jun 2002 @ 7:48pm

  
  

  interesting article, but...

  It's a good overview of current gripes about software, but the article is mish-moshing a lot of things together. For software, it talks about embedded control systems, operating systems, compilers, medical machines, and web servers. For what constitures a bug, it talks about bloated code, ugly code, inefficient code, badly designed code, buffer overflows, bad algorithm implementation, incorrect handling of badly entered data, and of course the ultimate in cataclysmic chaos -- an app that generates unnecessary Windows messages. For how to fix things, it mentions component-based design, exhaustive review of source code before compiling, better initial planning, better programming tools, highly-typed languages like C#, better measuring tools, and never deferring bugs. For the goals that should be aimed for, it talks about usability, reliability, cost effectiveness, and maintainability.

  So that's all fine and dandy, but it's not like you can just take one from each column and have something that makes sense. For example, were bugs in an operating system due to inefficient code that would be fixed by component-based design with an eye towards cost effectiveness? Well, uhhh, maybe, I think.

  It didn't help that so many of the people quoted had no idea what they were talking about, and the ones who did had their quotes taken so far out of context that they made no sense. It seems a lot of people who never worked at Microsoft know how Microsoft develops software. Oh well.

  It would make more sense to talk about a particular class of software and bug and then discuss why it is there. E.g. why do Microsoft systems products have buffer overflows. Even then you would get a bunch of different answers (of course, if you want the real answers, "I discuss that in my book"(tm) -- but also here and here).

  - adam

  [ link to this | view in chronology ]

  • 

    Charles C. Mann, 18 Jun 2002 @ 11:45am

    
    

    Re: interesting article, but...

    "It didn't help that so many of the people quoted had no idea what they were talking about, and the ones who did had their quotes taken so far out of context that they made no sense."

    As the author of the piece, I'd be interested to learn a) why Nathan Myhrvold, Peter Neumann, the folks at SEI, and the other people I spoke with don't know what they're talking about; and b) how you know I quoted them out of context. Have you read the transcripts of my interviews?

    "It seems a lot of people who never worked at Microsoft know how Microsoft develops software."

    I think the people whom I spoke with at Microsoft -- as well as the ex-Microsoft developers -- know how the company develops software. I mean, didn't you read the article?

    "It would make more sense to talk about a particular class of software and bug and then discuss why it is there. E.g. why do Microsoft systems products have buffer overflows."

    Not in an overview article, which is what this is. This complain reminds me of Dawn Powell's complaint that much criticism boils down to the remark that if you were driving my car you'd go to some other destination. Well, fine, but it's my car -- I wanted to write, and was asked to write, an overview.

    --Charles C. Mann

    [ link to this | view in chronology ]

• 

  Doug P, 17 Jun 2002 @ 10:53pm

  
  

  Blame?

  My big problem with the article is how it tries to lay the blame entirely on the software developers:

  • "signs that the software’s developers were too rushed or too careless to fix obvious defects."
  • "'The attitude today is that you can write any sloppy piece of code and the compiler will run diagnostics,' says SRI’s Neumann."
  • "Software engineers know that their code is often riddled with lacunae, and they have long been searching for new technologies to prevent them."
  • "Incredibly, Humphrey says, the design for large software projects is sometimes 'nothing but a couple bubbles on the back of an envelope.'"
  • "The inadequate design in the final products, critics argue, reflects inadequate planning in the process of creating them."
  • "In an exhaustive examination, Nancy Leveson, now an MIT computer scientist, assigned much of the blame to the manufacturer’s inadequate software-engineering practices."
  • "'It’s just a fact that there are things that other engineers can do that we can’t do,' says Shari Pfleeger, a senior researcher at the Rand think tank..."
  • "Battered by such experiences, software developers are becoming more attentive to quality."
  • "Critics welcome calls for excellence like those from Kestrel and Microsoft but argue that they will come to naught unless commercial software developers abandon many of their ingrained practices."
  • "When engineers inside a software company choose to ignore a serious flaw, there are usually plenty of reviewers, pundits, hackers and other outsiders who will point it out."
  • "'We don’t learn from our mistakes,' says Rand’s Pfleeger."

  In my experience, the problem has not generally been the ignorance or the arrogance or the laziness of the software developers. The problem has been the impatience and miserliness of their employers. Software developers cannot be expected to create solid software when under intense pressure to "ship something, anything!" in as short a time as possible.

  On a completely separate note, the article is incorrect about the Ariane 5 rocket failure having been due to a buffer overflow. It was caused, as such things almost always are, by a long chain of events. One of those events was an arithmetic conversion overflow (from floating to integer), not a buffer overflow.

  [ link to this | view in chronology ]