Why Software Sucks
from the no-design,-bad-coding-practices,-test-afterwards dept
So why does software suck so much? Some people just accept the fact that all software is buggy, but others think it’s a problem in how software is written. They say a lot has to do with the fact that very few people actually design software any more. People come up with an idea for software, and then they start coding away. Along the way they test things, and fix bugs as they pop up. The article suggests if software engineers were more methodical in the process of designing software to work properly instead of just writing up some code, there wouldn’t be as many bugs in their code.
Comments on “Why Software Sucks”
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
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
Blame?
My big problem with the article is how it tries to lay the blame entirely on the software developers:
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.