The Economics of Perfect Software 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."
How is this news? (Score:5, Insightful)
Re:How is this news? (Score:4, Interesting)
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? (Score:5, Funny)
Re: (Score:2)
But how do you know before it's time to ship?
Re: (Score:2)
Use tools like FindBugs [sourceforge.net] to root out as much as you can.
Then you have at least shoveled away the bulk of stupid bugs that causes resource leaks and other things that makes a system go obnoxious after a while.
Design bugs are a different kind of animal and those are harder to figure out since they aren't detected by the normal tools.
Re:How is this news? (Score:5, Insightful)
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: (Score:2)
Who cares about the UI giving an attacker root. As far as I am concerned it is a *minor* problem. I don't pay the cost, why should I care?
For those of you who are a bit slow, I don't mean this. It just serves to illustrate a point.
Re: (Score:2)
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.
"You talkin' to me?" - Gates and/or Ballmer, or perhaps their legions of minions.
triaging incompetence (Score:2)
One of the best things I've read on this subject was an interview with top level muck muck at NASA (I think it was _the_ guy) when NASA was bent on fixing their safety culture, following a little bug that cascaded into millions of small pieces. In a safety audit they found a small number of broken wires in some electrical harnesses that weren't supposed to have this defect in this quantity. The engineers did what I might term a sensitivity analysis and determined that with all the other layers of redundan
Re: (Score:3, Interesting)
The economic angle is a dangerous meme, because it lets incompetent management off the hook by allowing them to triage incompetence, and in particular, to ignore process failures, and the failure of team culture, both of which point back to management itself. We all know how well that worked out for NASA. This wasn't fixed until lives were lost.
If you're writing code for NASA, or say the medical industry, I'd agree. But 99.9% of the developers out their are writing code that nobody is ever going to die bec
Re: (Score:2)
I agree. I was going to reply in the same manner, but probably not as good as yours, thanks.
That's the problem with bugs. The small UI bug may be caused by underlining wrong state of the program, which may also cause crash or loss of data. So unless you know almost exactly the cause of the bug, you really don't know how serious it is (especially true for mysterious bugs - if a message overflows a message box, then you probably know the problem). If you know, on the other hand, it may be economical not to fi
Re: (Score:2)
It's funny you say that because a lot of the time it's little glitches in IE that end up giving a user remote root.
IE is a full program, not a UI. A simple UI would be a form on an HTML page that uses some javascript. (I have heard of morons that use Javascript as a security mechanism. That's the kind of thing I'm talking about.
Jpeg, mp3, and zip have proven to be capable carriers of exploits precisely because of the issue that either the official support code or a common library contained an exploit;
Yes
Re: (Score:2)
Re: (Score:2)
"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%."
Maybe it's because it comes from so way back you can't remember properly but it doesn't go that way.
It goes "it takes 80% of the time to do the first 80% of the code, and 80% of the time to do the remaining 20%". There, fixed for you.
Re:How is this news? (Score:5, Interesting)
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.
Diminishing returns for who? (Score:2)
Sure, there are diminishing returns from the corporate payroll/sales perspective, but even tiny bugs tap manpower out of your customers, and as such, put a drain on the economy.
Hours of my time every week are spent working around bugs that the OP would probably have considered too minor to be worth fixing. It's all nickel and dime stuff -- five or ten minutes here or there, sometimes even just seconds, but many times a day. We'd use less buggy software, but it doesn't exist. Sometimes we fix the bugs and
How do you know which is which, though? (Score:2)
My question, though, would be how do you know which is which?
And before I even start, a thing I learned pretty early is that if you aim low, you'll hit even lower. If you aim for a B or C in school, 'cause, well, no point in fretting over not being exactly perfect, you start getting D's and lower. I should know, I actually tried that philosophy for half a year or so, before realizing that lesson. Partially because life doesn't throw you exactly the curve you were expecting, and partially because once you st
Re: (Score:2)
How do you know? Experience. Experience reading through the code, and experience in software debugging.
How do you know absolutely positively without a doubt? You don't, and you never will. All understanding and knowledge is a model of reality, and models are sometimes wrong. This idea people in this discussion seem to have that you can eventually, with just a little more effort make the system "perfect" is severely flawed. The disconnect the pragmatists in this discussion have with the perfectionists
Re:How is this news? (Score:4, Insightful)
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: (Score:2)
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.
Ahh, reinventing the fart... (Score:2)
Ahh, the joys of the Dunning-Kruger effect [wikipedia.org]: being too unqualified to realize one is unqualified.
The author of that blog post basically reinvented Stress testing [wikipedia.org] (yes, software which can replay input sequences and even variations thereof,
Lets look at it another way (Score:3, Insightful)
You cant afford perfect software.
Re: (Score:2, Informative)
Unless you are NASA:
http://www.fastcompany.com/magazine/06/writestuff.html [fastcompany.com]
Re:Lets look at it another way (Score:5, Interesting)
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.
Oh Please (Score:5, Insightful)
* 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
Re:Oh Please (Score:5, Insightful)
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 (Score:5, Insightful)
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: (Score:2)
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
Re: (Score:2)
It was just supposed to "look good" to go with the story, but I guess having a bug was just as good :-)
Re: (Score:3, Insightful)
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
Re: (Score:2)
This list also exists for aviation (and I'm sure other life critical) software. In the case of aviation software, it gets submitted to the FAA (or whoever your regulatory agency is, along with an analysis of each bug and why it is OK not to fix it.
Re: (Score:2)
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 (Score:5, Insightful)
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: (Score:3, Insightful)
That's one factor; but another larger factor is that there are often several orders of magnitude more users of your software than there are testers. Even if the testers were able to come up with all the "utterly creative stupidity" as the users, there wouldn't be enough hours in the day for them to test all those cases.
Re: (Score:2)
We'd do it if we could ... and someday we will.
Really? How? I'm genuinely curious.
No bugs isn't a perfect product. (Score:5, Insightful)
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: (Score:2)
If Windows was truly perfect, then we could consider "Operating Systems" to be a solved problem. We wouldn't need a fifty billion dollar software company any more, we'd just need someone to print bits on a polycarbonate cylinder and/or transmit them over glass tubes.
Re: (Score:3, Funny)
I'm breeding cockroaches to write code. How ironic: bugs will solve bugs.
Re: (Score:3, Interesting)
The other thing that might be a possibility... is that software needs to have bugs from the business end to ensure lucrative service contracts.
Now this is just pure speculation of course... but I used to a work for networking vendor known for superior customer support... and making mega bugs in the servicing contracts as well.
I sat there looking at some ridiculous policies in the software realm that almost seemed to encourage bugs in the code as opposed to writing good software.
They were throwing code arou
Re: (Score:2)
I would add, "* perfection can't be achieved within today's software lifecycle's".
Maybe at some point in the future, the software lifecycle will be longer. A particularly mature piece of software might be considered "done" from the standpoint of features. Then, its lifecycle is indefinite. You might consider analog signal decoding as a very simple program with a feature set that is "done". In the early days of FM radio there was debate about the best circuit for decoding a signal, then they settled on a p
Re: (Score:2)
* 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: (Score:3, Insightful)
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: (Score:3, Insightful)
Re: (Score:2)
Ah, but they will pass through the infinite number of bugs stage and onto perfection. Eventually. Maybe even before the sun burns out, although I wouldn't bet on it.
Well, sure, if you have precognition (Score:5, Insightful)
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: (Score:2)
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: (Score:2)
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 mo
Re: (Score:2)
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."
That's not the bug. That's a symptom of the bug. The bug itself will be something like a race condition, or a temporary variable that is not deleted after use. If it's triggered by sequence A,B, C-- and you don't actually what the bug is-- then why do you think know what else will trigger the bug?
...It's not a difficult process to figure out how much a bug affects your user
Sure... if you can predict everything that your users are ever going to do with your software, now and in the future.
probably good idea; definitely bad example (Score:4, Insightful)
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: (Score:2)
And others like disabling WMP's stranglehold on my MP3 player requires a somewhat obscure incantation involving deregistering a dll file
Re:probably good idea; definitely bad example (Score:5, Funny)
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: (Score:2)
Re:probably good idea; definitely bad example (Score:5, Funny)
then you replied:
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: (Score:2)
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: (Score:2)
Maybe because you believe in the Unix way of small programs to do a single thing well?
Dangerous approach (Score:5, Insightful)
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.
Maybe. (Score:4, Insightful)
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: (Score:2)
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.
I'm not sure I buy the argument (Score:3, Insightful)
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: (Score:2)
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.
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. Howev
If they need it, and it's buggy, it's annoying (Score:4, Insightful)
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: (Score:2)
Re: (Score:3, Insightful)
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: (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
My example was based on the assumption that the error was somehow critical (as in, software/car refused to function due to the malfunction) and in that case any user who wanted to use the feature would've been pretty annoyed ("WHAT DO YOU MEAN I CAN'T USE THE RADIO WHILE THE ENGINE IS ON?! IT CAME WITH THE CAR! IT SHOULD WORK! WHAT'S THE POINT OF A CAR RADIO THAT ONLY WORKS WHEN THE ENGINE IS OFF?!").
Re: (Score:2)
without actually breaking any functionality
Re: (Score:2)
Which was clearly not the premise of the post by Tsu Dho Nimh that you replied to.
Talking about bugs that don't cause any problems wouldn't make any sense.
The core argument does make sense. (Score:3, Informative)
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.
sometimes crash == possible exploit (Score:5, Insightful)
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.
Duh. (Score:2)
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.
That's a symptom, not a bug. (Score:2)
> 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.
Re: (Score:2)
From the description I don't know that the bug is in the UI.
mediocrity (Score:5, Insightful)
s/nation/project/
Economics of Perfect (Gaming) Software (Score:2)
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
Re: (Score:2)
It should have gone without saying that I meant "the perfect game within a particular narrow genre", like 4X games for instance. There would be more than one perfect game in total, if such things actually existed. Endless replayability with well randomized maps/scenarios would be one of the most important criteria for the perfect game.
Doesn't sound like a little bug... (Score:2)
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..." (Score:2)
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 (Score:2)
Obscure bugs can be fatal ones. (Score:5, Informative)
Re: (Score:2)
Exactly. What, BTW is a "minor bug"? How do we decide this if we haven't experience it? If no one has seen it yet, how do we judge?
Also, the Ford Motor Company in the early 70's made an informed, rational and very wrong economic decision to produce the Pinto despite knowing it could be dangerous. They measured things out and decided the danger was worth it in terms of profitability.
This argument is just an excuse for not caring.
My TV Remote has bugs... (Score:2, Interesting)
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 s
Release when? (Score:2)
Perfect software is like a perfect person: hard to find. Even if you did find it, then it probably wouldn't be doing things in the way you want it to.
If I am asked to add a set a features and make it perfect, then I will do the best job I can, but in the end the question to be asked is "do you want perfect software or a deliverable?". Perfect software is also like a derivative, in that you can always get closer to your integer the more you work at it, but still not be there, it simply tends to infinity.
Crappy excuse alert! (Score:2)
If you don't have pride in your work, quit. Making excuses for bugs has no excuse. It guarantees you will ship bad software. There is a ratcheting effect. At first you accept some defects, then you accept more, etc.
And if I was that user I would be angry. I just wasted all that time navigating through all of those menus (also a sign of bad software, too many levels) for no good reason. You just pushed off your lack of caring on to me. I would look for better software. Something which costs me less $$$$ in l
Until your users figure out the game (Score:2)
The little bugs add up, and users consider your software and even computers in general to be very unreliable these days. The PC has such a bad reputation that users just openly mock it all the time. It's expected to suck. Microsoft software especially is expected to have bugs. The whole platform is just a big bugfest, a race to the bottom in quality.
Part of why Apple has been making hay over the past decade is that their software is just more reliable than what people have come to expect. They spent years p
craftsmanship in code (Score:2)
When I first started programming they liked to compare programming to building a house. I had to point out that its not like building a house. With programming you can start from the top and go down and you can start at the bottom and go up and you can start at the east, west, north and south too. You can build the parts in any order.
However there is an aspect of programming which is akin to house building and this is the idea of the framing carpenters and the finishing carpenters.
Who here wants to use a
craftsmanship in code part 2 (damn varnish error) (Score:2)
It is much cheaper to write software to do the job right the first time. This makes later debugging much easier to do because the rest of the system can be trusted.
So here is a story on one of my programmers. The company was under tight deadlines. That was their own damn fault because the previous 6 consultants couldn't figure out how to write a single line of code on their watch. Of course they didn't tell us when they hired us! Go figure?
I told my project team: Check every error code - without excep
Support Contracts (Score:2)
The same economics as being a unicorn rancher (Score:2)
After all, they're both mythical beasts.
I had "one of these" years ago (Score:2)
I had a software package to which I was adding features and there was one nagging, subtle bug that kept me chasing my tail for a couple of weeks.
I was fairly junior in my career, so you can imagine how I felt when the VP of Software Development called me in for a chat. He impressed on me how it's really not practical to hold up a product shipment for some "little bug". There will always be "little bugs", and I needed to get over it and move along.
I accepted this sage advice (and counted myself lucky that
Re: (Score:3, Funny)
{
printf("Hello, world");
return 0;
}
I demand your first born.
Re:Wrong name (Score:5, Funny)
You didn't include stdio.h and you probably wanted a \n at the end of your output string.
First born denied.
Re:Wrong name (Score:5, Funny)
Re: (Score:2)
$cat hw.c
int main() {
printf("Hello, world");
return 0;
}
THEEND
You sure about that? (Score:2)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
No, it won't necessarily do what you expect.
With printf undeclared, it's assumed to be a function that takes an int argument, and returns int. It just happens to work on your machine, but on a 64 bit box it would likely crash, because on AMD64 int is still 32 bits, but a char* is 64 bit.
I've just finished debugging precisely this problem in a piece of software over the weekend, btw.
Re: (Score:2)
Re: (Score:2, Insightful)
Programs run just fine, or so some hope, with compiler warnings. Despite that, parent says his shop considers them to be bugs.
Oh to work in such a shop, where I don't have to sift through 74 warnings every build because someone decides that catch (Exception e) is fine even if you never take so much as a passing glance at what got put into variable e. Hey, dev manager, how about you just turn the fsckin' things off if no one cares?