Beta
×

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!

Why Buggy Software Gets Shipped

Zonk posted more than 7 years ago | from the life-is-pain-princess dept.

422

astonishedelf writes to mention an article in the Guardian about the hard reality of why buggy code is sold on retail shelves. From the article: "The world's six billion people can be divided into two groups: group one, who know why every good software company ships products with known bugs; and group two, who don't. Those in group 1 tend to forget what life was like before our youthful optimism was spoiled by reality. Sometimes we encounter a person in group two, a new hire on the team or a customer, who is shocked that any software company would ship a product before every last bug is fixed. Every time Microsoft releases a version of Windows, stories are written about how the open bug count is a five-digit number. People in group two find that interesting. But if you are a software developer, you need to get into group one, where I am."

Sorry! There are no comments related to the filter you selected.

Windows Software Shop :-) (4, Insightful)

Whiney Mac Fanboy (963289) | more than 7 years ago | (#15402026)

Typical Windows Software house:
Vault's backend makes extensive use of features specific to Microsoft SQL Server. Contrary to popular belief, SQL isn't portable.
*shakes head* and then this:
Linux and MacOS users have problems over how end-of-line terminators show up.
Ouch!

Anyway, I do agree with the author for the most part (its all pretty 101 risk assessment stuff). It is inevitable that software will have bugs in it (especially commercial software shipped to a schedule). This is not really news tho'.

What I would like to see is some vendor honesty. How about making a list of known bugs available to your customer prior to purchase? (I know, I know, fairly warning a customer is madness, etc etc).

Re:Windows Software Shop :-) (0)

Anonymous Coward | more than 7 years ago | (#15402198)

Tell me, oh wise consumer (which you obviously think you are, seeing as how you blatantly point out your purchasing decisions even in your own account name), how many of your kind would even be interested in wading through a potential list of tens of thousands of bugs, all described in a technical manner? Oh, that's right, none. Because the people like you who are complaining about it aren't the people that are actually using the software.

Oh, yes, by the way...did you notice that Mac OS X has been updated...oh, I don't know...several point revisions, and Apple isn't making a "list of known bugs available" to their customers "prior to purchase," at least not in any way that's going to draw the attention of the people that would need to read it? I bet you did, but you ignored it because you dropped a few thousand on a computer that you're trying to define your personality with. Grow up. Everyone else will, I'd suggest you start early if you don't want to be left behind.

Re:Windows Software Shop :-) (3, Interesting)

packetmon (977047) | more than 7 years ago | (#15402214)

How about making a list of known bugs available to your customer prior to purchase?</i> I don't think the Board of Directors on any publicly traded company will allow this. The problem with many traded companies (and I'm using publicly traded companies since MS is mentioned) would be that the company wouldn't likely meet financials. Hence many pouring out shoddy programs. Imagine the trading price of MS if it did ship a list of known bugs alongside their products... I would think consumers would wait for a stable product before buying. Even if they did ship what they deemed a stable product, whose to blame for someone finding a flaw? The programmer who didn't have an insight to think outside the box similar to the hacker (and I use that term in its purest sense) who broke the product? Speaking of MS...

From:  Microsoft Security Response Center <secure@microsoft.com>
To:  "xxxx" <xxxx@hushmail.com>
Cc:  Microsoft Security Response Center <secure@microsoft.com>

Thank you for the update with regards to your findings. We are still
going through the repro stages of the case and there appears to be some
confusion over the concern. Do you happen to have a network trace of the
behavior that I could work with our development teams in reviewing to
ensure that we are looking at the same concern and avoid any possible
confusion on the matter?

Thanks,

Adrian
Microsoft Security Response Center

I've broken MS' MSRPC in a real bad way. There are no ifs ands or buts. I passed the information off to Microsoft instead of passing code to a full disclosure list. I've replicated this over and over, remotely and locally. I know for a fact because of the architecture of networking they will never be able to fix this. So what would you think as a consumer about to purchase a product with a hole that can never be filled.

Re:Windows Software Shop :-) (2, Interesting)

Sproggit (18426) | more than 7 years ago | (#15402218)

No no no no no no!!!

It is NOT inevitable that software will have bugs in it.
By your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.

This whole fucking "tinkerer" mentality that self important developer assholes have foistered on the rest of mankind, is no different from the self important tinkerer mentality that steam engineers foistered in the 1800's.

Take solace in the fact that the software development world will ultimately fall into the same engineering disciplines as steam and mechanical enginering before it, and whatever mankind pulls out of our asses after it.

Software and any other IT components will ultimately be consumer grade, and the inner mechanics (and bugs) will be a problem for the engineering QA department.

Re:Windows Software Shop :-) (2, Insightful)

Anonymous Coward | more than 7 years ago | (#15402373)

All bridges DO have defects - a weld may be slightly off-center. A beam might be 1/8" wider/longer than it's supposed to be, the cement covering it may be cracking. The point is that we're all human and imperfect, so therefore the things we create are imperfect.

It is the job of the engineer (whether for bridges or software) to make sure that the mistakes that ARE made are not the critical ones - the ones that make the bridge collapse or the software crash.

Until the human race as a whole attains God-hood (whatever your diety, this is unlikely), this is a fact of life.

Re:Windows Software Shop :-) (4, Insightful)

Whiney Mac Fanboy (963289) | more than 7 years ago | (#15402409)

By your reasoning, it is inevitable that bridges have design defects in them, and that at some point (in their usable specified lifetime), will collapse.

I didn't say all software will have major bugs that lead inevitabley to the collapse of the software. Just that all software will have bugs.

All bridges have defects too you know - the suspension cables will be slightly uneven, or some features of the fascade will be unsymetrical. Bridge engineers make damn sure there are no structual problems that will lead to collapse (but even they fail sometimes).

I wish software engineers would be more like bridge engineers as well, but the cost of failure (and the cost of fixing in the event of a failure) are so different between bridges & software that its not likely to change.

Re: Vendor honesty (5, Funny)

Medievalist (16032) | more than 7 years ago | (#15402308)

What I would like to see is some vendor honesty. How about making a list of known bugs available to your customer prior to purchase?
Good idea! You go first.

Vendor honesty doesn't pay... (1)

Captain Sarcastic (109765) | more than 7 years ago | (#15402393)

The problem with vendor honesty is that it backfires on the vendor.

Let us suppose that WidgetWorx version 1.1 gets shipped. Inside the package is a list that says, "at the time of shipment, these are known bugs/shortcomings/issues."

An ambulance service that uses WidgetWorx for their dispatching service, and something goes wrong that leads to a patient dying. Said patient's estate could hire a savvy lawyer who would make a wrongful death claim against the ambulance service for "using a software package with known defects, thus indicating negligence." Even if the package did not have anything to do with the patient's death, it would be an indication of careless behavior and "lack of due diligence" by the ambulance service.

The ambulance service (or its insurance company), in turn, would sue the manufacturers of WidgetWorx to recoup their losses... and the list of issues would make it a slam-dunk.

I'm not denying that "vendor honesty" as you describe it would be a good thing in a perfect world. Unfortunately, this world, like my grammar, ain't perfect.

Yeah how about those examples? (2, Insightful)

Mateo_LeFou (859634) | more than 7 years ago | (#15402487)

"Cost: Very high. Vault's backend makes extensive use of features specific to Microsoft SQL Server"

Read: we got embraced and extended all to hell. What do to? Blame SQL! That's right, the language itself! It "isn't portable". Also blame users! "People who refuse to use SQL Server can't use Vault."

And here's some typical MS morality for you: "I'd probably even patent this algorithm even though, in principle, I believe software patents are fundamentally evil."

I don't expect bug-free software of any real complexity to be shipped often. But the examples are both interoperability problems, and not actual bugs. Looks like an excuse to marginalize the non-windows crowd. "...only affects users on non-Windows platforms, a rather small percentage of our user base."

The numbers are too big (2, Insightful)

truthsearch (249536) | more than 7 years ago | (#15402490)

It took a leaked Microsoft memo to find out Windows 2000 shipped with 65,000 bugs [msversus.org] . Even the author of the memo wrote [zdnet.co.uk] , ""How many of you would spend $500 on a piece of software with over 63,000 potential known defects?"

The problem is with a number that large, no matter how small the proportion is to code size, the backlash would be huge. No potential customer could hear that number and then actually want to buy a copy. I believe they should disclose as much information as possible. But from their perspective no amount of marketing could make up for the negative impact of disclosure.

Welcome to Group One (1, Insightful)

eldavojohn (898314) | more than 7 years ago | (#15402027)

The world's six billion people can be divided into two groups: group one, who know why every good software company ships products with known bugs; and group two, who don't.
If you are in group two, than I post this for you.

Theoretically, there is no language that is more or less prone to bugs than any other language as understood in Turing Completeness [wikipedia.org] . Without delving too much into this, it simply states that all languages emulate a Turing machine to some degree and therefore should be capable of everything a Turing machine is capable of (although I don't think this says anything about time/space efficiency). One language may be better supported than another or have more libraries but we are going to assume these issues to be irrelevent to our discussion on applications--let us look as all applications being written in the same low level language that your computer directly understands. I don't want to compare architectures either, let us assume they are equivalently prone to bugs and are basic Turing machines.

If we think about a binary executable program (machine language consisting of ones & zeros) then we must recognize that the program's memory space has many many states. Open up your favorite word editor. Type in a sentence you're thinking about. Highlight part of it and bold it. Highlight a different part and hit escape seven times. Do you think that this scenario was tested?

My point is that it is an impossible herculean task for the developers to test any application in every state. They can come close and smart software design can leave an easier job for the testers but it will never be completely tested.

I would define the term bug as "undesired behavior" and I suggest they be thought of in this manner. I will also make the statement that no piece of software can be garunteed to be free of undesired behavior due primarily to the above analysis of them being amazingly complex machines with a large state space. To take a stab at it mathematically, this browser (Firefox) is operating with a 48,604 Kb memory footprint (I have many tabs open). That's 49770496 bytes or 398163968 bits. Each bit can be on or off meaning that for the amount of memory my browser occupies now, there are 2^398163968 different possible states for any similar sized application running. Now, to add even more complexity, that state space adjusts according to what the application requires for memory.

As our applications become more bloated, the situation only worsens. That is why development phases are either getting longer or requiring larger teams from the beginning of the project (mythical man month noted). At what point does the testing phase end? Hopefully never. Hopefully your software that you acquire is supported until the end of time ... but there are already too many projects out there left for dead.

If you're wondering how companies can ship software with bugs, you should be wondering how is it possible not to ship software with bugs. You should also understand that there are rigorous standards and practices implemented along the way to prevent the most devestating bugs from escaping. If the company making the software has a history of failing in extinguishing the most glaring of errors, simply stop purchasing their software or demand the support you need.

Re:Welcome to Group One (3, Funny)

Threni (635302) | more than 7 years ago | (#15402080)

> If you are in group two, than I post this for you.

> Theoretically, there is no language that is more or less prone to bugs than any > other language as understood in Turing Completeness. Without delving too much
> into this, it simply states that all languages emulate a Turing machine to some
> degree and therefore should be capable of everything a Turing machine is capable
> of (although I don't think this says anything about time/space efficiency).

If you understood Turing Completeness you'd be in group one.

Re:Welcome to Group One (1)

hunterx11 (778171) | more than 7 years ago | (#15402083)

Theoretically, there is no language that is more or less prone to bugs than any other language as understood in Turing Completeness.

I have a theory that most software written today is written by human beings, or is generated by computers in a very predictable and straightforward manner given human input. Actually, this isn't a theory, it's an empirical observation, and I doubt many people would contest its truth. There are differences in debugging languages using different programming paradigms. Non-monadic code written in a functional language, for example, need not have every state checked; the correctness of such code is actually provable.

Re:Welcome to Group One (1)

YU Nicks NE Way (129084) | more than 7 years ago | (#15402146)

the correctness of such code is actually provable
Oh? Really? I have before me a small segment of purely functional Scheme which implements an operator called "lambda". It takes a valid expression, and applies the "lambda" operator to it. Can you tell me how much hardware my customers will need to buy to support this feature (called "Church combinator support", for those of you interested)?

You can't? Gee -- isn't that a bug in the program, open source or not?

Re:Welcome to Group One (2, Funny)

greg_barton (5551) | more than 7 years ago | (#15402233)

Type in a sentence you're thinking about. Highlight part of it and bold it. Highlight a different part and hit escape seven times.

ON, I did that. Where's my damn easter egg?

MS Word Easter Egg (1)

eldavojohn (898314) | more than 7 years ago | (#15402257)

Where's my damn easter egg?
Calm down. Open up Microsoft Word, type "=rand()" without the quotes and hit enter.

Re:MS Word Easter Egg (2, Funny)

cerberusss (660701) | more than 7 years ago | (#15402419)

Open up Microsoft Word, type "=rand()" without the quotes and hit enter.

You bastard! When I typed this, my PC froze! But since it's also a server, it rebooted itself, mailed a Nigerian scammer my home address, started a DDOS on the local authorities and blew itself up, taking half of the data center along with it. When I came home, the Nigerian scammer had raped the dog and the cable guy from the ADSL company who had showed up at my house. When I told my wife, she replied that she didn't care since the left me this morning and took the house along.

So thanks to your FUCKING easter egg, I am divorced, broken, homeless and worst of all, WITHOUT AN INTERNET CONNECTION.

Thanks for nothing.

Re:Welcome to Group One (4, Insightful)

jizmonkey (594430) | more than 7 years ago | (#15402244)

The article was about why known bugs ("thousands of bugs") aren't fixed before ship, not why all bugs aren't found.

Re:Welcome to Group One (5, Informative)

exp(pi*sqrt(163)) (613870) | more than 7 years ago | (#15402263)

Theoretically, there is no language that is more or less prone to bugs than any other language as understood in Turing Completeness
Frankly, this is complete garbage. Try writing an application in the Turing complete language Brainfuck [muppetlabs.com] or 6502 assembler and compare that with writing in the Turing complete language Haskell. Turing completeness is completely irrelevant and you're simply quoting CS 101 to give your comments an air of authority.

I Thought It Was Relevant (0)

eldavojohn (898314) | more than 7 years ago | (#15402399)

Turing completeness is completely irrelevant and you're simply quoting CS 101 to give your comments an air of authority.
On the contrary, I thought it to be completely relevant in order to dismiss people complaining that one language is more error prone than another. Recognizing that this would only deviate us from the path of the real discussion, I made the assumption that all languages are essentially equal (the premise being that all interpreters and byte readers are simply Turing machines in the end).

There are experts in every language that are very capable of emulating almost anything--without many bugs ... how much work and time goes into this is a variant, however.

You, apparently, did not agree with my assumption. That's fine. Just don't accuse me of throwing in irrelevant information in an attempt to sound like an authority on the matter who is important or intelligent. I know that I am neither and it is insulting to say that I would be so pretentious as to fake it or even desire it.

Re:Welcome to Group One (1)

panthro (552708) | more than 7 years ago | (#15402404)

Each bit can be on or off meaning that for the amount of memory my browser occupies now, there are 2^398163968 different possible states for any similar sized application running.

That's not true at all. First of all, a lot of that memory is the program itself, which isn't going to change, and some of it is probably your OS counting shared library code, which also isn't going to change. Even then, you can't take the variable segments of memory and assume that the application could by its own operation potentially set each bit of memory in any combination of ones and zeroes. There are a lot of memory structures that you can safely say are going to look like such-and-such, greatly reducing your estimate of the number of possible states.

Anyway, testing software doesn't mean taking every possible state into account. That would be ridiculous. Certain things just shouldn't affect one another, so your ones and zeroes in memory situation would basically be a whole whack of "don't-care conditions" (as in truth tables and such) and a relative few significant bits whose values are largely co-dependent. Good programming should compartmentalize the program so that modules affect each other with minimal interaction and thus you really only have to do exhaustive state tests on very small modules.

Re:Welcome to Group One (0)

Anonymous Coward | more than 7 years ago | (#15402428)

[Turing Completeness] simply states that all languages emulate a Turing machine to some degree and therefore should be capable of everything a Turing machine is capable of (although I don't think this says anything about time/space efficiency)

I believe there is a property that all 'reasonable' models of computation can be emulated on a Turing machine with only a polynomial reduction in time efficiency - hence it makes sense to consider problems in P (computable in polynomial time on a deterministic Turing machine) and NP (computable in polynomial time on a non-deterministic Turing machine) even though we don't actually want to run programs on a Turing machine at all. Unfortunately I can't find any specific definitions or names for this...

(Assuming that's true, space efficiency cannot get worse than a polynomial decrease, since the amount of space used is bounded by the time spent performing the computation.)

Re:Welcome to Group One (1)

0xABADC0DA (867955) | more than 7 years ago | (#15402457)

You have a good point about the massive number of states, but you logic is sloppy. You assume that every byte of the heap can have any value, but this is just not true. In a reasonable language there are a great number of states that are simply not possible.

Just because the language is turing complete does not mean that it produces processor complete binaries. In Java there is no way to refer to an illegal address, so you can emulate a tape machine and you can produce a binary with gcj, but that binary will never issue an illegal reference (either to unmapped memory or to the wrong address). If a variable is a protected field then only the object's operations can affect it, so the number of combinations of states it can take is greatly reduced. In fact, the real problem is not the number of states at all but that the way they are interrelated. You could have only a hundred variables and still not be able to tell whether the program operated correctly.

If you program your application in Java or Ruby or Python or basically not-C/C++, then you have a whole huge category of mistake and bugs that are simply not possible no matter what the skill level is of the developers. The choice of language is the greatest factor in reducing bugs.

Re:Welcome to Group One (1)

Retric (704075) | more than 7 years ago | (#15402469)

That's one way to think about things, but in the real world there is a huge separation in the number and type of bugs created when you go from one language to another.

For example :
C++ programs tends to have a both a large number and a wide verity of pointer issues.
Java still has pointer issues but most of them are NULL pointer issues.

Granted they both have casting issues. However, for the same memory foot print you are not going to end up with the same number and type of bugs.

The real reason why most software is full of bugs is people don't realy care. Yes, software is a hard problem but most projects tend to operate by trimming features to fit the schedule vs. focusing on the core problem until you have a rock solid solution and then adding carefully tested features until time runs out.

PS: When people do care you see a huge difference. EX: Few people are willing to use an extremely buggy compiler.

And lo, there was much rebuking (3, Insightful)

linvir (970218) | more than 7 years ago | (#15402028)

I disagree with his grouping. The vast majority of the six billion doesn't give a shit about software bugs. They're primarily concerned with their ability to exchange services and products for money and vice versa, and if they do have free time, they don't spend it fretting about XP's bug count.
But if you are a software developer, you need to get into group one, where I am.
Or maybe even better would be for both groups to continue to exist. The Jedi need the Sith, and smartasses who don't worry about bugs need idealistic noobs who find them shocking. This sounds like the case of someone who's managed to become so surrounded by likeminded coworkers that he's completely convinced that his is the One True Way.

And do we really need that much whitespace [linuxvirus.net] on a news page? I know about that whole '10 words per line' usability mantra, but it looks fucking ridiculous. Why can't all the other website owners just think exactly like me?

Wow, look at all that rebuking. Do I win Slashdot?
(IAJAFSS (I Am Just Another Fucking Smartass Student))

Re:And lo, there was much rebuking (1)

Itninja (937614) | more than 7 years ago | (#15402161)

They're primarily concerned with their ability to exchange services and products for money and vice versa,
Or just find/growing/scavaging enough food to stave of painful hunger and/or starvation for one more day.

Re:And lo, there was much rebuking (1)

linvir (970218) | more than 7 years ago | (#15402220)

Maybe that was the case 100000 years ago when humans first entered the scene, but nowadays the majority of humans aren't starving. Where have you been all this time?

Re:And lo, there was much rebuking (0)

Anonymous Coward | more than 7 years ago | (#15402252)

Africa, Asia, parts of Central America - where there are people starving.

Re:And lo, there was much rebuking (1)

linvir (970218) | more than 7 years ago | (#15402282)

Well said, moron, but 800 million is not a majority, not matter how many times you say Africa.

This is why (0)

gentimjs (930934) | more than 7 years ago | (#15402037)

This is one of the reasons I truly despise the economics of commercial software ... ugh ... every word of the post is correct. $DIETY, I hate commercial software.... FP?

Re:This is why (3, Funny)

PrescriptionWarning (932687) | more than 7 years ago | (#15402089)

compiler error: $DIETY does not exist (except in weight-loss applications). Please use $DEITY.

Re:This is why (0, Flamebait)

mypalmike (454265) | more than 7 years ago | (#15402203)

compiler error: $DEITY is just pretend.

Re:This is why (0)

Anonymous Coward | more than 7 years ago | (#15402264)

compiler error: $DEITY is a template. Create an instance of this object before use.

A separate question (4, Insightful)

Southpaw018 (793465) | more than 7 years ago | (#15402050)

The argument about the enormous bug count in Windows isn't really about every last bug being fixed. The article fails to address a separate question: whether you're allowing the public to do your beta testing for you.

The idea of QC/testing/beta/whatever the heck you want to call it is that you get as many bugs as you can fix while accepting the ones that will remain behind. That's absolutely correct. However, there are companies - like Microsoft - that are notorious for either being sloppy and not getting bugs they should have, or just straight up not caring at all and rushing a product to market that legitimately shouldn't be there.

The argument can even be extended to good coding practices, like worrying about security fron start to finish rather than after you've entered beta (another well known Microsoft flaw, though they're getting better at it). That reduces the number of bugs to begin with, which in turn gives a better product.

That's not what QA is for (1)

BadAnalogyGuy (945258) | more than 7 years ago | (#15402158)

QA is not there to find bugs for fixing. Sure, they may run into a few here and there that are worth the time to fix before the product ships, but by and large the major bugs are caught while the sources are still hot on the developer's local tree. The bad ones that make it to QA fall into one of two categories: 1) bad developers and 2) bad architecture/design. Both of which are great topics for conversation, but not the problem at hand.

What we are talking about is QA and its role. It's role is to identify and label as many bugs as possible. Ideally, no bug would make it unknown to the wild. Even heinous bugs that wipe out user data and go on to crash international banking servers require no more than identification and tagging by QA. What QA is for is to make sure that all behavior by the product is predictable.

Now, one byproduct of making the product's behavior 100% predictable and reproducible is that it becomes easier to write the fixes for those features which are labelled as bugs, but that's a byproduct of QA, not its main reason for existence.

If you work for a company that thinks that QA is supposed to be finding bugs for fixing, you're most likely working in a place where the QA team is stressed out and the product cycle is longer and less productive than other places where QA's role is clearly defined as the assurance of the quality level of a product.

Re:A separate question (0)

Anonymous Coward | more than 7 years ago | (#15402221)

The argument about the enormous bug count in Windows isn't really about every last bug being fixed. The article fails to address a separate question: whether you're allowing the public to do your beta testing for you.

I see you are firmly rooted in Group 2.

Re:A separate question (3, Insightful)

Ansonmont (170786) | more than 7 years ago | (#15402262)

Not a fanboy of MS, but they certainly haven't rushed Vista out. I'll bet that they do ship it in s pretty buggy state when it does come out, but they have delayed its launch it is becoming like Duke Nukem Forever.

Anyway, yes, most people don't care about software, but you also have to look at what the application is trying to do and what you need it to do.

1) Rules of thumb: The last 50% of a project is spent taking it from 95% to 100% (or really 99% as the case may be...)

2) Is the software used for medical purposes? Financial? Downside to those barfing are HUGE. Or is it a game that is meant as a fun diversion? All of those make a difference in people's tolerance for bugs/undesired effects/undocumented features ;-)

The consumers have spoken with their wallets. So far they have said that low cost up front (PC) is worth more than a more stable, polished platform (Mac). Less true now, thouh, XP isn't that bad. I use PC for work, Mac for home, Linux/Unix rarely.

-A

Quick Precis (0)

Anonymous Coward | more than 7 years ago | (#15402059)

Example: Item 10016. Linux and MacOS users have problems over how end-of-line terminators show up. Last October, we tried to fix this and accidentally introduced a nastier bug that prevented users creating new versions of a project.
Short answer: We're incompetent.
Long answer: Our code base is so insanely intricate and unmanaged that we can't implement a simple bug fix without inducing an enormous number of regressions.

Article summary : We're incompetent, but no more so than everybody else.

Member of Group 1.5 Confused (2, Funny)

PrescriptionWarning (932687) | more than 7 years ago | (#15402060)

I propose we call a meeting with Groups 3-12 and 15-20 and see if we can get some kind of real analysis of what Groups 1 and 2 are really thinking.

Re:Member of Group 1.5 Confused (1)

Red Flayer (890720) | more than 7 years ago | (#15402311)

What, are groups 13 and 14 out to lunch?

One reason (Ballmer style!) (0)

fak3r (917687) | more than 7 years ago | (#15402068)

Marketing! Marketing! Marketing!

No idea (4, Funny)

Unski (821437) | more than 7 years ago | (#15402076)

..why buggy $oftware is $hipped. Can anyone help me with thi$?

Buggy code is sold because it is demanded (2, Insightful)

crummyname (977083) | more than 7 years ago | (#15402078)

In many cases, the customer *needs* the software now, bugs be damned. If you don't, your company goes under.

*BAH* (0)

Anonymous Coward | more than 7 years ago | (#15402304)

In many cases, the customer *needs* the software now, bugs be damned. If you don't, your company goes under.

In
1) *MOST* cases, the
2) *VENDOR* needs the revenue in order to meet unrealistic sales forecasts and
3) *PROFIT* now, bugs be damned.

If you don't, your
4) *SHAREHOLDERS* get
5) *PISSED* and run and the
6) *COMPANY goes TITS*

The stock market plays a HUGE role in why things suck.

Re:Buggy code is sold because it is demanded (4, Informative)

drooling-dog (189103) | more than 7 years ago | (#15402412)

I'm surprised I had to read so far down to find this, the real reason. Stuff gets shipped because somebody needs to make their numbers, now. Sometimes the survival of the company is at stake, and sometimes it's just an individual climbing the career ladder.

In a previous life I was in charge of software development for a smallish company whose business was scientific software and systems. To my repeated horror, the CEO and the Sales & Marketing VP would get together and decree - perhaps for reasons that were very compelling to them - that major software packages would be released to customers with no testing whatsoever. Stuff went straight from the compiler to the customer, sometimes even without a cursory walkthrough of functionality. For objecting, we, the software people, were branded as troublemakers and criticized for not being "team players". Once labeled in that way, I would be pretty much ignored any time I had to report that a new product or an update was not ready to ship. Needless to say, I left that company in a hail of bullets.

To this day, I still laugh when I hear people say that Open Source software can never measure up to "commercial standards". Depends on whose commercial standards you're talking about...

The Reason: PHBs (4, Interesting)

koweja (922288) | more than 7 years ago | (#15402082)

99% of the time it's because upper managment either promised the customers features that could not be implemented or gave the programmers too little time and/or resources to finish the job. While not software development, I am having to deal with a similar problem right now. We are moving our website to a new CMS system. So we have to move all of the content from our old pages to the new system using a slow, buggy, web based system. In the beginning we were told by IT that we had until June 5 to complete the move, so we scheduled our time accordingly. Things progressed slowly but in time to meet the deadline. Then Tuesday morning we get a call from the assholes in PR that we have to have everything done by this Friday. We just had our remaining time cut in less than half. There is no way we can get done, so the site will be incomplete. PR gets no blame and we look bad.

Re:The Reason: PHBs (1)

fish_in_the_c (577259) | more than 7 years ago | (#15402476)

; Perhaps many of us would understand it stated better this way
; this piece of code was taken from the secret scripting ;language that is used to run manager training simulators

;WARNING: understanding this code may make you
; begin to understand management
; understanding management has been known to cause
; corruption to programmers minds and has been known to
; eventually cause promotion from programming to management
DOLOOP

IF(want to make $money$)
            write new software OR new features;

IF(time proposed to customer by manger LESSTHEN time to implement new feature)
{
Terminate ON(time proposed to customer by manger = current time)
                {
                                test and fix;
                                update design documents;
                                keep organized;
                  }
}

IF(time to implement new feature >= time to this point)
time to implement new feature = Reduce By Half (time to implement new feature)

time proposed to customer = time to implement new feature
END LOOP

ok... but what about? (0, Troll)

mseidl (828824) | more than 7 years ago | (#15402084)

Careless mistakes and security holes? What about MS taking 200+ days to patch a critical security hole? What about bugs/security holes due to bad management styles/lazy programming or a combination of the two?

Sure, bugs / security things will happen... but how many are too many? And when is an acceptable time frame to fix those, and fix those that pose major security risks?

In my experience, here's the reason (2, Insightful)

Weaselmancer (533834) | more than 7 years ago | (#15402085)

Managers.

Specifically, managers who don't know enough about the project (whatever it may be) and make unreasonable promises to their superiors about shipping dates. It seems that the way most businesses are set up reward managers who complete projects on time or early, rather than the quality of the product. As a result, managers tend to rush development teams through their tasks and the end result is a buggy release. And a manager with a bonus check.

If software shops could change their focus to creating a better release product but with a flexible time schedule...say for instance, rewarding managers for fewer bug reports and service calls rather than completion dates, you'd have an entirely different picture.

Re:In my experience, here's the reason (0)

Anonymous Coward | more than 7 years ago | (#15402436)

Parent poster must still be a peon.

I can illustrate exactly why those deadlines are imposed:

Client: We need this software to show at our conference on date X.
Sales: We can't deliver that.
Client: Ok, we'll go somewhere else. Oh, and that next $80 billion in purchases we were going to make from you? You can forget that as well.
Sales: Oh sorry, did I say we can't deliver that? I was just joking. We can.

At this point your sales/marketing/CRM people better be prepared to make the client understand that there will be bugs in a shipped product. As long as the sales/marketing/CRM people can do their job (and do it successfully) and the client understands the bug aspect, everyone's happy as long as the major feature sets are complete and delivered on-time. Bug fixing can happen after deployment but the client has to be made aware that bug fixing will happen post-launch.

You'd be surprised how many clients are satisfied with this approach.

Re:In my experience, here's the reason (0)

Anonymous Coward | more than 7 years ago | (#15402448)

1) make unreasonable promises to superiors about shipping date
2) rush development teams and ignor quality
3) get rewarded (bonus check) for completing projects on time or early
4) distribute buggy release
5) PROFIT!

VS.

1) creating a better release product with a flexible (longer) time schedule
2) distribute solid release
3) reward manager for fewer bug reports and service calls. (How do you reward fewer?)
4) NO PROFIT!

Re:In my experience, here's the reason (0)

Anonymous Coward | more than 7 years ago | (#15402483)

If software shops could change their focus to creating a better release product but with a flexible time schedule...say for instance, rewarding managers for fewer bug reports and service calls rather than completion dates, you'd have an entirely different picture.

Indeed you would. You'd have no customers since neither sales nor marketing would have no idea what to tell them. You'd lose ground to your competitors, but at least your developers wouldn't feel pressured to produce quickly.

Of course, they might feel pressured after they lose their jobs to an offshore competitor.

What a load of crap (-1, Troll)

rehashed (948690) | more than 7 years ago | (#15402107)

That is the biggest load of rubbish I have heared in my entire life. Software SHOULD NEVER BE SHIPPED WITH KNOWN BUGS. Sloppy development techniques, and over-ambitious per-release feature-lists are the only reason for extensive known buglists. From my perspective, hardware incompatibilities are the only reason to have a known buglist - but this should be related to hardware issues only - and not issues caused by the software itself. It is people like youself who give small, efficient development houses a bad name.

Re:What a load of crap (1)

nasch (598556) | more than 7 years ago | (#15402182)

So there's no possibility of a bug whose cost to fix is so high that it doesn't justify the benefit?

Re:What a load of crap (3, Interesting)

Mindwarp (15738) | more than 7 years ago | (#15402232)

How very black and white of you. So the large Investment Bank shouldn't ever put its new trading system in place, which has the potential to make them hundreds of millions of dollars, because of a couple of small, esoteric display bugs in the GUI?

The real world is all about risk/benefit analysis. The only places that ship guaranteed bug-free code are those where human life is directly affected by the output of that code. For anything other than trivially simple systems the cost/benefit analysis will rule out formal code proof in anything but the most necessary of circumstances.

Re:What a load of crap (1)

ch-chuck (9622) | more than 7 years ago | (#15402292)

Hahahah - you have obviously underestimated the irresistible power of the Quarterly Balance Sheet.

Re:What a load of crap (1)

BenjyD (316700) | more than 7 years ago | (#15402302)

All software ships with known bugs - if it doesn't, you are either not testing enough, or are only shipping tiny programs. At some point, commercial reality has to come into it and you weigh the cost of fixing the bug against its impact.

Nature of Competition (4, Insightful)

DuSTman31 (578936) | more than 7 years ago | (#15402116)

Regardless of the nature of the software development team, the nature of competition remains the same.

Stagnation is costly - delaying a product launch drives people to the alternatives (both due to the alternatives updating faster, and due to the lack of progress seen by the outside world).

Of course, buggy software is costly in terms of reputation, as well, so the end question becomes at what point will the delaying of the release cost us more market share then the remaining bugs will.

Unfortunate from a purists eyes, but it's just the way things go.

Umm... (0)

Anonymous Coward | more than 7 years ago | (#15402120)

His little 'graph the severity against the frequency', but 'never' make easy changes just because they are easy plan fails when it comes to typographical errors. They may not show often, and are certainly not severe, but they ARE extremely easy to fix, and have no further impact (ie: fixing a typo will never cause more bugs). But, according to his rules, he'll never fix a typo.

"It is better to ship a product with a known quality level than to ship a product full of surprises."

And it's BEST to get all the bug out first!

Software can be shipped without known bugs (1)

trelanexiph (605826) | more than 7 years ago | (#15402124)

There are products available, memprof [gnome.org] , Coverity [coverity.com] nessus [nessus.org] which can be used to find and fix common forms of previous bugs. These fix everything from repeating previous security flaws (I note a previously unknown DoS flaw I found in Asterisk's skinny codec ages ago which emulated a bug in cisco call manager exactly, which I found with Nessus), to bad programming, or programming mistakes (Coverity), to memory leaks (memprof). These types of bugs are unacceptable, there are tools out there to detect them DURING THE PRODUCT DEVELOPMENT CYCLE. I am not saying that you can fix every bug every time, but 5 digit numbers of open bug reports are unacceptable.

Re:Software can be shipped without known bugs (1)

tcopeland (32225) | more than 7 years ago | (#15402171)

> which can be used to find and fix common forms of previous bugs

And there are open source versions [sf.net] of those code analysis tools, too!

Re:Software can be shipped without known bugs (0)

Anonymous Coward | more than 7 years ago | (#15402464)

Yes, but do they support VB? *ducks*

A grossly oversimplified market explanation (1, Flamebait)

melquiades (314628) | more than 7 years ago | (#15402134)

Software will stop being buggy as soon as people stop putting up with it.

If people actually stopped buying Windows because it sucks, you can bet your sweet darned bippie Microsoft would stop making it suck. As it is, honestly, why should they care? People keep using Windows. It makes no business sense for them to focus on quality if quality doesn't sell.

<flamebait>There is already a company that caters to the niche market that actually gives a rat's ass about consumer software quality. It's Apple -- and oh, look at how they just dominate the desktop computer market....</flamebait>

Re:A grossly oversimplified market explanation (0)

Anonymous Coward | more than 7 years ago | (#15402471)

Funny, that, I just bought my first apple laptop...

bugs, so what? (2, Insightful)

ComSon0 (473373) | more than 7 years ago | (#15402136)

We buy buggy cars, houses, and anything else you can think. Nothing with the aim of perfection *ever* gets done.
So what's the big deal?
I understand shipping something like bad tires that will eventually kill people should not be done, but anything that does not cause harm or major finantial distress should just be dealt with during the normal lifetime of a product.
I am an embedded systems developer. We take care of the functionality problems before shipping and work on the corner cases as we move along.
There is no way a group of people, doesn't matter how large, can think on every possible problem that can occur.

Show me one thing that's man made and that's perfect and I will eat my shoes.

-later!

Re:bugs, so what? (4, Interesting)

tbone1 (309237) | more than 7 years ago | (#15402248)

I work for a company that does medical publishing. Our data is used by many medical professionals in highly-stressful, quick-paced environments. If we mess something up, it can kill people.

And if our IT staff had the same intelligence, competence, and vision as our management team, we'd kill over 10,000 people a week.

Re:bugs, so what? (1)

mypalmike (454265) | more than 7 years ago | (#15402385)

Our data is used by many medical professionals in highly-stressful, quick-paced environments. If we mess something up, it can kill people.

Are you saying there aren't any mistakes in the data you publish?

Re:bugs, so what? (1)

magicjava (952331) | more than 7 years ago | (#15402357)

Show me one thing that's man made and that's perfect and I will eat my shoes.

http://starfcker.typepad.com/photos/stars_ive_spot ted/pamanderson.jpg [typepad.com]

Re:bugs, so what? (1)

magicjava (952331) | more than 7 years ago | (#15402418)

Althought, truth be told, that's two things.

How does that shoe taste?

Re:bugs, so what? (1)

Al Dimond (792444) | more than 7 years ago | (#15402475)

Um, that's not perfect, that's grossly out of proportion -- and tacky to boot!

The author of the article... (1)

tcopeland (32225) | more than 7 years ago | (#15402142)

...Eric Sink, has a interesting piece on his blog about open sourcing Java [ericsink.com] . He says he's a C# programmer now, so kind of a different perspective...

Why Buggy Software Gets Shipped (1)

goldaryn (834427) | more than 7 years ago | (#15402152)

Why Buggy Software Gets Shipped

Easy. Because it's nearly impossible to get software bug free. Add time constraints and pressure from above... Even when software is close to bug free, people always want enhancements, new bugs are introduced..

The best Linux distros test their releases to death, and still require and release regular bug fixes. And that's the difference, really, not to get into the OSS/closed source debate, but it's all down to how you deal with the fact that software is buggy.

I don't care about quirks/annoyances. (1)

artifex2004 (766107) | more than 7 years ago | (#15402160)

I do care about bugs that crash the program, and I really care about those that cause data loss.
If you knowingly ship code that causes data loss, you are morally responsible for that loss, especially if you don't warn anyone about it.

Disabling that dysfunctionality is always preferable to destroying customers' work.

Real reason (5, Insightful)

gowen (141411) | more than 7 years ago | (#15402163)

Because, by and large, no one gets killed when commercial software crashes.

In those cases where it does; e.g. medical/aviation software, usually embedded people take the time. If aviation software designers cut the same corners (w.r.t. bugs vs. features) that office software designers do, planes would fall out of the air and people would die. So they write well engineered software, in well engineered, fault tolerant languages (lika Ada). (Yes, yes, Ariane, but thats the exception that proves the rule)

The real reason buggy software is shipped, is because buggy software is accepted by the market, and people will keep buying it, and continue to roll their eyes when it crashes, because they're completely inured to it, and many of them have reached the conclusion that its literally impossible to write robust, stable software.

It's not, but the profit margins are narrow, and no-one seems to mind (or rather they mind, but keep forking over their money anyway). So no-one bothers to.

Face if folks, we're enablers.

It's the three M's (1, Interesting)

FidelCatsro (861135) | more than 7 years ago | (#15402179)

Marketing , Management and Money

Nice excuse, but not good enough (1, Insightful)

Anonymous Coward | more than 7 years ago | (#15402181)

I agree that for a non-mission critical type of software, bugs are acceptable. As long as there are workarounds (e.g. avoid doing things that cause the bug to occur), it would be ok.

However, for mission critical software such as medical devices that deals with raditions output or heck even slot machines, bugs are unacceptable.

A good example is the Therac 25 where due to bugs, it actually injured people. http://www.ganssle.com/articles/disaster.htm [ganssle.com]

I hope the poster of this article or anyone who is in group 1 will never work on any mission critical software.

TFA (1)

LCookie (685814) | more than 7 years ago | (#15402184)

Read the article... Just a list of poor excuses from a bad developer.

Re:TFA (1)

LCookie (685814) | more than 7 years ago | (#15402310)

Yeah, right.. Modded -1 by a bunch of equally incompetent people. So go and live with your botnets, spam, worms, viruses. You know, that's what you get from buggy software in case you didn't know!

Articles like these make me sad.. (1)

wfberg (24378) | more than 7 years ago | (#15402201)

Articles like these make me sad that slashdot doesn't allow the posting of images in replies. Had this been on fark.com, this thread would be full of Ric Romero [go.com] images.

Luckily Ric's wikipedia article suggests a textual equivalent..

"Determining which bugs to fix should take into account some manner of cost-benefit analysis?! Thank you, Captain Obvious!"

I test industrial software. I watch it ship buggy (1, Interesting)

Anonymous Coward | more than 7 years ago | (#15402205)

It is in the best short term business interests of the people making the decision to ship software with some bugs NOW rather than ship perfect software later or never.
You're going to announce that you plan to ship xyz new feature on some date well before that date occurs.
In this business, you make the announcement for the same reason as in any other business. You don't want your customers to choose an alternative that precludes the necessity of buying from you.

These schedules are always aggressive. They typically assume no bugs passage release test on the first try.
Managers who develop these schedules are not stupid. They just have to respond to business as well as engineering requirements.

Development and debugging are always behind schedule because this is not realistic.

So, you string the Customer (one company or "the market"; doesn't matter) along with promises and betas, but eventually, they demand the product. Pressure is high and the Customer says give us what you got. (And well scream bloody murder if it's not right, and we know it's not right, and it's your fault, now, give us the f---ing software now!)

And you ship, because once you've gotten to this point, to ship is a better business decision.

QED

PS
You bet your ass I'm posting this AC.

Five digit bugs are wrong for what reason...? (1)

creimer (824291) | more than 7 years ago | (#15402207)

When I was a lead tester at Atari, there was 3,000+ bugs for Backyard Baseball GCN and less than a dozen open minor bugs when the game shipped. Some people considered 3,000+ bugs to be a high number for a GameCube title. For me, that's being thorough. (Which we had too since the programmers loved inserting phallic imagery into a kids game.) I'm looking forward to seeing how Backyard Baseball 2007 GCN stacks up when it's released next month. My assistant lead tester and I (we both no longer work for Atari) are planning to tear it apart. I just hope I don't have to submit a report to change the ESRB rating for any inserted phallic imagery. From some of the screenshots I've seen so far, we may very well find something.

Group 1, not in my industry.. (1)

s31523 (926314) | more than 7 years ago | (#15402210)

Whats really frustrating is getting people from Group 1 that know why buggy software is delivered to customers, but start to accept this as normal practice. This especially hurts in the aerospace industry when we get crossover managers and software developers from Group 1 that can't understand why we don't release buggy software intentionally and spend a lot of time dealing with their crappy code or improper schedules because they think software verification is a luxury item that is unnecessary.

Known undisclosed broken features (1)

192939495969798999 (58312) | more than 7 years ago | (#15402213)

I would prefer to at least know the things "you" (microsoft, etc. whoever) know that are definitely broken features of the product. I'd like to see "You can't do this, but here's the workaround" and put that info in some kinda place. Programs used to come with user manuals that told exactly how to do things. Now they pretty much don't come with that stuff, which means I should be able to do anything? Nope, some stuff won't work, but no one told me the Proper(tm) way to do it, so I have to go spend another hr on the internet looking it up. That's broken as hell! Just tell me how to do it the first time.

Also, the scope of the bugs that exist is super-wide now. There were always some kinda errors in a program that are weird, but main features being broken (especially becoming broken by other installs from same company) is just not acceptable. Sure, a "buffer overflow that is really complex to implement" probably matters to me, but way less than seeing "windows media cant find codec" on a WMV video I need to watch for class in a school lab, on a PC that I can't install anything on.

Why is this "commercial" software specific? (0)

Anonymous Coward | more than 7 years ago | (#15402228)

I see all the usual flippant comments from the /. banana gallery about M$, but what does buggy software have to do with "commercial" software? All software has bugs, closed source commercial to open source free. While it's popular to only hold up specific examples like IE vs Moz/FF or Linux/GNU vs Windoze, fact is that I have not personally witnessed any better quality coming out of FOSS side vs the commercial side. Like with anything else, several factors play into why software has bugs, most of them focus on the abilities of the developers themselves (give me good developers on a tight schedule vs average/crappy developers with all the time in the world).

because we want it NOW! (4, Insightful)

LWATCDR (28044) | more than 7 years ago | (#15402247)

Look at Vista. Everyone is complaining about it not shipping on time. I have yet to hear anyone say. It is a good thing that Microsoft is fixing all those bugs.
Product ships late because of bug fixes. Why is it taking so long.
Product ships on time with bugs. Why didn't you fix the bugs before shipping.
You just can't win

It's Business (0)

Anonymous Coward | more than 7 years ago | (#15402255)

while ( ( your_budget ) > ( Estimated_liklihood_of_this_bug_being_a_problem_to _users ) * ( The_foreseen_cost_of_recovering_from_this_bug_if_i t_were_to_be_a_problem ) {
      fix_bugs();
}
ship_product();
     

Profitability Uber Alles ... (1)

Infernal Device (865066) | more than 7 years ago | (#15402276)

The very fact that this discussion arises at all tells me that profitability is of more concern than quality in the commercial software world.

In the Free Software/Open Source world, that excuse doesn't exist, so what is it? Laziness? Hubris? Apathy?

Re:Profitability Uber Alles ... (1)

BenjyD (316700) | more than 7 years ago | (#15402360)

Lack of time for bug-fixing and the virtual impossibility of proving any reasonable size piece of code 'correct'.

Erveytnhig Hmuans Do Has Bgus (1)

magicjava (952331) | more than 7 years ago | (#15402303)

Erveytnhig hmuans do has bgus. Soemohw we mnagae to get aolng.

no comment but ... (0)

Anonymous Coward | more than 7 years ago | (#15402316)

it just shows that being a programmer nowadays is just
another job you can do. write software, earn money.
no more moral grounds, or bonding with the software or
the resposibility of the "thoughts of a computer". very sad.
just throw together some "software" (my god!! "builds on
sql server") and sell to some idiots.

just wondering when this economical bug will hit the
manufacturing industries. i think some wittier slashdoter
can come up with horrendous outcomes with this "never mind
we sell products with bug" mentality in the food,
pharmaceutical or machine industry ...
"yeah, we KNOW our sausages; we dont eat them"
"yeah we build that airplane; but we do fly in them"

If at first.... (1)

Malor (3658) | more than 7 years ago | (#15402332)

If at first you don't succeed, redefine success.

My experience (4, Insightful)

bbroerman (715822) | more than 7 years ago | (#15402397)

I work for a large software shop. In my experience it boils down to:

  1. Accellerated schedules created by management / client without development buy-in.
  2. Management cutting development phases in order to get things done faster to meet dates from #1. (i.e. design reviews, code reviews, phases of testing, etc)
  3. Shipping portions of the development off to India teams (in order to save money) who are under trained, and can't speak the same language as the other developers, and who won't ask questions when they don't understand.
  4. Giving development / design tasks to people with no experience in the subsystem that they are being assigned to, because management believes that one developer is as good as any other... we're just bodies...
  5. Churn in employees... Better / more experienced people leaving for better jobs, and noobs coming in to replace them. After a while, you have too many noobs, and not enough older, more experienced folks.
  6. Colleges not training people on common coding errors, proper design principles, good design patterns, proper testing and documentation strategies, etc.
  7. The old addage: Too many cooks spoil the broth. Some times, there are too many senior developers, architects, etc. workign on a design, an they all have their favorite ways of doing things. Many times, even within a single subsystem, one senior person will move to a new project and a new one will come in, and want to change the process / design to fit his style... and usually at the last minute...

Now, as to why bugs don't get quashed quickly:

  1. Lack of enough informatin from the person experiencing the problem to allow development to recreate the problem.
  2. High complexity of the systems involved.
  3. Bad library design / separation of concerns / encapsulation, etc. means that a small bug in some unrelated libarary can cause problems where you never expected them.
  4. Developers who aren't experienced enough with the code / subsystem to be able to find said small bugs. (i.e. see number 4 and 5 from last list).
  5. Developers who aren't given training and experience in the proper use of debuggers, memory checkers, etc. (how many college hires out there really know how to use dbx to track down a bad pointer in the free list?)
  6. Too small a staff, too much to do.

I see each of these every day!

The real cause (1)

diodeus (96408) | more than 7 years ago | (#15402421)

Quarterly sales figures and bonuses based on projections that must be met.

Further Reading (1)

yeah81 (884178) | more than 7 years ago | (#15402423)

If anyone is more interested in this subject, Mark Minasi wrote a good book on the subject called "The Software Conspiracy".

all of the above. (1)

frankencat (946892) | more than 7 years ago | (#15402427)

eom.

Because they can (1)

nuggz (69912) | more than 7 years ago | (#15402433)

People do stuff because they can do that stuff.
Ideally they do it because the trade offs are acceptable.

In software there is some that is very buggy, some that is nearly bug free. This is mostly driven by what the customer is willing to tolerate.

I don't think this is what he meant but... (1)

Java Pimp (98454) | more than 7 years ago | (#15402447)

It is better to ship a product with a known quality level than to ship a product full of surprises.

So, if all the known bugs were fixed, then the product would ship but be full of surprises (since we assume it has bugs we don't know about).

But if you don't fix the known bugs... the product would ship full of bugs and surprises?

hmmm...

Real Reason: Bad Design Leads To Unfixed Bugs (1)

aldheorte (162967) | more than 7 years ago | (#15402450)

Although Mr. Sink makes good points about the need to ship products with a certain level of minor bugs and do a constant analysis of priorities to continually improve a product, which may lead some minor bugs always open, original architecture design has a big impact on the ability to fix bugs.

For example, Mr. Sink's two bugs that he cited show two things:

1. Improper design of the business logic to database connection by locking themselves into a closed-source, expensive, proprietary database system and using proprietary extensions offered by such.
2. Developing and testing for only one platform.

If originally they had designed their architecture to not rely so heavily on internal mechanisms of SQL Server and kept in mind that they might want to make a change at some point, the evaluation of whether to fix the first bug he cited would be quite different. If they had spent just a little time upfront thinking and testing cross-platform development design, the line endings bug would be a non-issue and overall code quality would probably improve.

Therefore, his analysis of bug prioritization makes sense once you get to the shipping stage. However, it is not an excuse for shoddy design, which causes some bugs to not be fixed because of the high level of cost and risk it would now take because of that poor design. An indication of the overall quality of a codebase is how easily bugs can be fixed. Given enough time, the market (in non-monopolistic product niches) will sort out those that can fix their bugs because of good design from those who cannot.

The problem's not that there's always bugs... (1)

Svartalf (2997) | more than 7 years ago | (#15402462)

It's that so many companies ship with flaws that would be unacceptable anywhere else.

Would you ship a doorknob for an outside door that could have the lock so easily breached that it's as simple a matter as inserting a slot screwdriver into the keyhole and turning?

That's what gets shipped by many companies- those sorts of flaws.

And it's the mentality of the first group (The "there's always going to be bugs" crowd he's talking about..) that causes the stuff to ship that way. Sure, there's going to always be some issues somewhere in a complex system- but the goal is to do your level best to reduce those to as close to zero issues present as you possibly can, dealing with problems in the order of their severity.

How about Group 3? (3, Interesting)

dpbsmith (263124) | more than 7 years ago | (#15402468)

Group 3 consists of people who acknowledge that fixing all bugs is impossible, and that judgement is necessary in deciding which bugs need to be fixed... but nevertheless contend that within the personal computer software culture in the United States, these judgements consistently err in the direction of shipping software with too many bugs.

The personal computer software culture in the United States is much like that of automakers in the United States circa the sixties, who insisted that the low quality of U. S. autos was the result of the best and wisest judgement... and that public toleration of low quality, as reflected in good sales and profits, validated their judgement.

Good sales and high profits, that is, until overseas competitors began to ship high-quality cars to the U. S.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?