Slashdot Mirror

Dude - you are using ActiveX in IE *TODAY* It's a fucking design flaw. Does it matter if the article is 10 years or 20 years old?

Which part of "IT'S A FUCKING DESIGN FLAW" do you not understand?

Mark Minasi wrote a book on this: http://www.softwareconspiracy.com/ In the book, he gets on the record quotes from Microsoft/Sun/Oracle development VPs on why they put out shitty/insecure software. The answer - because the customers buy it anyway. It's people like you who hand wave shitty stuff away that's stopping the software industry from improving.

... And to put UCITA in perspective, check Mark Minasi's Software Conspiracy site.

http://www.softwareconspiracy.com

The Forum on Risks to the Public in Computers and Related Systems

While certainly all us programmers should be reading it, much of the material is accessible to anyone who knows how to use a computer, and so really should be read by anyone who uses computers for anything of importance or makes policy decisions that involve computers.

While the complexity of todays software systems make it unlikely that we'll ever have truly bug-free software, the situation can be a lot better than it is today. One thing that's needed is for the public to wake up and demand that software companies take responsiblity for their products, and to understand that they're being ripped off.

Someone who's working towards that end is Mark Minasi, the author of the book The Software Conspiracy:

There are no significant bugs in our released software that any significant number of users want fixed... The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard... And so, in no sense, is stability a reason to move to a new version. It's never a reason.

-- Bill Gates

In the world I came from pursuits like software development were supposed to be clean and pure things, exercises to stimulate and enrich the mind and advance the cause of reason and promote the betterment of human existence.

Instead the industry which appears to be the main driving force behind the tremendous recent growth of the world economy, especially the US economy, is in my opinion a cancer that is desperately in need of the surgeon's knife.

Michael D. Crawford
GoingWare Inc

The Forum on Risks to the Public in Computers and Related Systems

While certainly all us programmers should be reading it, much of the material is accessible to anyone who knows how to use a computer, and so really should be read by anyone who uses computers for anything of importance or makes policy decisions that involve computers.

While the complexity of todays software systems make it unlikely that we'll ever have truly bug-free software, the situation can be a lot better than it is today. One thing that's needed is for the public to wake up and demand that software companies take responsiblity for their products, and to understand that they're being ripped off.

Someone who's working towards that end is Mark Minasi, the author of the book The Software Conspiracy:

There are no significant bugs in our released software that any significant number of users want fixed... The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard... And so, in no sense, is stability a reason to move to a new version. It's never a reason.

-- Bill Gates

In the world I came from pursuits like software development were supposed to be clean and pure things, exercises to stimulate and enrich the mind and advance the cause of reason and promote the betterment of human existence.

Instead the industry which appears to be the main driving force behind the tremendous recent growth of the world economy, especially the US economy, is in my opinion a cancer that is desperately in need of the surgeon's knife.

Michael D. Crawford
GoingWare Inc

There are no significant bugs in our released software that any significant number of users want fixed... The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard... And so, in no sense, is stability a reason to move to a new version. It's never a reason.

-- Bill Gates

While Slashdot discussed the government's reluctance to accept Open Source in Linux -- Government Acceptance vs. Actual Use, apparently our Nation's proud warriors have no problem putting our nation at risk at the hands of a closed-source operating system as evidenced in USS Yorktown dead in water after divide by zero. The mighty Yorktown had to be towed back into port after its NT network crashed when a sailor entered a "0" into a data entry field.

I haven't read it yet, but by the looks of the web page The Software Conspiracy looks pretty worthwhile too:

There are no significant bugs in our released software that any significant number of users want fixed... The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard... And so, in no sense, is stability a reason to move to a new version. It's never a reason.

-- Bill Gates

Until the public wakes up and realizes they're being ripped off the situation will continue.

For us developers, this is a matter of taking responsibility for our work. For the public (and us developers when we purchase software) it is a matter of demanding that the vendors take responsibility: refuse to purchase software whose End User License Agreement disclaims a warranty, and demand of your legislators that the government enforce minimum quality standards on software and quality products.

At the very least you should be able to get your money back on a defective product, even if the manufacturer disclaims responsibility. And if there are real costs associated with the failure, as when a friend of mine bounced a $4000 check because of a bug in Microsoft Excel, the injured party should be able to sue for damages.

I've spent most of my career fixing somebody else's broken code.

This is not to say that my own has always been of the very highest quality, but in fact I decided early on to try to come to a fundamental understanding of what was wrong with software development, to get very good at debugging (I say that debugging is a specialty on my homepage) and to learn to write better code.

In my early years I was initially very shocked at what I'd discover in production use at companies. Over the years I just learned that that's standard practice, in commercial software, in-house software, and even in scientific software (where I have become convinced, because of my experiences with high-energy physics data analysis, that many scientific papers are published with erroneous measurements because of software bugs).

Early on I read that something like 90% of software development is spent doing maintenance programming. Some of this is doing legitimate upgrading, but a lot of it is just spent fixing bugs, and even a lot of time spent doing upgrades would be more productive if the code were of better quality.

After reading this figure and having so many experiences with software bugs, both other people's and my own, I decided very early on to get very good at debugging.

One of the first things I did was adopt the regular use of "lint" for checking my C code. I would integrate lint targets into my makefiles and after editing a source file I would type "make lint" before compiling to objects and lint would check all the files that were out of date with the object modules. Pretty quickly I got to where I could write code that was nearly always lint-clean - but the existing code I worked on would make lint scream with hundreds if not thousands of complaints, often serious things like variables being used before they are initialized.

One of the first solid clues I got about software quality came from Robert Ward's book "Debugging C" - now out of print, it predated the common use of source code debuggers and talked about how to write your own stack crawls and other tools.

Ward emphasized the use of the Scientific Method in debugging, and because I was trained in physics, this came very naturally to me; before that I'd mostly floundered and used printf a lot.

I've gotten very good at debugging and have even worked full-time as a debugger at Apple Computer where I was a "Debug Meister" and my business card gave my title as "Cybernetic Entomologist".

I can easily get highly paid consulting work doing debugging for companies desperate to ship a product (and have in the past) but I don't really like to do it for various reasons, some of the same reasons I quit my debugging job at Apple.

One is that if I only do debugging I don't have something to point to at the end of the day and say "I wrote that". I could say "that works because of me", but sadly there's usually lots of bugs left that I didn't have the time to find so I don't really feel proud of the result. The other problem is that the bugs are usually not there because of something interesting, it's not like the code is mostly good but there's some subtle flaws, rather the code is a heap of dung and I can go in with a pitchfork and do debugging wholesale until I get tired of it and the client or manager decides the rate new bugs are being found is low enough they can feel OK about shipping it.

I don't feel good about contributing to such shoddiness. If a company is not good enough to support quality in their corporate culture I don't want to come in and put on a band-aid for them. It would be an entirely different thing if a company hired me to restructure their development process so that quality was a goal that was achieved through direct application of process but gee whiz no one has ever asked me to do that for them.

I do have to say though that the best thing that ever happened to me is that I became a "technology prostitute" as the author of the original article puts it. One benefit of this is that the process is entirely of my own creation, and almost all of the work I've been given has been to write entirely new products from scratch, so I can engineer in quality from the beginning.

Here's a few recommendations I have. Get good tools. Besides a compiler, editor and debugger, you need a static code checker and you also need dynamic testers. The ones I know about are (I haven't used them all yet):

• PC-Lint static code checking for C and C++. It runs on Windows but Flexe-Lint comes as shrouded source code and is highly portable.
• Spotlight dynamic tester for Mac PowerPC - I use this every day and recommend it highly
• BoundsChecker dynamic tester for Windows
• Purify dynamic tester for Unix (but apparently not Linux) and Windows NT
• Optimizeit dynamic tester for Java - do you know many Java programs have memory leaks? Can you understand why? Not just Java but any garbage collected program.

Finally, to really come to understand the software quality problem in the industry and what you can do about it, read The Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks. The book The Software Conspiracy exposes the complete disregard the commercial software industry has for serving the consumer by providing quality products - I haven't read it yet but it looks interesting.

A very interesting methodology that emphasizes personal responsibility and puts the fun back into programming as well as maintaining quality from the very start is Extreme Programming. I'm starting to adopt extreme programming (the the extent a one man operation can - I can't work in pairs :-/ ) and find it a tremendous benefit.

The Forum on Risks to the Public in Computers and Related Systems

The Software Conspiracy

While there will always be quality problems in software, current practice in many companies is to not even try to do the basic things that tend towards improving software quality. Until the public wakes up and realizes they're being ripped off, and their safety and corporate information being put at risk, we will always have this problem.

One solution is to get every programmer in a company a copy of some good quality tools, static analysis tools like PC-Lint and dynamic (runtime) analysis tools like Spotlight (for the MacOS) or BoundsChecker (for Windows) or Purify for Unix (but apparently not Linux) and NT.

As a Spotlight user and a long-time reader of the Risks forum, I wouldn't dream of shipping a Mac product unless it tested absolutely cleanly under Spotlight and had zero memory leaks.

But it is amazing to try Spotlight on a mature commercial product for the first time. Think you're program's free of bugs? Guess again. I proposed using Spotlight to my manager, on our program which had been shipping for several years and cost $600 retail. It was a serious product for high-end users. My manager said it would be a waste of time because "Our program has so many bugs, Spotlight would keep finding them and progress would be very slow." And you know, he was right. I persisted anyway, and spent three months ferreting bugs out of that program with Spotlight.

There's a lot of tools out there (and there's tools like these for Java too, like OptimizeIt - do you know many Java programs have memory leaks?). You don't have to pick the tools I recommend, but look out for what's available there and make sure you have something for every developer seat in the house.

It will be the best investment you make. The $199 for Spotlight will be paid for in the day it's first used.

And free software writers, I suggest writing free software versions of these. It would be possible in principle to write a special version of gcc, or an command-like option to it, that when your program is linked to a special library all your memory accesses are boundschecked. Note that Spotlight can validate memory reads as well as memory writes.

If you think programmers can really escape liability for their products (or should), think about what kind of effort and investment companies like the tobacco industry and auto manufacturers of automobiles and childrens toys and food put into defending themselves from lawsuits and government regulation.

It's only a matter of time before the public rises up and demands accountability for software. Imagine a senator getting elected on the platform of promising to put programmers behind bars for writing software that is unreliable. Or a district attorney setting out to put programmers behind bars, not for hacking or writing viruses, but for writing products that don't meet government standards.

I haven't read it yet, but the Software Conspiracy looks interesting.

There are no significant bugs in our released software that any significant number of users want fixed... The reason we come up with new versions is not to fix bugs. It's absolutely not. It's the stupidest reason to buy a new version I ever heard... And so, in no sense, is stability a reason to move to a new version. It's never a reason.

I have a good friend who worked at the Learning Company for quite some time, and he told me no end of horror stories about an utter disregard for engineering quality, lack of concern for usability, maintainability of code or anything that sounded remotely like common sense. They'd basically just ship all their applications when they could get them to more or less run and not when they were running reliability.[sic]

And this somehow distinguishes them from the rest of the sofware industry? Not a chance. Check out Mark Minasi's http://www.softwareconspiracy.com/ book for more info, but the dirty "secret" of the software industry is that darn near all software development is done like that today. It shouldn't be, but it is. I've seen enough to know - the hardware mfrs are even worse...