×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The Economics of Perfect Software

Soulskill posted about 4 years ago | from the done-versus-done-ish dept.

Bug 201

An anonymous reader writes "This article takes the interesting perspective that leaving bugs in software is good — little ones, at least. This quote is particularly insightful: 'How do you know whether a bug is big or little? Think about who's going to hit it, and how mad they'll be when they do. If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug. It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way. If your program crashes on launch for a common setup, though, that's a big bug. Lots of people will hit it, and they will all be pissed. ... The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

201 comments

How is this news? (5, Insightful)

Dragoniz3r (992309) | about 4 years ago | (#31648618)

Diminishing returns applies to programming too... big surprise...

Re:How is this news? (3, Interesting)

Jurily (900488) | about 4 years ago | (#31648918)

Diminishing returns applies to programming too... big surprise...

But you don't know how much each bug will cost. What if that little UI glitch gives remote root?

BTW Joel Spolsky [joelonsoftware.com] said the same in 2001. Big fucking news indeed.

Re:How is this news? (4, Insightful)

Vellmont (569020) | about 4 years ago | (#31649442)


What if that little UI glitch gives remote root?

Then you're an idiot who didn't separate your software properly into layers and should learn, or get out.

I understand your example, but the ultimate fear you're expressing about "the unknown" isn't warranted. Software is complex and can lead to unexpected problems. But worrying about every single minor bug possibly being a major one is just silly if you understand how the system interacts with itself. That's why good software is developed in layers. If you've really got a system where a UI glitch leads to a root exploit, time to throw away the whole application and start over.

Re:How is this news? (1, Insightful)

Anonymous Coward | about 4 years ago | (#31648958)

I leave in all kinds of weird bugs that only I can fix, just to guarantee my future job. I'm betting big software companies relying on people buying the new versions of their products do the same. After all, there's no reason for upgrading perfect software, is there?

Re:How is this news? (4, Insightful)

obarel (670863) | about 4 years ago | (#31649400)

I hope you're not serious.

The first problem is that it doesn't guarantee anything. There are very few software companies that close down or get rid of people because of small quirky bugs. You're not going to lose your job simply because you write perfect code either...

The second problem is that if you do keep your job, it's only to maintain the same piece of code. Aren't there more exciting things to do than to fix the same bugs you left in some spaghetti code that only you can understand? Isn't it better to write good solid readable code and move on to more interesting problems than off-by-one bugs you left on purpose?

And the third problem is that you can never justify that to your boss: "You've got to keep me because the code is terrible and only I can maintain it". The easiest thing would be to cut the losses and send you free, only to bring someone who can write some code that isn't an expensive liability.

Sadly, you're not the only person that writes bad code for "job security". So I hope your post gets a "Score: 5 Funny" and not a "Score: 2 Insightful"...

Re:How is this news? (1)

spongman (182339) | about 4 years ago | (#31649760)

i just hope your boss is smart enough to know this so that once your company fails he'll warn all your potential future employers not to hire you.

Re:How is this news? (1)

clarkkent09 (1104833) | about 4 years ago | (#31649216)

Yeah, I remember waaaay back the saying was something like it takes 20% of the time to do the first 80% of the code, and 80% of the time to do the remaining 20%. It would be nice to get every last bug fixed but if you have plans for the rest of your life other than bug fixing you have to draw the line somewhere and get it released.

Re:How is this news? (0)

Anonymous Coward | about 4 years ago | (#31649290)

That was my first thought as well. Thanks for being quick about it.

Re:How is this news? (4, Interesting)

spongman (182339) | about 4 years ago | (#31649720)

yeah, there's a also a mistaken suggestion that there's a correlation between the severity of the bug and the cost of fixing it.

in general there isn't.

you might have a crashing, data-destroying bug that's trivial to fix. or you might have a minor UI annoyance that would require a complete re-write in order to fix, possibly introducing a whole slew of new bugs.

unless you have a deep understanding of the architecture of the application, there's absolutely no way to judge which class a given bug is in.

The bugs you are not aware of are the worst ones (0)

Anonymous Coward | about 4 years ago | (#31649790)

Ask Toyota. But there is no need to despair. Toyota software researchers or anybody else who writes safety-critical applications should read this: How to Construct 100% Bug-Free Software [blogspot.com] . It can be done but we will need to change to a synchronous and reactive software model.

Lets look at it another way (3, Insightful)

Anonymous Coward | about 4 years ago | (#31648626)

You cant afford perfect software.

Re:Lets look at it another way (2, Informative)

Tablizer (95088) | about 4 years ago | (#31648654)

You cant afford perfect software.

Unless you are NASA:

http://www.fastcompany.com/magazine/06/writestuff.html [fastcompany.com]
     

Re:Lets look at it another way (4, Interesting)

sopssa (1498795) | about 4 years ago | (#31648820)

Quote from the site:

Consider these stats : the last three versions of the program -- each 420,000 lines long-had just one error each. The last 11 versions of this software had a total of 17 errors.

So yes, they have errors too and their software isn't perfect nor bug-free. But their acceptable cost versus bug-free threshold is just a lot more higher than usual software. Exactly what the summary and article is about.

Leaving bugs is not professional (0)

Anonymous Coward | about 4 years ago | (#31648632)

Fix them all, you basterds!

Re:Leaving bugs is not professional (0)

Anonymous Coward | about 4 years ago | (#31648648)

You obviously don't work in IT. If you do, it's in marketing or sales.

Oh Please (5, Insightful)

WrongSizeGlass (838941) | about 4 years ago | (#31648660)

The reason that every piece of software ships with bugs is because:
* It's created by people
* The programmers, testers, etc can never find all the bugs
* It's gotta get out the door so you can pay your programmers, testers, etc
* All of the above

There is a matter of pride with individual programmers, small groups, and most open source programming projects. We'd all love to be able to crow about shipping a bug free project/product. We'd do it if we could ... and someday we will.

Re:Oh Please (0)

Anonymous Coward | about 4 years ago | (#31648722)

... and someday we will.

I doubt that that will happen. Anything made by a human has a flaw.

Re:Oh Please (-1, Flamebait)

Anonymous Coward | about 4 years ago | (#31648840)

In your case, many!

Re:Oh Please (2, Insightful)

gyrogeerloose (849181) | about 4 years ago | (#31649446)

I doubt that that will happen. Anything made by a human has a flaw.

Yeah, but it's one of those infinite-number-of-monkeys-for-an-infinite-amount-of-time things. Enough programmers writing enough code for enough time will, more or less by accident, write a perfect piece of code.

Re:Oh Please (4, Insightful)

zappepcs (820751) | about 4 years ago | (#31648744)

Exactly. Most coders have to use the code they write. Leaving bugs is not something you do if you know they are there. Sure some people do that, but not the ones that want to get it right - at least for their own use. This is why some open source software is not infinitely usable - it did what the original author needed, and was not intended particularly to solve everyone's silly problems. The example of the 'A' key is probably something that was going to work soon, but the need for it never materialized and someone forgot to disable the code that checks for the letter 'A' - and since it was not implemented, nobody checked it.

The first time I had code in production, running 24/7 I was kind of upset that I didn't need to look at it everyday, then amazed that it was working so well. Then, months later when I did have to go look at why it seemed to be not working right, I learned how important documentation and comments are. At this point I stopped being amazed that it worked well, but that it worked at all. Bugs are not left on purpose, only when there is not time or resources to fix them.

Re:Oh Please (4, Insightful)

Jurily (900488) | about 4 years ago | (#31649094)

Leaving bugs is not something you do if you know they are there.

Depends on how much of the code you have to refactor to get rid of it, how many users are annoyed at that particular bug in the previous release, and how many new users you'd get by implementing the most asked-for feature instead.

You probably won't fix the bug where your text editor crashes if the user tries to open a file larger than 32 Gb first, if they've been also nagging you for global replace functionality.

Re:Oh Please (1)

zappepcs (820751) | about 4 years ago | (#31649244)

You are describing the resources vs number and type of bugs. With enough resources, both problems would be addressed: if $file.size > 32Gb then err_msg and return. In this case, global replace is probably more work to fix. Still, it comes down to resources and the squeaky wheel syndrome.

Lets not ignore or forget that in many commercial situations, the propensity for Marketing and Sales groups to describe the problems opposite of how I did. That is to say they will promise the hard fix before the easy one to get the sale. This in turn negatively affects the resources vs. problems algebra.

3(-2x + 1) = -6x - 7 looks good on paper so far... Sure, global replace is easy says the salesman, the dev teams are working on it already.

Re:Oh Please (2, Insightful)

Vellmont (569020) | about 4 years ago | (#31649220)


Most coders have to use the code they write. Leaving bugs is not something you do if you know they are there. Sure some people do that, but not the ones that want to get it right

This happens all the time. Have you never read release notes that have a list of "known bugs"? Generally that's open source software. The closed source software has the exact same list, it just exists on the software makers private network.

Sure, if you KNOW how to fix the bug and it's easy most people will just fix it. The other cases it depends on the economics. Open source software isn't any different than closed source in this respect. Resources are always finite whether they're money or time.

Re:Oh Please (1)

Lije Baley (88936) | about 4 years ago | (#31648760)

Duh, you just outlined the economic rationale. And b)We'd love to ship something bug free, but even as individuals with all of our time at our discretion we would not waste the rest of lives trying to get the bugs out of something as complex as modern software, so NO we won't do it SOMEDAY either. Maybe Skynet will though...

Re:Oh Please (5, Insightful)

WrongSizeGlass (838941) | about 4 years ago | (#31648900)

even as individuals with all of our time at our discretion we would not waste the rest of lives trying to get the bugs out of something as complex as modern software, so NO we won't do it SOMEDAY either.

We may not ever accomplish it, but that doesn't mean we won't stop trying. Bugs slip through no matter how much we test. One reason is because no matter how we may try to break it we can never imagine the utterly creative stupidity that a user will cast upon our software.

And as far as Skynet is concerned, it will be written by humans or by a system written by humans, so it's gonna have bugs, too (unless it was written by Deep Thought, but that's another story entirely).

Re:Oh Please (0)

Anonymous Coward | about 4 years ago | (#31648866)

The reason that every piece of software ships with defects is because:
* It's created by people who think defects are inevitable
* The programmers, testers, etc spend all their time fixing defects after they have been introduced rather then trying to never introduce them in the first place
* It's gotta get out the door and capitalism treats low quality as a PR problem, instead of a people problem.
* All of the above

There.. fixed it for you ;-)

Re:Oh Please (1)

zippthorne (748122) | about 4 years ago | (#31648980)

* It's gotta get out the door and capitalism treats low quality as a PR problem, instead of a people problem.

At first I thought this was an indictment of capitalism, but then I strained to think of an economic system that treats it differently and realized that you can claim to think of low quality as a "people problem" if the users are the people who are the problem...

Re:Oh Please (1, Insightful)

Anonymous Coward | about 4 years ago | (#31649038)

We'll patiently wait for you to show us your prefect, bug free software. Until then we'll get on with the job of writing the software that you use every day.

Re:Oh Please (0)

Anonymous Coward | about 4 years ago | (#31649194)

(...) prefect (sic), bug free software.

http://ertos.nicta.com.au/research/l4.verified/

No bugs isn't a perfect product. (5, Insightful)

ArundelCastle (1581543) | about 4 years ago | (#31649224)

Even if it's bug free, that doesn't mean the software is designed to be easy or intuitive to use. There is often more money to be made from deliberate obfuscation. Every piece of Enterprise software I've used (particularly SAP) seems to follow this principle. And the huge aftermarket of expert consultants charging $150/hr for training and troubleshooting, seems to affirm it. Keep in mind those consultants are usually teaching the corporate experts, I'm not even touching the surface of end user training, which I'm experienced at being responsible for.

The real money comes from support packages and direct-line support levels (ie: silver, gold, platinum and such to maintain a 24h call centre). Let's ask a simple hypothetical: what if Windows was bulletproof and bug free? How would Microsoft make any money? If nobody had reason to fix a problem within 30 minutes like their job depends on it? Or even not upgrade to the next version because the last one works better? With XP and Vista we already know the answer to that.

Re:Oh Please (3, Funny)

Tablizer (95088) | about 4 years ago | (#31649362)

The reason that every piece of software ships with bugs is because:...It's created by people...

I'm breeding cockroaches to write code. How ironic: bugs will solve bugs.
   

Well, sure, if you have precognition (4, Insightful)

Geoffrey.landis (926948) | about 4 years ago | (#31648698)

Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug. And if you're not, that bug that you think will only happen in some situation that's vastly improbably will, in fact, actually hit at exactly the WORST possible time, because maybe that key sequence gets used in some extremely important operation that you hadn't realized your software was going to be used for. Or maybe that bug is ALSO triggered by some different sequence that you weren't quite prescient enough to realize would be common.

Re:Well, sure, if you have precognition (1)

PingPongBoy (303994) | about 4 years ago | (#31649166)

Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug

That's just it. Keeping software in a controlled environment if there is any risk of it running amok is only prudent. In the enlightened days of Terminator Toyotas a cap on the damage caused by bugs needs to be considered.

Re:Well, sure, if you have precognition (1)

Bigjeff5 (1143585) | about 4 years ago | (#31649316)

It's not hard.

Bug Report:

"If I do X, Y, then Z, and sometime in the next 5 seconds do A, B,C, followed by ctrl-shift-A, I get an error message."

If you've got a million customers, there are maybe 50 who are going to hit that sequence, and all it does is give them an error message without stopping their work in any way. The effect on the user is practically nill.

Now, same bug, but for some reason you've buried significant functionality in this sequence that 10% of your users are going to want to use, it's more important but still a minor bug that doesn't really affect the user's ability to use your software. It does make your software seem less professional, so maybe you fix it at the next major update.

One more time, same basic bug, but this time instead of just throwing an error message and continuing like nothing bad happened, it throws an error and then crashes your program. Worse if it corrupts any saved data. That's a serious bug, and you want to fix that ASAP and push out a free patch to all your customers as soon as you possibly can. That's like, work-around-the-clock-to-fix it important, because there is a very good chance you will lose 10% or more of your customers over it.

Well, sure, except that this assumes that you are PERFECT in your ability to predict the effect of a bug.

For 99% of bugs that you come across before the release, you know exactly how it will affect your customers and exactly how important it is to fix. Those 1% are the ones that come out of the blue, they are rare, and they usually don't affect a lot of people. But sometimes they do.

However, once you know about a bug (what it is and what it does) it's very easy to determine how it impacts your customers. What you are thinking of are bugs that you think you understand, but really don't. That's different, and falls into that rare 1%. It's almost like you've found Bug 1, it's common enough that it is something to be a little concerned about, but it doesn't actually do anything so you ship anyway. What you did not know is that there is a subset of Bug 1, called Bug 1a, which with additional conditions (making it even rarer than Bug 1 itself) is absolutely devastating to your program.

You missed Bug 1a going out the door, even though you caught Bug 1 but decided it wasn't worth fixing at this time. Now you have to determine how many people Bug 1a affects, if it is just a handful you can put it off - it isn't worth fixing. If it's a significant number of people then you'd better think about fixing it soon.

It's not a difficult process to figure out how much a bug affects your users, but you are definitely not going to catch all the bugs, and that's true for serious bugs that are subsets of minor bugs.

probably good idea; definitely bad example (3, Insightful)

pem (1013437) | about 4 years ago | (#31648700)

If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.

When I'm trying very hard to make a program do what I want it to, the more hoops I have to jump through for every iteration of trying to make it work, the madder I get. So, the fact that the software has dark corners that you can get to like this is already a major strike against it...

Re:probably good idea; definitely bad example (1)

hedwards (940851) | about 4 years ago | (#31648804)

You must be a Windows user or haven't updated to an Apple OS past the old world Macs. The only way of eliminating those dark corners is by eliminating them. Which coincidentally is the thing which angers people more than an obscure corner of the app having issues. I've largely given up on Windows except for a few things because there's somethings which you just can't do.

And others like disabling WMP's stranglehold on my MP3 player requires a somewhat obscure incantation involving deregistering a dll file. Or that time when the resolution wouldn't stay set via the control panel and I had to go reg diving to change it to what I wanted on a regular basis. As broken as that was, it was nice to be able to rig up a simple tweak via an obscure method of screwing with the registry.

Someday somebody will find the line of code that causes windows to work perfectly at MS and be horribly, horribly broken everywhere else. They'll be awarded a Nobel peace prize for all the peace and quiet they provide.

Re:probably good idea; definitely bad example (4, Funny)

WrongSizeGlass (838941) | about 4 years ago | (#31648976)

The only way of eliminating those dark corners is by eliminating them.

And today's Yogi Berra award goes to hedwards. We'd like to thank everyone who participated for participating and the winner for winning.

Re:probably good idea; definitely bad example (5, Funny)

pem (1013437) | about 4 years ago | (#31649172)

When I wrote:

When I'm trying very hard to make a program do what I want it to, the more hoops I have to jump through for every iteration of trying to make it work, the madder I get.

then you replied:

You must be a Windows user or haven't updated to an Apple OS past the old world Macs.

I have been racking my brain for the last half hour, trying to figure out what I wrote that bothered you so much that you felt compelled to resort to this sort of name-calling, but I can't figure it out, so expect a communication from my lawyer demanding compensation for this terrible libel you have committed about my computing practices in front of the entire slashdot community.

Re:probably good idea; definitely bad example (1)

Bigjeff5 (1143585) | about 4 years ago | (#31649334)

Not if it is some obscure functionality that hardly anybody is going to need. If you have a lot of features, that's the only way to do it.

Sure, you could make your program do less, but why the hell would you want to do that?

Re:probably good idea; definitely bad example (1)

pem (1013437) | about 4 years ago | (#31649830)

Sure, you could make your program do less, but why the hell would you want to do that?

Maybe because you believe in the Unix way of small programs to do a single thing well?

Uh, Duh? (0)

Anonymous Coward | about 4 years ago | (#31648706)

Sums it up nicely

Thank you, think you very much

Dangerous approach (4, Insightful)

mmmmbeer (107215) | about 4 years ago | (#31648730)

This sounds a lot like the "Good Enough Software" policies that certain companies used to have. It's true that having a few minor bugs is acceptable; in fact, it's pretty much inevitable. But you should expect to have bugs that you haven't even noticed at the time you ship your software. If you start ignoring the bugs you do know about, you increase the total number considerably. From there, it's a slippery slope. Pretty soon, you'll be answering bug reports with a chorus of "Minor, leave it," and your code will be riddled with tons of minor bugs. Your users will go from "huh" to "what?" to "dammit" to "f*ck this!" Your software will look sloppy and unprofessional, and even if none of the bugs are showstoppers, your customers will be looking for alternatives.

Re:Dangerous approach (0)

Anonymous Coward | about 4 years ago | (#31649558)

You're right.

While I see that you cannot ship without bugs for obvious reasons, I don't like how a lot of commenters make it sound like many bugs shouldn't be fixed or left in until later. Once you're getting lazy on this front, the quality of the software degrades. We all know that bug fixing gets more and more expensive the older the bugs are. Not to speak of the resulting bad image.

It's not a bug...... (0)

Anonymous Coward | about 4 years ago | (#31648746)

it's a feature... There's your fix :)

Hitchhiker's Guide to the Galaxy (0)

Anonymous Coward | about 4 years ago | (#31648748)

The Economics of Prefect Software.

Maybe. (3, Insightful)

Junior J. Junior III (192702) | about 4 years ago | (#31648750)

The cost of fixing all the bugs in your program and then being sure you fixed them all is way too high compared to the cost of having a few users hit some bugs they won't care about.

I think it also depends on how much it costs to remove the bugs. Often times, the small bugs that people are more likely to accept or tolerate are also very easy to fix. When the cost of fixing the bug is very low, it should be a no-brainer to do it. If on the other hand the bug is expensive to fix -- requiring a complete redesign and re-coding, then if the bug is not severe it may well be better to leave it in.

Re:Maybe. (0)

Anonymous Coward | about 4 years ago | (#31649126)

Fixing the bug is cheap. The problem is finding the bug. Once a user finds it and reports it, you might as well fix it, but it might not be worth spending enough on testers to actually find it.

Re:Maybe. (1)

Bigjeff5 (1143585) | about 4 years ago | (#31649628)

When the cost of fixing the bug is very low, it should be a no-brainer to do it.

For large programs especially, but with any program really, there is a minimum cost to fix any bug. Most of them involve time, but there are other costs as well. Because of this, there are bugs that are small enough that never make sense fixing, unless you are already fixing a larger bug and fixing the small bug at the same time adds minimal extra cost. If there are no more large bugs to defray the cost of fixing the small bugs, it may never make sense to fix the small bugs if they are small enough.

Wrong name (1)

aBaldrich (1692238) | about 4 years ago | (#31648754)

It should have been Perfect Software-Econonmy or something like that. The Perfect Software(tm) has zero bugs, and if such a program ever happens, its cost will be very high.

Re:Wrong name (2, Funny)

betterunixthanunix (980855) | about 4 years ago | (#31648822)

int main()
{
printf("Hello, world");
return 0;
}

I demand your first born.

Re:Wrong name (1)

zippthorne (748122) | about 4 years ago | (#31649014)

$cat hw.c
      int main() {
            printf("Hello, world");
            return 0;
      }
THEEND

You sure about that? (1)

zippthorne (748122) | about 4 years ago | (#31649080)

Bah, stupid submit button right next to the continue editing button.


$cat <<endhere >hw.c
> int main()
> {
> printf("Hello, world");
> return 0;
> }
> endhere
$gcc -o hw hw.c
w.c: In function ‘main’:
hw.c:3: warning: incompatible implicit declaration of built-in function ‘printf’

Re:You sure about that? (1)

betterunixthanunix (980855) | about 4 years ago | (#31649180)

Can you point out the error? I see a warning related to not including stdio.h, but it is still valid C code and will still do exactly what you expect.

Re:You sure about that? (1)

russotto (537200) | about 4 years ago | (#31649476)

He forgot -Wnone. And the "return 0" is entirely unnecessary; the specs say to print "Hello World.", with no requirement on the return value. This overdesigning of the simplest tasks is costing far too much money :-)

Re:You sure about that? (0)

Anonymous Coward | about 4 years ago | (#31649568)

return 0 may be unnecessary, but a return value from main is required by spec, and lacking it can be a serious bug on some architectures depending on calling conventions: The caller (startup code in this case) will pop a return value from the stack since main always returns an int, but without a return statement, nothing was pushed to the stack, so the program's stack is now trashed.

I'm not sure I buy the argument (2, Insightful)

Palestrina (715471) | about 4 years ago | (#31648772)

Software is not so different from other engineering disciplines that we cannot learn from the best practices of adjacent fields. Although no human endeavor -- other than being Pope -- is infallible, we do see disciplined attempts to measure, manage and improve quality levels. The point is not to reduce the quality level to zero, but to know what your quality level is and be able to hit your mark. What level of quality is needed will depend on the market, your customers, the competition, the frequency of releases, whether the software is easily updated or burned into firmware and devices, etc.

In the end, the best way to create higher quality software is not to find and fix more bugs. It is to use a disciplined approach to programming that introduces fewer bugs in the first place. If you focus on defect detection and removal, then you are fighting the wrong battle. You can't win doing it that way. Quality software comes from a disciplined process at all stages, from requirements to testing, and not just as an endgame activity to sway as many bugs as you can.

Re:I'm not sure I buy the argument (1)

Tablizer (95088) | about 4 years ago | (#31649336)

But the problem is that bug-severity level is generally subjective. Is a broken X worse than a broken Y? Without an objective metric, a "mechanical" way to measure quality is elusive.

In the end, the best way to create higher quality software is not to find and fix more bugs. It is to use a disciplined approach to programming that introduces fewer bugs in the first place.

The problem is that requirements tend to change too often. If you have a fixed target, it's easier to be anal about getting it right. However, often users and designers don't really know what they want until they use a working product.

For example, I've been working on an open-source sql query assistance tool[1] for a few years now (side pet project), and I've scratched much of it and started over 3 times already because when it gets close to being usable, I find that the UI and feature interaction is not to my satisfaction and not sufficiently better than what it intends to replace.

[1] Sort of like a cross between Toad, MS-Access, and a scripting language.

Err. Dumbo. (0)

Anonymous Coward | about 4 years ago | (#31648790)

They are not bugs.
They are DEFECTS.
Pure and simple.

That little example of the 'trivial' bug, if it is the feature, integration, function, exporter, importer, etc.. without which the user cannot work. If it is the feature for which they actually bought the product. And they have now wasted their time and money buying, installing, partially configuring the tool. And now, due to the incompetence of the developers they cannot continue. Then they Will think you are a Jerk, and that -all- developers are jerks. And they are right. I've worked at a 6-sigma organisation, it's not actually very hard to write bug-free code, you just have to care.

once again. They are NOT BUGS. They are DEFECTS caused by lacklusture workmanship.

If they need it, and it's buggy, it's annoying (3, Insightful)

Tsu Dho Nimh (663417) | about 4 years ago | (#31648862)

... a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble

Is going to be one extremely unhappy user because they had a reason for going that deep into the sub-cellars of the software to get at that obscure feature ... and it is likely that they are the sport of user who is a bit more tech-savvy and ready to bitch than Joe Average user.

Re:If they need it, and it's buggy, it's annoying (1)

Kral_Blbec (1201285) | about 4 years ago | (#31648934)

Unless they had no reason to hit the A button and it was an accident that just happened to trigger an error message without actually breaking any functionality.

Re:If they need it, and it's buggy, it's annoying (2, Insightful)

mikael_j (106439) | about 4 years ago | (#31649058)

How about we pretend that the user actually wants to use the feature to avoid analogies along the lines of "It's like saying a car is acceptably broken if the engine explodes when you turn on the radio since we can assume the driver had no intention of actually using the radio, that's just an obscure extra feature that no one uses..."...

Re:If they need it, and it's buggy, it's annoying (1)

Bigjeff5 (1143585) | about 4 years ago | (#31649652)

It's more like there is a small beep on the radio when the users changes radio station while turning the ignition, but only if the park break is on. Very strange, and definitely a bug, but it affects an extremely small number of people and does not affect them in any significant way.

If the engine blew up, that would be different, but it's just a beep on the radio - who cares?

Clear cut? (0)

Anonymous Coward | about 4 years ago | (#31648864)

I agree with what you are saying, but will the economic v. code perfection decision always be clear cut? Could lead to a slippery slope...

Functional Tests and Unit tests (1)

fysdt (1597143) | about 4 years ago | (#31648904)

There are programming methods that aim to decrease the amount of bugs substantially with functional testing and unit testing. Unfortunately these tests don't make software 100% bug-free but it they do reveal 'big bugs'.

The core argument does make sense. (2, Informative)

Max Romantschuk (132276) | about 4 years ago | (#31648910)

Sometimes it's better to ship a product and deliver it to 95% of the user base instead of having everyone wait because 5% wants feature X which is broken.

But there is the option to disable feature X, so rather than knowingly ship with bugs you can often have the program show a notice that this feature is disabled or something like that.

Generally when building software you'll have "Quickly", "Lots of features" and "Bug free". Depending on the software and project stage you'll want to strike a different balance. Releasing an alpha which has lots of features quickly with loads of bugs is OK. Releasing a final release of a program handling financial transactions with loads of bugs is never OK.

But yes, it's a question of economics, and what makes sense for a given project at a given time.

But it's just rhethorical (1)

ET3D (1169851) | about 4 years ago | (#31649218)

I'd bet that the majority of CEO's know that most software is released with bugs (the others are not in the software business :). Any product manager worth his salt will be able to manage priorities correctly. So the entire argument is built on false assumptions. Sure, there are bad managers who will get priorities horribly wrong, but even they probably know that not all bugs can be squashed. To present this as if it's something new and revolutionary is silly.

sometimes crash == possible exploit (4, Insightful)

Eponymous Coward (6097) | about 4 years ago | (#31648946)

It isn't always easy to judge the severity of bugs. Exploits often grow from a black hat figuring out how to crash a program. Some of the greatest exploits started with the smallest of footholds.

This applies to everything really... (0)

Anonymous Coward | about 4 years ago | (#31649042)

Creating a 100% perfect product is just a terrible idea for business.

Of course, in software, creating a perfect product is hardly an achievable thing to do, especially if you are actively working on it.
Whether it is adding new features, releasing optimizations for functionality X, or just some bug fixes, you shouldn't really ever be able to create anything "perfect".
If you somehow managed to create something perfect, then you already never had much scope for the product in question.

I use a simple example, PowerMenu for Windows adds 4 new menu items on all windows context menus to change priority and transparency, set it Always On Top or Minimize to the system tray.
It was built with Windows XP and below in mind. It worked and it worked well. You can't really do much else with it. (well personally i think it would be nice to have had the ability to minimize to the powermenu tray icon rather than clog up the system tray)
Okay, my example wasn't good, sue me.
But you get the idea... right..?

Duh. (1)

Vellmont (569020) | about 4 years ago | (#31649066)

Isn't this how people ACTUALLY write software already? Resources aren't infinite, and unless you're NASA writing code for the space shuttle, all bugs don't have to be fixed. I learned about triage and fixing the "big bugs" 15 years ago in school and it was certainly common practice in the industry then.

I was going to say "what a stupid article, everyone already knows this". But judging from the responses I guess everyone doesn't.

It's *intended* accleration... (0)

Anonymous Coward | about 4 years ago | (#31649072)

Did Toyota Sponsor this article? Really, it's a *little* bug, we should just let it go....

NO, IT IS NOT !!! (-1, Troll)

Anonymous Coward | about 4 years ago | (#31649164)

You would not be soooo GLIB if you have the misfortune of being in a car that had unintended acceleration, and a driver waaaay too drunk to do anything about it except crash. If tt were not for Toyota's very, very bad software (I smell MSFT for some reason), he'd still be here to talk about it.

Other golden rules (0)

Anonymous Coward | about 4 years ago | (#31649076)

1. If you're aware of a bug, stop and fix it.
2. If you cannot fix a bug quickly, you've got a design problem. Stop and fix it.
3. If you have so many bugs that you need a tool to track them, you've got a management problem. Stop and fix it.

insight on. (1)

eexaa (1252378) | about 4 years ago | (#31649138)

I might misunderstand the actual message, but still, I see a small benefit for leaving minor bugs around:

Imagine a long-running project (just like cobol+finances). Several core programmers go away, and you have a big heap of code that no one can maintain, therefore you will need to rewrite all your software "as soon as possible" and spend huge amount of money on migration.

If you leave a tiny annoying thingy there, it will inevitably attract hackers that:

a] formulate the real nature of a bug (gaining insight on how it really works)

b] eventually hack through all the code and apply the oneliner (slowly becoming experts on the topic. Happens only if source is available to users/admins)

In short, 'annoying non-critical bugs produce maintainers'.

(well, maybe I am a development lunatic)

That's a symptom, not a bug. (1)

John Hasler (414242) | about 4 years ago | (#31649144)

> If a user who goes through three levels of menus, opens an advanced
> configuration window, checks three checkboxes, and hits the 'A' key
> gets a weird error message for his trouble, that's a little bug.

That's a symptom, not a bug. It could be a symptom of a buffer overflow that, if not fixed, will soon be exploited to clean out the bank accounts of 100,000 of your customers. You won't know until you've fixed it.

mediocrity (5, Insightful)

electrogeist (1345919) | about 4 years ago | (#31649162)

"Once genius is submerged by bureaucracy, a nation is doomed to mediocrity. " -Richard Nixon

s/nation/project/

Re:mediocrity (1)

FlyingBishop (1293238) | about 4 years ago | (#31649654)

Between bureaucracy and Nixon-style genius, I'll take mediocrity.

Really, that statement was a cover for Nixon quietly subverting the bureaucracy. The bureaucracy exists for a reason, and it is effective. Genius always thinks itself better than the group. It is generally wrong.

Im not aprogrmmer but do programming (0)

Anonymous Coward | about 4 years ago | (#31649170)

Programmers view my approach to programming a bit weird. But so do I, they always claim bugs aren't a problem, its ingrained in the way you do things.

You can do things a LOT better. For starters stop making the same mistake many times.

And for gods sake don't always ask as much code as one possibly can do in any amount of time its inanely stupid. If the code is worth to you 20,000$ the be prepared to pay 20,000$ for it. It don't get better because you may sometimes get it cheaper if you luck out. Because in the end this always bites your ass.

Those bugs indicate a broken dev process (0)

Anonymous Coward | about 4 years ago | (#31649204)

if the simple and easy stuff is broken (the stuff that can be automatically checked),then bigger bugs lurk below. Article is dumb, assumes the dummy programmer can know the difference.

High Quality in Software Requires THINKING (1, Troll)

CAOgdin (984672) | about 4 years ago | (#31649238)

I know, that's too much to ask of modern code monkeys. How many of you who "good enough" quality have ever even read a book on "Software Engineering?" Have you even HEARD of the original NATO conference on that subject? How many have studied interesting "Software Physics." Yes, all code I write has bugs, because I am not omniscient. There are inputs and environments I never imagined the program having to cope with. But about half the code I write has two things rarely seen in code today: 1. Comments in the form of Assertions (e.g. "At this point, input XYZ is confirmed to be in the range 87...92". 2. About half the lines of actual code (absent comments) are validation of input conditions from the world (user and environment) outside the program itself. Perfection is not actually achievable, but IT'S THE ONLY TARGET WORTH PURSUING. Companies like Microsoft don't even try, because they're not in the software business; they're in the money-making business. Professionals care; money-grubbers aren't.

Economics of Perfect (Gaming) Software (1)

macraig (621737) | about 4 years ago | (#31649266)

Yeah, in my own mind I inserted that extra word in the title, and I was disappointed that it wasn't about that at all. I'd like to see an article about that, describing how the "perfect" game would be an economic Bad Idea, and including interviews with game developers who finally admit that they deliberately repeat old shortcomings and mistakes and stop short of perfection, knowing that the perfect game would completely destroy the market for next year's game. I can think of one or two that actually tried to damn the torpedoes and thwart this dynamic, but ultimately they got shut down by the suits holding the purse strings.

Doesn't sound like a little bug... (1)

argent (18001) | about 4 years ago | (#31649450)

If a user who goes through three levels of menus, opens an advanced configuration window, checks three checkboxes, and hits the 'A' key gets a weird error message for his trouble, that's a little bug.

1. If that error message refers to "H-Tilt", then that's a big bug no matter how many levels of menus you go through.

2. If a user can provide a reliably reproducible test case like that for the bug, then it's one you should have caught in testing.

"If X is less than the cost of a recall..." (1)

Minwee (522556) | about 4 years ago | (#31649472)

Is this still Slashdot? Why has nobody made the obvious quote from Fight Club yet?

I haven't even seen a numbered list ending in "Profit!" Why are you all letting me down?

A lesson (1)

BigBadBus (653823) | about 4 years ago | (#31649482)

I used to work for a small computer firm in Weybridge, England. Oh, damn it, since it collapsed ten years ago, I may as well name it: MTA (Computer Consultants) Ltd. We had a project between 1997-9 to write a software demonstrator for a radar resource manager for the Eurofighter project, for DERA Malvern. The project was divided into two parts, of which phase 1 went through a successful factory acceptance task. However, a few bugs had been found in the programme after this, one of them, due to me, was fairly serious. It was a small mathematical error but I produced a bug in a few mninutes.
Now MTA had gone through a turbulent time, having to sack all of its staff because of the lack of money and the rehiring them. MTA were annoyed that DERA decided to stall the programme while it did a full evaluation of the software, rather than go to phase 2, which would have provided money for the coffers. At this point, the only thing keeping MTA afloat was hope for this project and a tiny project. MTA stalled on delivering the software, saying they would only do so when the software went to phase 2. By the time MTA had backed down and provided the patch, I had already left. DERA cancelled the project and MTA went bust within the year.
Moral? It doesn't pay to piss off those who pay you.

Obscure bugs can be fatal ones. (4, Informative)

Garrett Fox (970174) | about 4 years ago | (#31649500)

The post talks about minor bugs being the ones that are hard to reach, but that's not necessarily the case. There was a piece of radiation-beam hardware used for cancer treatment (the Therac-25 [wikipedia.org] ), that became a case study in engineering because of a literally fatal flaw. It was possible to mis-configure the machine so that it struck the patient with a much more powerful radiation beam than was normally allowed. The relevant point was, this situation only happened if the operator did some obscure, seemingly unlikely combination of actions that would result in a lead plate getting misaligned or something. Yet it happened at least six times, killing at least two people. The fact that the bug was caused by this particular sequence of actions made it that much harder to identify -- and it was not a minor bug worth ignoring.

My TV Remote has bugs... (1, Interesting)

tonywestonuk (261622) | about 4 years ago | (#31649602)

If I connect my TV remote to the mains AC, it will break. I blame the makers for not 'validating' my input voltage. My Cups/Mugs all have bugs, as when I drop them, they break....silly makers for not designing in dampers to cushion the blow. My car has bugs.... I can very easily crash it, how dare the manufacturers make something I can crash by just pressing the buttons/ turning the wheel in the wrong order.

My point is, that practically everything will fail, or demonstrate unpredictable behavior if it is subject to conditions to which it is not designed to handle. We accept this, as a fact of life!....Why should software be judged any different, just because it's 'virtual' and cant really be seen as a real world object?...to make a perfect bug free piece of software is practically impossible.....well, maybe 'hello world', and even this will fail should it be run on an architecture it was not designed to run on.

Another reason (0)

Anonymous Coward | about 4 years ago | (#31649694)

Large corporations often like to buy "Enterprise" software with support contracts. If the software works perfectly, nobody is happy: the IT staff responsible for supporting the software have less to do and worry about their job security; IT management does not get anything demonstrable from the support payment; the vendor's support staff do not get a chance to learn how the software is being deployed in the field; the vendor's management have a high cost-per-ticket on their support line. Nobody builds relationships. If bugs cause small or medium problems, but the problems are handled well, corporate customers actually like this: rationally, it's a successful test of the support model giving reassurance that a big problem might be handled well too; irrationally, people feel better about a company after it handles a problem extremely well - e.g. quick resolution and apologies - than they would if the problem never arose in the first place.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...