Slashdot Mirror

• Steven Bellovin, AT&T
• Matt Blaze, AT&T
• David Farber U of Pennsylvania
• Peter Neumann, SRI International
• Eugene Spafford, Purdue University CERIAS

And Peter Neumann I know very well in an online way, as he is the moderator of the Forum on Risks to the Public in Computers and Related Systems which discusses all kinds of topics in software reliability and security, and provides an ongoing archive of known software bugs.

It is also available on the Usenet News as comp.risks and I consider it required reading for anyone wishing to take themselves seriously as a programmer.

This means you.

Neumann also wrote the book Computer Related Risks which draws on material from the forum but discusses it in more depth.

He is also a frequent consultant to the government and military on computer reliability, security and computer policy as you can see from Neumann's home page.

He writes great puns too, which are often found added to Risks submissions.

Now for my contribution - I'd like to suggest you read my page Why You Should Use Encryption.

This page discusses in a way that I hope is clear, approachable and compelling, why everyone - even your mom, even your kids, should use encryption.

Michael D. Crawford
GoingWare Inc

USS Yorktown Dead in Water After Divide By Zero

The Navy's Smart Ship technology is being considered a success, because it has resulted in reduced manpower, workloads, maintenance and costs for sailors aboard the Aegis missile cruiser USS Yorktown. However, in September 1997, the Yorktown suffered a systems failure during maneuvers off the coast of Cape Charles, VA., apparently as a result of the failure to prevent a divide by zero in a Windows NT application. The zero seems to have been an erroneous data item that was manually entered. Atlantic Fleet officials said the ship was dead in the water for about 2 hours and 45 minutes. A previous loss of propulsion occurred on 2 May 1997, also due to software. Other system collapses are also indicated. [Source: Gregory Slabodkin, Software glitches leave Navy Smart Ship dead in the water, Government Computer News, 13 Jul 1998, PGN Stark Abstracting from http://www.gcn.com/gcn/1998/July13/cov2.html]

Michael D. Crawford
GoingWare Inc

USS Yorktown Dead in Water After Divide By Zero

The Navy's Smart Ship technology is being considered a success, because it has resulted in reduced manpower, workloads, maintenance and costs for sailors aboard the Aegis missile cruiser USS Yorktown. However, in September 1997, the Yorktown suffered a systems failure during maneuvers off the coast of Cape Charles, VA., apparently as a result of the failure to prevent a divide by zero in a Windows NT application. The zero seems to have been an erroneous data item that was manually entered. Atlantic Fleet officials said the ship was dead in the water for about 2 hours and 45 minutes. A previous loss of propulsion occurred on 2 May 1997, also due to software. Other system collapses are also indicated. [Source: Gregory Slabodkin, Software glitches leave Navy Smart Ship dead in the water, Government Computer News, 13 Jul 1998, PGN Stark Abstracting from http://www.gcn.com/gcn/1998/July13/cov2.html]

Michael D. Crawford
GoingWare Inc

I was close friends with a carpenter when I was younger, and he told me that he arrived at a new job site one day and found the following sign posted at the entrance:

If you don't take pride in your work you have no reason to be here.

But my friend thought it was great and said he wished more construction companies would hold such high standards. It happened that this friend took great pains to always learn new skills, and he spent a great deal of money on tools, and always did his best to always have, not just the right tool for the job, but the most obscure tools right on hand so there'd be no time wasted running to the hardware store or doing it a more difficult way.

And guess what? My friend was consistently among the highest paid carpenters for his level of experience. I haven't spoken to him in years but last I heard he's gone back to school because he wants to be a high-energy physicist. (This same fellow taught himself to program in x86 assembly after he bought a 486. I think it says something about his intellect and style that he chose to program in such a low-level language from the very start because it would be the fastest.)

I believe in having the best tools for the software job too, and by this I mean not the machine - a fast CPU is handy but doesn't help that much; what does help is my personal tools - the skills, experience and insight. To that end I work hard to study and sharpen my skills.

I spoke about that here just a couple days ago in Self-Training is Vitally Important as part of the discussion on What's the Best Way to Retain Trained Employees?

I also discuss it in my article Study Fundamentals Not APIs, OSes, or Tools. The gist of that article is that while you must study particular apis or tools to get work done, you shouldn't concentrate on or dive deeply into them but work to improve basic skills that will serve you well on any job.

Perhaps one of the problems these days is the overemphasis on APIs and the lack of emphasis on the basics, like good coding style and efficiency. Two people who know a given API equally well will get dramatically different results if one of them is well-grounded in algorithm analysis as well as having a good understanding of how computers actually work.

My comment about assembly code wasn't meant to say we should all start implementing our products in it. Rather, we should all learn and write some, and do some work with hand-tuning assembly code so that we have a good grasp of what the computer is doing when we write higher level code. Two books that discuss this pretty well are Gary Kacmarcik's Optimizing PowerPC Code and Michael L. Schmit's Pentium Processor Optimization Tools.

While they emphasize assembly code they should give you enough insight into the actual functioning of your computer that it should make your higher-level programming more efficient. And I do mean to say that your overall code will be more efficient on any processor, not that you should hand-tune it for one particular processor at the expense of another as someone here suggested would be the result.

A lot of people in this thread say the reason things have gotten so bad is because of pressure from marketing, management, clients or customers to add features and ship in a hurry. Yes, I acknowledge that such pressure exists and while they share responsibility you cannot blame them because that is their nature, much like the alligator who ate the frog after offering it a ride across the stream. (Frog? But frogs can swim)?

I've been in this business 13 years and there has always been marketing pressure but code quality has not always been so bad.

The quality and efficiency of your product is ultimately your responsibility as an architect and implementor. This is the case whether you're working in a well-funded dot-com or you're writing free software when you get the spare time.

At every step of the way in your software development process, you make choices. All too often we (and I do include myself) take the easy way out and write bad or inefficient code. It is a far better life to live if we strive for excellence in our products, and to do so we must strive for excellence with every choice we make in our software development.

I hope very much for the success of Linux and Free Software in general, but I think that it suffers overall from a severe quality problem. You may find this tolerable because you are a developer, but I'm a developer who has used lots of systems and personally I think Linux sucks as a development environment. It is no where near where it could be taken seriously as a desktop environment.

Now before you curse me for criticising, you should know that I run Linux on two Pentium III machines (Slackware) and I'm going to add LinuxPPC to my Mac soon. This is, in part, because I want to work to make it better. But part of the way I am going to work to make it better, isn't just fixing things directly but also advocating that everyone should take responsibility for their code and make it the very best that it can be.

My final word in this post is that if you want to get a good start on improving the quality of your work, read the Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks

Risks is a very well-moderated list that is frequented by some very serious and experienced experts on computer reliability, safety, fault-tolerance and public policy. But it is also often funny as your just as likely to see the latest UI bug in Word next to a problem with the control system in some nuclear power plant. It will give you a great deal more respect for the problems with computer code but there is also a great deal of discussion as to what can be done about it.

Michael D. Crawford
GoingWare Inc

* Voting cards failed to fit properly in the slots of some voting machines in Osceola County, giving 300 votes to the Libertarian candidate (where only 100 Libertarian voters are registered). Misaligned card machines have long been a source of errors.

The Risks folks can strike this one off the list. It turns out that this one is a legitimate vote bump, not a tech glitch:

I was watching NBC Nightly News this evening. Brokaw and crew detailed the grievances about Palm Beach County and all of those poor old people who just must have accidentally voted for Pat Buchanan. Then we heard that the Democrats also have their eye on Osceola County!

It seems that the Democrats are suspicious about the number of votes that Libertarian Harry Browne got in Osceola. You see, there are only 120 or so registered Libertarians in Osceola County, but Harry Browne got 309 votes there. The Democrats feel that if there's only 120 registered Libertarians and Harry Browne gets 309 votes ... why, hell. There must be voter fraud! These people aren't just going to decide to vote for Harry Browne on their own!

Well, guess what. It wasn't voter fraud. It was me. No false modesty here. It was Neal Boortz.

You see, I'm broadcast on 580-WDBO in Orlando. WDBO goes blasting into neighboring Osceola County and it's two largest cities, Kissimmee and St. Cloud. I've been on that station for quite some time now talking up the Libertarian position. Last Saturday Royal, Belinda and I traveled to Orlando to do a special two-hour election show. Believe me, I talked up Harry Browne and the Libertarian Party through a good part of those two hours.

So - to my pals in the Democratic Party. You can drop Osceola County from your list of counties with potential voter fraud. I'll take the full blame. Concentrate on those poor old folks in Palm Beach County who just can't seem to read a ballot.

• Sanity in the Election Process by the moderators of the Privacy and Risks Forums. Electronics is not the solution.
  
• Statement by Don A. Dillman on Palm Beach County Florida Ballot, about the form
  
• Florida vote counts, informative.
  
• Did a human factors problem affect the U.S. presidential election?.
  
• More on Florida in this and previous elections.
  
• More on Florida in this and previous elections.

• Sanity in the Election Process by the moderators of the Privacy and Risks Forums. Electronics is not the solution.
  
• Statement by Don A. Dillman on Palm Beach County Florida Ballot, about the form
  
• Florida vote counts, informative.
  
• Did a human factors problem affect the U.S. presidential election?.
  
• More on Florida in this and previous elections.
  
• More on Florida in this and previous elections.

• Sanity in the Election Process by the moderators of the Privacy and Risks Forums. Electronics is not the solution.
  
• Statement by Don A. Dillman on Palm Beach County Florida Ballot, about the form
  
• Florida vote counts, informative.
  
• Did a human factors problem affect the U.S. presidential election?.
  
• More on Florida in this and previous elections.
  
• More on Florida in this and previous elections.

• Sanity in the Election Process by the moderators of the Privacy and Risks Forums. Electronics is not the solution.
  
• Statement by Don A. Dillman on Palm Beach County Florida Ballot, about the form
  
• Florida vote counts, informative.
  
• Did a human factors problem affect the U.S. presidential election?.
  
• More on Florida in this and previous elections.
  
• More on Florida in this and previous elections.

• Sanity in the Election Process by the moderators of the Privacy and Risks Forums. Electronics is not the solution.
  
• Statement by Don A. Dillman on Palm Beach County Florida Ballot, about the form
  
• Florida vote counts, informative.
  
• Did a human factors problem affect the U.S. presidential election?.
  
• More on Florida in this and previous elections.
  
• More on Florida in this and previous elections.

• Sanity in the Election Process by the moderators of the Privacy and Risks Forums. Electronics is not the solution.
  
• Statement by Don A. Dillman on Palm Beach County Florida Ballot, about the form
  
• Florida vote counts, informative.
  
• Did a human factors problem affect the U.S. presidential election?.
  
• More on Florida in this and previous elections.
  
• More on Florida in this and previous elections.

There's very little wrong with the punch card ballots.

Bzzzzt. Wrong.

They aren't reliable, for one. According to computer risks experts Peter Neumann and Laruen Weinstein "manual recounts provide the MOST reliable mechanism for counting these cards accurately". See http://catless.ncl.ac.uk/Risks/21.12.h tml for more.

In addition, they are very easy to manipulate. Anyone with a piece of wire can punch a few extra holes in a card, making them double-punch, invalid ballots.

If we're going to use 19th century technology, let's at least use good 19th centure technology.

The comp.risks digest issue 21.12 has a well-written essay by Lauren Weinstein and Peter G. Neumann (both affiliated with PFIR and ACM). They refer to some position papers which address some of the risks associated with various computerized solutions to the voting mess.

Personally, I have plenty of reasons to be skeptical about digital voting systems. Paper ballots can be verified after the fact. As creaky as the security systems are in our current system, the citizens who are our poll workers are less likely (IMHO) to defraud their neighbors than impersonal vote-hackers living in other states. It's the integrity of the poll workers which helps to keep our system honest.

One specific concern about the glib comparison between anti-fraud provisions in e-commerce and those in the polling stations: e-commerce transactions have no requirement for anonymity. In fact, the anti-fraud provisions require that one examine his credit card statement to verify that it contains only legitimate charges. How would the anonymity of votes be protected? I'm not saying it's impossible, I just can't see an obvious way to do it which has parallels to e-commerce.

Now, to a proposal: after this election and the legal challenges are over, and we have sworn in the new Congress and a new President, the partisan divisions are likely to be more bitter than ever. One way to try to bring the two parties together would be for them to cooperate early in the session on an appropriation to the states, for a nationwide upgrade of the voting infrastructure. This could include a research phase, to identify or invent the best solution[s] and possibly to have NIST create some sort of standards (not technology standards, but "shall" requirements on security features, etc). After the research phase, the second appropriation would go to the states to deploy new infrastructure. Finally, some of the anecdotal evidence suggests that better training of poll workers is desirable.

By cooperating on such uncontroversial measures, the new Congress might be able to move on to other matters important to the nation. In the process, our Congress might elevate their public image above the current low, so that they might be seen as the moral equals of, say, Chimpanzees instead of Baboons. (apologies to primates).

The ACM Risks Forum ("Risks Digest") has lately been full of talk about elections, vote-counting, and electronic voting. Most notable is this item:

Security of electronic voting in public elections

which contains many pointers to discussions on the topic of "net voting". Also see issues 21.11 and 21.12, which contain some interesting comments on the current recounts going on in Florida and whether machine counting is more or less accurate than hand counting (spoiler: Peter Neuman and Lauren Weinstein disagree with the Bush campaign's contention that machine counting is more accurate).

--Jim

The ACM Risks Forum ("Risks Digest") has lately been full of talk about elections, vote-counting, and electronic voting. Most notable is this item:

Security of electronic voting in public elections

which contains many pointers to discussions on the topic of "net voting". Also see issues 21.11 and 21.12, which contain some interesting comments on the current recounts going on in Florida and whether machine counting is more or less accurate than hand counting (spoiler: Peter Neuman and Lauren Weinstein disagree with the Bush campaign's contention that machine counting is more accurate).

--Jim

The ACM Risks Forum ("Risks Digest") has lately been full of talk about elections, vote-counting, and electronic voting. Most notable is this item:

Security of electronic voting in public elections

which contains many pointers to discussions on the topic of "net voting". Also see issues 21.11 and 21.12, which contain some interesting comments on the current recounts going on in Florida and whether machine counting is more or less accurate than hand counting (spoiler: Peter Neuman and Lauren Weinstein disagree with the Bush campaign's contention that machine counting is more accurate).

--Jim

Computerized voting is a bad idea. Yes, there is enough hardware and software available to create a voting system that is secure and reliable. These things have been tried and there have always been problems and glitches that falsified the result. Just search RISKS for computer and voting ...

After all, the result will be the same anyway: Today, ballots are invalid because people punch the wrong hole. Tomorrow, my voting record will go down the drain when the database server crashes.

I probably don't know enough about your voting system in the US, but over here in Germany, people have to take a pencil and mark their candidate with a cross (1 line on paper = 1 candidate). The pencil will sometimes break, but that won't invalidate your vote and you can always etch your selection until you leave the voting booth ;-)

The ACM forum on risks, the usenet risks forum (comp.risks) and others have been talking about this for years. I always go to the back page of Communications of the ACM for a hair-raising chuckle. Unfortunately, recently the columns have been self-serving ads.

If you haven't recognized that people are the weakest link, where have you been?

Do you know in how many way the absence of technology can fail us? What about the famines? the plagues? manual back-breaking work?

Color? But you have a black-and-white TV? So a color TV will control you, but a B/W TV will not?

A man stands looking at a hammer in his hand. "Will I be able to control it? Or will it control me? Aaah, better not take the chance..."

Hal Duston
hald@sound.net

The very earliest case I now of is a guy who was jealous of his brother's success. So he set up his own town and put signs on the road pointing the other direction, leading to Reme.

The very earliest case I now of is a guy who was jealous of his brother's success. So he set up his own town and put signs on the road pointing the other direction, leading to Reme.

What's discussed there is quite relevant here; poor engineering or attempting to overextend what may have originally been a good design appropriate to simpler tasks will result in terrible software problems - security holes, safety hazards and the like.

Also recommended is the book Computer Related Risks by Risks Forum moderator Peter Neumann (ISBN 020155805X). It draws on material from the forum but discusses it in greater detail.

Now we're seeing a claim that in a rather fundamental fashion, feature accretion is not a good thing.

This is nothing new. A brief scan of the RISKS Digest archives shows many, many cases going back years where a working system and a new, working-as-intended component were combined with disastrous results. (It always amazes me how many engineers and developers have never read RISKS Digest or the book that Neumann published; one developer at a major Northern Virginia Internet applications developer asked me "Is that a local list in your area? I never heard of it.")

If you don't know what RISKS is, check out comp.risks (the USENET feed of the digest); if your ISP doesn't carry it, either get them to, or change ISPs. It's well worth a few bucks a month more if it comes to that.

I propose a new version of Brooks' Law: "Adding components to a buggy piece of software makes it buggier."

But after a sailor entered a zero into a data entry field aboard the Yorktown, the whole ship's NT network went down and our nation's proud vessel had to be towed into port, as seen here.

Of course there's no guarantee that this wouldn't happen with Linux too, but what would make a lot of sense is to use it's open-source nature to create a military distribution, which has been audited for both security holes and reliability defects.

I'm sure many of the distribution vendors would be happy to do that for a price, but I suggest the military do it for yourselves - but remember the GPL!

For more such informative anecdotes of computer reliability, please read The Forum on Risks to the Public in Computers and Related Systems

Also, the moderator of Risks, Peter G. Neumann is a computer reliability expert that is held in high esteem by the defense establishment - see for example Practical Architectures for Survivable Systems and Networks which he did for the Army Research Lab.

He presented a keynote talk for the April 2000 NATO Symposium "The Potentials of Open-Box Source Code in Developing Robust Systems". At the NATO Symposium he handed out a preprinted entitled "Robust Nonproprietary Software" which is available in PDF format.

I suggest you drop Dr. Neumann a Line.

But after a sailor entered a zero into a data entry field aboard the Yorktown, the whole ship's NT network went down and our nation's proud vessel had to be towed into port, as seen here.

Of course there's no guarantee that this wouldn't happen with Linux too, but what would make a lot of sense is to use it's open-source nature to create a military distribution, which has been audited for both security holes and reliability defects.

I'm sure many of the distribution vendors would be happy to do that for a price, but I suggest the military do it for yourselves - but remember the GPL!

For more such informative anecdotes of computer reliability, please read The Forum on Risks to the Public in Computers and Related Systems

Also, the moderator of Risks, Peter G. Neumann is a computer reliability expert that is held in high esteem by the defense establishment - see for example Practical Architectures for Survivable Systems and Networks which he did for the Army Research Lab.

He presented a keynote talk for the April 2000 NATO Symposium "The Potentials of Open-Box Source Code in Developing Robust Systems". At the NATO Symposium he handed out a preprinted entitled "Robust Nonproprietary Software" which is available in PDF format.

I suggest you drop Dr. Neumann a Line.

I guess that I must have been hallucinating when I saw the comp.risks posting describing Emacs executing arbitrary lisp copde in a document, then. And the other comp.risks posting, six years later, describing exactly the same thing.

Don't feel bad; most people don't know that Microsoft isn't creating new risks, they're just duplicating the stupidity of GNU a decade earlier.

I guess that I must have been hallucinating when I saw the comp.risks posting describing Emacs executing arbitrary lisp copde in a document, then. And the other comp.risks posting, six years later, describing exactly the same thing.

Don't feel bad; most people don't know that Microsoft isn't creating new risks, they're just duplicating the stupidity of GNU a decade earlier.

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.

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 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.

Searching for "Promis" yields US Congress Report on INSLAW Case

The mentioned article on Apple's FTP site doesn't appear to be there anymore, but doing an FTP search on lycos revealed that there's a lot of INSLAW stuff at the Electronic Frontier Foundation. You can repeat the search yourself with this link.

While you're there, why don't you stop in and Join the EFF? It will only take you a few minutes, cost a few bucks (you can give what you're comfortable with) and it will help with the DVD case as well as bringing justice to bear on the folks that stole and hacked the Promis code.

Searching for "Promis" yields US Congress Report on INSLAW Case

The mentioned article on Apple's FTP site doesn't appear to be there anymore, but doing an FTP search on lycos revealed that there's a lot of INSLAW stuff at the Electronic Frontier Foundation. You can repeat the search yourself with this link.

While you're there, why don't you stop in and Join the EFF? It will only take you a few minutes, cost a few bucks (you can give what you're comfortable with) and it will help with the DVD case as well as bringing justice to bear on the folks that stole and hacked the Promis code.

I'd further like to say that I think everyone should spend less time concentrating on learning specific API's in great detail, and instead focus on improving your core skills and fundamental understanding of programming.

I used to spend a lot of time learning API's (bought every volume of Inside Macintosh as they came out, and when I was just starting out and broke and hungry, used to read them in the bookstore before I could afford to buy them).

I prided myself on knowing all the little bugs and intricacies of the MacOS so I could just know to code around an OS bug without having to research why my code didn't work. I got so good that I was hired as an OS engineer at Apple where I concentrated on debugging the MacOS system software with MacsBug (a machine level debugger) - I had the MacOS source code at my disposal but that usually didn't help when I was visiting a tester's cubicle to diagnose a machine with a hard-to-reproduce crash.

Then I moved to the BeOS, shipped a product and wrote a lot of code but got fed up with their lack of commitment to their developers. And without getting paid to write BeOS code, I never could keep up with the BeOS API's I wanted to work with, like the new Media Kit (which I do know enough about to say it is pretty cool).

A couple years back I stopped spending much time learning and mostly just cranked out routine code. I felt I didn't want to learn anymore because, as I would sometimes say:

I feel that if I have to learn another API my head will surely explode.

I read Scott Meyers' Effective C++ and More Effective C++ and as I read through each item I inspected my program top to bottom and applied the advice to it (thus fixing a lot of bugs).

I also bought Bjarne Stroustrup's The C++ Programming Language: Special Edition (I recommend the special edition to professional programmers).

I started reading the newsgroups comp.lang.c++, comp.lang.c++.moderated and comp.std.c++ and posting questions there - in one case I found a construction on the very edge of the C++ standard and as a result of a compiler bug managed to instantiate an object of an abstract base class - its pure virtual function had a nil pointer in the vtbl and my program would crash when this function was called. An engineer from the compiler vendor read my post on the newsgroup, agreed that it was a bug that his product would compile my code, and logged a bug.

I didn't used to use the Standard Template Library very much at all. I had read too many mailing list and newsgroup postings from people whose code wouldn't compile when they changed platforms.

But I figured that by now compilers must have matured enough I could reasonably start trying out the STL. I bought STL Tutorial and Reference Guide by Musser and Stepanov and actually only read a little bit of it before I realized that the STL is actually really easy to use (the API is very simple and uniform), so if you know only a very little bit you can go a very long way.

In part because of challenging myself I became overwhelmed with programming stuckness as discussed in Overcomming Programmer's Block? (sic) and I suppose grew a little bit by taking a week off without pay to rest, contemplate, study and take a broader view of architectural issues.

One thing that helped quite a bit was learning about Extreme Programming.

These things have all had direct payoff in my code, both in making my code quicker to write, easier to debug, easier to make my classes more reusable within the one program I've been writing the last few months, and I'm pretty sure more likely to make some of the code I've written reusable in most any program in the future.

It's also made it a lot more pleasant.

But don't listen to the headhunters - what they're looking for is "skill sets" and industry buzzwords (COM, COM+, DCOM, TCP/IP, Visual C++, ASP, SQL, device drivers, CORBA, Unix internals, Java, Perl, PHP, JSP) - I get recruiter calls looking for all kinds of acronyms, most of which I don't mention anywhere on my resume.

Even I advise listing every skill keyword you can legimately claim on your online resume in Market Yourself - Tips for High-Tech Consultants - but while listing skillsets may be a valuable jobhunting tool in your resume, acquiring them should not be your focus.

BTW, when someone asks me whether they should learn Java or C++, I usually advise beginners to learn Java as it's easier to get something working reliably without crashing, but emphasize they should learn both languages as well as at least one kind of assembly code. I stress that it's important to learn both C++ and Java well enough to understand the strengths and weaknesses of each (pop quiz - why does Optimizeit claim to remove memory leaks from Java programs, when Java is a garbage collected language?).

Most new programmers these days are most concerned with which language will make them the most money the fastest. I tell them that they won't go anywhere until they can pick up any new programming language as a matter of course and have at least a couple under their belt.

I've got bad news for you neophytes - friends, just knowing a programming language doesn't win you very much in the work world, you have to understand the concepts and how to apply them, and you have to know how to apply them in a production environment, working in a business under pressure, shipping working products and dealing with people who don't understand anything of substance about computers.

Your focus should be on acquiring skills that will be applicable to any program you write. You should just learn enough of a skill or tool to get the job done and then leave it. Take with you what can be applied anywhere.

BTW - learning the fundamentals and not getting too specialized enables you to develop for any platform, as I do - you can see this from my homepage. (Perhaps one reason why I prefer understanding the fundamentals is that my degree is in Physics, and I've always wanted to understand things at a fundamental level - Quantum Mechanics, Particle Physics, Cosmology and so on.)

One final word of advice - read The Forum on Risks to the Public in Computers and Related Systems. It's often entertaining and funny, occassionally tragic, usually insightful and will make you a more responsible programmer and a wiser computer user. You'll certainly learn to avoid using computers for anything of real importance and take extra caution to protect yourself when you choose to do so.

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.

Stack overflow? Heap corruption? Unanticipated input?

'Nuff said.

The Yellow Network Coalition takes old 486's and turns them into firewalls and IP masquerading servers they give away for free to people who have cable modems and DSL. I gave them my 486 when I moved. They also set up free public-access kiosks. These guys are inspired by the freely available yellow bicycles in Amsterdam.

They Need Your Donations of Old 486's and Other Hardware

The Forum on Risks to the Public in Computers and Related Systems discusses security holes, bugs in software, user and usability problems that cause such trouble as security problems, and carries security announcements.

The CERT Coordination Center carries authoritative announcements of security problems and what you can do to fix them; provides rapid response to security emergencies while they are in progress.

I've also heard BugTaq is good and better than CERT for timely information but don't have a URL handy.

While anyone may submit to Risks, some of the people who post there are respected experts in their fields, and will often write very well-thought-out criticism of online and telephone voting schemes as they are actually practiced - usually without much regard for security and privacy - as opposed to the ideal schemes thought up by security experts and cryptographers.

I can't remember any specific posts on online voting, lets see what the search form produces:

Just searching for "voting" produces dozens of submissions, mostly related to computerized voting - that is, electronic voting booths, which have their own reliability and security issues but are not what we're discussing here - but see Computer Causes Chaos in Brazilian Election in which a program designed to weed out fraudulent voters (like dead people) canceled the voting rights of 70,000 twins.

Searching for "voting;online" produces a few hits such as the announcement of Arizona's online voting and a comment that there is no promise of privacy in online voting - that your identity and your vote won't be correllated, which is forbidden for conventional voting.

Wonder about the accuracy of unofficial online votes? Check out the risks of paying attention to uncontrolled e-voting in which a public opinion voting site on abortion funnelled votes from both sides to the anti-abortion side.

While anyone may submit to Risks, some of the people who post there are respected experts in their fields, and will often write very well-thought-out criticism of online and telephone voting schemes as they are actually practiced - usually without much regard for security and privacy - as opposed to the ideal schemes thought up by security experts and cryptographers.

I can't remember any specific posts on online voting, lets see what the search form produces:

Just searching for "voting" produces dozens of submissions, mostly related to computerized voting - that is, electronic voting booths, which have their own reliability and security issues but are not what we're discussing here - but see Computer Causes Chaos in Brazilian Election in which a program designed to weed out fraudulent voters (like dead people) canceled the voting rights of 70,000 twins.

Searching for "voting;online" produces a few hits such as the announcement of Arizona's online voting and a comment that there is no promise of privacy in online voting - that your identity and your vote won't be correllated, which is forbidden for conventional voting.

Wonder about the accuracy of unofficial online votes? Check out the risks of paying attention to uncontrolled e-voting in which a public opinion voting site on abortion funnelled votes from both sides to the anti-abortion side.

While anyone may submit to Risks, some of the people who post there are respected experts in their fields, and will often write very well-thought-out criticism of online and telephone voting schemes as they are actually practiced - usually without much regard for security and privacy - as opposed to the ideal schemes thought up by security experts and cryptographers.

I can't remember any specific posts on online voting, lets see what the search form produces:

Just searching for "voting" produces dozens of submissions, mostly related to computerized voting - that is, electronic voting booths, which have their own reliability and security issues but are not what we're discussing here - but see Computer Causes Chaos in Brazilian Election in which a program designed to weed out fraudulent voters (like dead people) canceled the voting rights of 70,000 twins.

Searching for "voting;online" produces a few hits such as the announcement of Arizona's online voting and a comment that there is no promise of privacy in online voting - that your identity and your vote won't be correllated, which is forbidden for conventional voting.

Wonder about the accuracy of unofficial online votes? Check out the risks of paying attention to uncontrolled e-voting in which a public opinion voting site on abortion funnelled votes from both sides to the anti-abortion side.

While anyone may submit to Risks, some of the people who post there are respected experts in their fields, and will often write very well-thought-out criticism of online and telephone voting schemes as they are actually practiced - usually without much regard for security and privacy - as opposed to the ideal schemes thought up by security experts and cryptographers.

I can't remember any specific posts on online voting, lets see what the search form produces:

Just searching for "voting" produces dozens of submissions, mostly related to computerized voting - that is, electronic voting booths, which have their own reliability and security issues but are not what we're discussing here - but see Computer Causes Chaos in Brazilian Election in which a program designed to weed out fraudulent voters (like dead people) canceled the voting rights of 70,000 twins.

Searching for "voting;online" produces a few hits such as the announcement of Arizona's online voting and a comment that there is no promise of privacy in online voting - that your identity and your vote won't be correllated, which is forbidden for conventional voting.

Wonder about the accuracy of unofficial online votes? Check out the risks of paying attention to uncontrolled e-voting in which a public opinion voting site on abortion funnelled votes from both sides to the anti-abortion side.

While anyone may submit to Risks, some of the people who post there are respected experts in their fields, and will often write very well-thought-out criticism of online and telephone voting schemes as they are actually practiced - usually without much regard for security and privacy - as opposed to the ideal schemes thought up by security experts and cryptographers.

I can't remember any specific posts on online voting, lets see what the search form produces:

Just searching for "voting" produces dozens of submissions, mostly related to computerized voting - that is, electronic voting booths, which have their own reliability and security issues but are not what we're discussing here - but see Computer Causes Chaos in Brazilian Election in which a program designed to weed out fraudulent voters (like dead people) canceled the voting rights of 70,000 twins.

Searching for "voting;online" produces a few hits such as the announcement of Arizona's online voting and a comment that there is no promise of privacy in online voting - that your identity and your vote won't be correllated, which is forbidden for conventional voting.

Wonder about the accuracy of unofficial online votes? Check out the risks of paying attention to uncontrolled e-voting in which a public opinion voting site on abortion funnelled votes from both sides to the anti-abortion side.

While anyone may submit to Risks, some of the people who post there are respected experts in their fields, and will often write very well-thought-out criticism of online and telephone voting schemes as they are actually practiced - usually without much regard for security and privacy - as opposed to the ideal schemes thought up by security experts and cryptographers.

I can't remember any specific posts on online voting, lets see what the search form produces:

Just searching for "voting" produces dozens of submissions, mostly related to computerized voting - that is, electronic voting booths, which have their own reliability and security issues but are not what we're discussing here - but see Computer Causes Chaos in Brazilian Election in which a program designed to weed out fraudulent voters (like dead people) canceled the voting rights of 70,000 twins.

Searching for "voting;online" produces a few hits such as the announcement of Arizona's online voting and a comment that there is no promise of privacy in online voting - that your identity and your vote won't be correllated, which is forbidden for conventional voting.

Wonder about the accuracy of unofficial online votes? Check out the risks of paying attention to uncontrolled e-voting in which a public opinion voting site on abortion funnelled votes from both sides to the anti-abortion side.

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.

I think this is with a 5000 RPM disk.

While on this topic, please read my page on Why You Should Use Encryption

While encryption is indeed computationally expensive, it is not nearly as computationally expensive as badly written GUI code, and that's what's usually running on modern computers. Encryption software is generally quite optimized, while the crud we call shrink-wrap software is a poor excuse for engineering.

I also refer you to the Risks Forum

You need to read Risks if you:

• Use and depend on computers in any but the most trivial way
• Program computers
• Make policy decisions regarding computers
• Operate computers in a way that affects safety (pilot a modern airplane, work in a hospital)
• Use computers in a way that may impact your own safety (flown on a modern airplane lately?)

You might also want to check out the book "Computer Related Risks" by forum moderator Peter G. Neumann ISBN 020155805X. It draws on material from the forum but discusses it in greater depth. You'll find it at all the online bookstores and many local bookstores as well.

Here's a few of my own posts to Risks:

The Sinking of the USS Gitarro

A US Navy submarine was sunk in the Mare Island channel near Vallejo, California by a test technician. He was trying to level the ship to run a test, and only knew how to take in ballast water, not expel it. The forward sonar hatch was off, power cables were run through the pressure safety doors because the sub was in for repairs, and so the might Gitarro sunk. My dad was stationed at the shipyard at the time, back in the 60's.

Algorithms Have Unclear Boundaries

Copy of a letter I wrote the patent office, on the problem of defining what is or is not an algorithm in a program when the boundaries between them cannot be precisely defined. Discussed the problems that occur when the virtual machine breaks down (as I guess happens in this case).

Excel Linked Spreadsheet Bug

In which a friend of mine bounced a business check for four thousand dollars because of a bug in Microsoft Excel - a bug he could later demonstrate at will.

Tilting at Windmills for a Better Tomorrow

You need to read Risks if you:

• Use and depend on computers in any but the most trivial way
• Program computers
• Make policy decisions regarding computers
• Operate computers in a way that affects safety (pilot a modern airplane, work in a hospital)
• Use computers in a way that may impact your own safety (flown on a modern airplane lately?)

You might also want to check out the book "Computer Related Risks" by forum moderator Peter G. Neumann ISBN 020155805X. It draws on material from the forum but discusses it in greater depth. You'll find it at all the online bookstores and many local bookstores as well.

Here's a few of my own posts to Risks:

The Sinking of the USS Gitarro

A US Navy submarine was sunk in the Mare Island channel near Vallejo, California by a test technician. He was trying to level the ship to run a test, and only knew how to take in ballast water, not expel it. The forward sonar hatch was off, power cables were run through the pressure safety doors because the sub was in for repairs, and so the might Gitarro sunk. My dad was stationed at the shipyard at the time, back in the 60's.

Algorithms Have Unclear Boundaries

Copy of a letter I wrote the patent office, on the problem of defining what is or is not an algorithm in a program when the boundaries between them cannot be precisely defined. Discussed the problems that occur when the virtual machine breaks down (as I guess happens in this case).

Excel Linked Spreadsheet Bug

In which a friend of mine bounced a business check for four thousand dollars because of a bug in Microsoft Excel - a bug he could later demonstrate at will.

Tilting at Windmills for a Better Tomorrow

You need to read Risks if you:

• Use and depend on computers in any but the most trivial way
• Program computers
• Make policy decisions regarding computers
• Operate computers in a way that affects safety (pilot a modern airplane, work in a hospital)
• Use computers in a way that may impact your own safety (flown on a modern airplane lately?)

You might also want to check out the book "Computer Related Risks" by forum moderator Peter G. Neumann ISBN 020155805X. It draws on material from the forum but discusses it in greater depth. You'll find it at all the online bookstores and many local bookstores as well.

Here's a few of my own posts to Risks:

The Sinking of the USS Gitarro

A US Navy submarine was sunk in the Mare Island channel near Vallejo, California by a test technician. He was trying to level the ship to run a test, and only knew how to take in ballast water, not expel it. The forward sonar hatch was off, power cables were run through the pressure safety doors because the sub was in for repairs, and so the might Gitarro sunk. My dad was stationed at the shipyard at the time, back in the 60's.

Algorithms Have Unclear Boundaries

Copy of a letter I wrote the patent office, on the problem of defining what is or is not an algorithm in a program when the boundaries between them cannot be precisely defined. Discussed the problems that occur when the virtual machine breaks down (as I guess happens in this case).

Excel Linked Spreadsheet Bug

In which a friend of mine bounced a business check for four thousand dollars because of a bug in Microsoft Excel - a bug he could later demonstrate at will.

Tilting at Windmills for a Better Tomorrow

You need to read Risks if you:

• Use and depend on computers in any but the most trivial way
• Program computers
• Make policy decisions regarding computers
• Operate computers in a way that affects safety (pilot a modern airplane, work in a hospital)
• Use computers in a way that may impact your own safety (flown on a modern airplane lately?)

You might also want to check out the book "Computer Related Risks" by forum moderator Peter G. Neumann ISBN 020155805X. It draws on material from the forum but discusses it in greater depth. You'll find it at all the online bookstores and many local bookstores as well.

Here's a few of my own posts to Risks:

The Sinking of the USS Gitarro

A US Navy submarine was sunk in the Mare Island channel near Vallejo, California by a test technician. He was trying to level the ship to run a test, and only knew how to take in ballast water, not expel it. The forward sonar hatch was off, power cables were run through the pressure safety doors because the sub was in for repairs, and so the might Gitarro sunk. My dad was stationed at the shipyard at the time, back in the 60's.

Algorithms Have Unclear Boundaries

Copy of a letter I wrote the patent office, on the problem of defining what is or is not an algorithm in a program when the boundaries between them cannot be precisely defined. Discussed the problems that occur when the virtual machine breaks down (as I guess happens in this case).

Excel Linked Spreadsheet Bug

In which a friend of mine bounced a business check for four thousand dollars because of a bug in Microsoft Excel - a bug he could later demonstrate at will.

Tilting at Windmills for a Better Tomorrow