Slashdot Mirror
The Economics of Perfect Software
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."
Diminishing returns applies to programming too... big surprise...
You cant afford perfect software.
Fix them all, you basterds!
The reason that every piece of software ships with bugs is because:
... and someday we will.
* 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
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.
http://www.geoffreylandis.com
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...
Sums it up nicely
Thank you, think you very much
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.
it's a feature... There's your fix :)
The Economics of Prefect Software.
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.
You see? You see? Your stupid minds! Stupid! Stupid!
It should have been Perfect Software-Econonmy or something like that. The Perfect Software(tm) has zero bugs, and if such a program ever happens, its cost will be very high.
In soviet russia the government regulates the companies.
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.
They are not bugs.
They are DEFECTS.
Pure and simple.
That little example of the 'trivial' bug, if it is the feature, integration, function, exporter, importer, etc.. without which the user cannot work. If it is the feature for which they actually bought the product. And they have now wasted their time and money buying, installing, partially configuring the tool. And now, due to the incompetence of the developers they cannot continue. Then they Will think you are a Jerk, and that -all- developers are jerks. And they are right. I've worked at a 6-sigma organisation, it's not actually very hard to write bug-free code, you just have to care.
once again. They are NOT BUGS. They are DEFECTS caused by lacklusture workmanship.
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.
I agree with what you are saying, but will the economic v. code perfection decision always be clear cut? Could lead to a slippery slope...
There are programming methods that aim to decrease the amount of bugs substantially with functional testing and unit testing. Unfortunately these tests don't make software 100% bug-free but it they do reveal 'big bugs'.
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.
.: Max Romantschuk
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.
Did anyone misread the title as "The Economics of the Perfect Square"?
Creating a 100% perfect product is just a terrible idea for business.
Of course, in software, creating a perfect product is hardly an achievable thing to do, especially if you are actively working on it.
Whether it is adding new features, releasing optimizations for functionality X, or just some bug fixes, you shouldn't really ever be able to create anything "perfect".
If you somehow managed to create something perfect, then you already never had much scope for the product in question.
I use a simple example, PowerMenu for Windows adds 4 new menu items on all windows context menus to change priority and transparency, set it Always On Top or Minimize to the system tray.
It was built with Windows XP and below in mind. It worked and it worked well. You can't really do much else with it. (well personally i think it would be nice to have had the ability to minimize to the powermenu tray icon rather than clog up the system tray)
Okay, my example wasn't good, sue me.
But you get the idea... right..?
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.
AccountKiller
Did Toyota Sponsor this article? Really, it's a *little* bug, we should just let it go....
1. If you're aware of a bug, stop and fix it.
2. If you cannot fix a bug quickly, you've got a design problem. Stop and fix it.
3. If you have so many bugs that you need a tool to track them, you've got a management problem. Stop and fix it.
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’
Can you be Even More Awesome?!
I might misunderstand the actual message, but still, I see a small benefit for leaving minor bugs around:
Imagine a long-running project (just like cobol+finances). Several core programmers go away, and you have a big heap of code that no one can maintain, therefore you will need to rewrite all your software "as soon as possible" and spend huge amount of money on migration.
If you leave a tiny annoying thingy there, it will inevitably attract hackers that:
a] formulate the real nature of a bug (gaining insight on how it really works)
b] eventually hack through all the code and apply the oneliner (slowly becoming experts on the topic. Happens only if source is available to users/admins)
In short, 'annoying non-critical bugs produce maintainers'.
(well, maybe I am a development lunatic)
> 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.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
"Once genius is submerged by bureaucracy, a nation is doomed to mediocrity. " -Richard Nixon
s/nation/project/
Programmers view my approach to programming a bit weird. But so do I, they always claim bugs aren't a problem, its ingrained in the way you do things.
You can do things a LOT better. For starters stop making the same mistake many times.
And for gods sake don't always ask as much code as one possibly can do in any amount of time its inanely stupid. If the code is worth to you 20,000$ the be prepared to pay 20,000$ for it. It don't get better because you may sometimes get it cheaper if you luck out. Because in the end this always bites your ass.
if the simple and easy stuff is broken (the stuff that can be automatically checked),then bigger bugs lurk below. Article is dumb, assumes the dummy programmer can know the difference.
I'd bet that the majority of CEO's know that most software is released with bugs (the others are not in the software business :). Any product manager worth his salt will be able to manage priorities correctly. So the entire argument is built on false assumptions. Sure, there are bad managers who will get priorities horribly wrong, but even they probably know that not all bugs can be squashed. To present this as if it's something new and revolutionary is silly.
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.
I know, that's too much to ask of modern code monkeys. How many of you who "good enough" quality have ever even read a book on "Software Engineering?" Have you even HEARD of the original NATO conference on that subject? How many have studied interesting "Software Physics." Yes, all code I write has bugs, because I am not omniscient. There are inputs and environments I never imagined the program having to cope with. But about half the code I write has two things rarely seen in code today: 1. Comments in the form of Assertions (e.g. "At this point, input XYZ is confirmed to be in the range 87...92". 2. About half the lines of actual code (absent comments) are validation of input conditions from the world (user and environment) outside the program itself. Perfection is not actually achievable, but IT'S THE ONLY TARGET WORTH PURSUING. Companies like Microsoft don't even try, because they're not in the software business; they're in the money-making business. Professionals care; money-grubbers aren't.
Leave in "little" flaws to save a buck. Well we all know what happened there.
For justice, we must go to Don Corleone
Yeah, in my own mind I inserted that extra word in the title, and I was disappointed that it wasn't about that at all. I'd like to see an article about that, describing how the "perfect" game would be an economic Bad Idea, and including interviews with game developers who finally admit that they deliberately repeat old shortcomings and mistakes and stop short of perfection, knowing that the perfect game would completely destroy the market for next year's game. I can think of one or two that actually tried to damn the torpedoes and thwart this dynamic, but ultimately they got shut down by the suits holding the purse strings.
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.
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?
I used to work for a small computer firm in Weybridge, England. Oh, damn it, since it collapsed ten years ago, I may as well name it: MTA (Computer Consultants) Ltd. We had a project between 1997-9 to write a software demonstrator for a radar resource manager for the Eurofighter project, for DERA Malvern. The project was divided into two parts, of which phase 1 went through a successful factory acceptance task. However, a few bugs had been found in the programme after this, one of them, due to me, was fairly serious. It was a small mathematical error but I produced a bug in a few mninutes.
Now MTA had gone through a turbulent time, having to sack all of its staff because of the lack of money and the rehiring them. MTA were annoyed that DERA decided to stall the programme while it did a full evaluation of the software, rather than go to phase 2, which would have provided money for the coffers. At this point, the only thing keeping MTA afloat was hope for this project and a tiny project. MTA stalled on delivering the software, saying they would only do so when the software went to phase 2. By the time MTA had backed down and provided the patch, I had already left. DERA cancelled the project and MTA went bust within the year.
Moral? It doesn't pay to piss off those who pay you.
My web domain.
The post talks about minor bugs being the ones that are hard to reach, but that's not necessarily the case. There was a piece of radiation-beam hardware used for cancer treatment (the Therac-25), that became a case study in engineering because of a literally fatal flaw. It was possible to mis-configure the machine so that it struck the patient with a much more powerful radiation beam than was normally allowed. The relevant point was, this situation only happened if the operator did some obscure, seemingly unlikely combination of actions that would result in a lead plate getting misaligned or something. Yet it happened at least six times, killing at least two people. The fact that the bug was caused by this particular sequence of actions made it that much harder to identify -- and it was not a minor bug worth ignoring.
Revive the Constitution.
If I connect my TV remote to the mains AC, it will break. I blame the makers for not 'validating' my input voltage. My Cups/Mugs all have bugs, as when I drop them, they break....silly makers for not designing in dampers to cushion the blow. My car has bugs.... I can very easily crash it, how dare the manufacturers make something I can crash by just pressing the buttons/ turning the wheel in the wrong order.
My point is, that practically everything will fail, or demonstrate unpredictable behavior if it is subject to conditions to which it is not designed to handle. We accept this, as a fact of life!....Why should software be judged any different, just because it's 'virtual' and cant really be seen as a real world object?...to make a perfect bug free piece of software is practically impossible.....well, maybe 'hello world', and even this will fail should it be run on an architecture it was not designed to run on.
Large corporations often like to buy "Enterprise" software with support contracts. If the software works perfectly, nobody is happy: the IT staff responsible for supporting the software have less to do and worry about their job security; IT management does not get anything demonstrable from the support payment; the vendor's support staff do not get a chance to learn how the software is being deployed in the field; the vendor's management have a high cost-per-ticket on their support line. Nobody builds relationships. If bugs cause small or medium problems, but the problems are handled well, corporate customers actually like this: rationally, it's a successful test of the support model giving reassurance that a big problem might be handled well too; irrationally, people feel better about a company after it handles a problem extremely well - e.g. quick resolution and apologies - than they would if the problem never arose in the first place.
Ask Toyota. But there is no need to despair. Toyota software researchers or anybody else who writes safety-critical applications should read this: How to Construct 100% Bug-Free Software. It can be done but we will need to change to a synchronous and reactive software model.
You cant afford perfect software.
The problem with that argument is that there is little evidence that it is actually true.
Let’s assume that by “perfect” what we really mean is “much better than most software today”, since no-one has yet worked out how to write literally perfect software. In that case, the difference in cost (by the time you take into account the full lifetime, including maintenance costs) seems to be rather small: it's not that great even during initial development, and the lower maintenance costs make it rather efficient to put more up-front effort into making less buggy code.
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.
Jumpstart the tartan drive.
You customers will be looking for whatever helps them get their jobs done the easiest, cheapest and quickest.
If your next release contains fixes to all your minor bugs but no new market-required features then your customers will be jumping ship to the competitor whose bug-ridden code does contain the market-required features.
I just requires a disciplined approach.
10,000 lines of C
0 Bugs
http://ertos.nicta.com.au/research/l4.verified/
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 push it upstream if it is OpenSource, but a lot of it isn't. It's almost never worth our time to do it for our own purposes, but it is worth it when you consider the total user base. /me contemplates the total manpower cost of most network administration UIs not being able to figure out that 0024.81b3.ff3e or 00-24-81-b3-ff-3e or 002481-b3ff3e are MAC addresses.
Someone had to do it.
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 lost productivity. As a user, the economics of this makes no sense.
It is exactly this sort of attitude which destroyed the American car companies.
putting the 'B' in LGBTQ+
Only god can create perfection. Every piece of software requires at least one bug to avoid blasphemy.
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 started making excuses and rationalizations, well, stretching the excuse just a little more or rationalizing a little further kinda comes naturally.
Same here.
But really, how do you know what you've _missed_? Because half the trouble with bugs is finding them in the first place. Something you didn't find (because finding the last little bug isn't worth it, right?) how do you know if it's a big one or a small one?
And if you found it and decided to ignore it, how do you know if that small bug isn't a symptom of something bigger? How do you know if that spurious failure to save the settings on the third page of a dialog buried 6 ft deep in menus, isn't symptomatic of a problem in a library function that is also called somewhere else too? How do you know if the same clever function -- or a version of the same clever hack from the same programmer -- isn't also used, say, when saving that 30 page form that the user has been editing? That's a big bug, especially when you deal with contracts worth hundreds of millions.
I mean, after all, the whole point is that you don't know exactly what line or method is causing it, or you'd have fixed it. So how do you know in which category to file the _unknown_?
A polar bear is a cartesian bear after a coordinate transform.
So user impact being considered when assessing a bug's criticality is uncommon?
Never happened. True story.
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 putting a Unix core under the Mac and they were mocked for it, "why do consumers need that level of reliability?" Now, it's typical for a Mac never to crash, typical for an iPhone never to crash. Users may not even consciously be able to explain that, but it's part of what they love and why they come back.
Thr truth is, you can't parse out the right level of quality you're "supposed" to ship. You have to take pride in your work at every level. Software is layered, all dependencies ... if you don't shoot for perfect you will never even get good. And you'll get into the race to the bottom, making Wal-Mart software. "Hey. we have 1 less bug thatn our competition, break out the champagne!"
Generally speaking, users hate computers. No wonder the PC is being replaced by mobiles with simplified software and a much, much higher expectation of quality.
So there is always damage from bugs. It may not be measured in this quarter's report, but you can see your whole product or company or platform hurt by it long-term.
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 redundancy, there was essentially zero chance this would lead to a major incident.
The big muck muck decided to postpone the launch regardless, because, in his words, "of what the wires were trying to tell me". The wires were trying to tell him that their statistical models concerning production quality were incorrect one way or another. If you quality process is broken, this is something you want to know before you let the big dawg ring in the new year.
The second question you need to ask is this: is the root cause behind the bug forgivable? Or was the programmer responsible (or just as likely, the culture created by the management team) unable to free itself from a wet paper bag? Does the bug indicate a state of crisis in personal topology assessment? Is this the first visible black buboe in a software release candidate rapidly progressing toward death rattle?
Forgivable bugs are bugs created when programming to a poorly documented API, which leaves out important cases, or gives you false of conflicted information. Especially if "I don't trust this edge condition" is found in the program comments and some sane defensive coding strategy was employed to mitigate this.
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.
Given a choice, I prefer to treat small bugs as canaries in the coal mine.
Another point. Obscurity is a fragile defense. Oops, the senior climate scientist just launched a month-long computation at E3 with the wrong initial parameter because of an obscure user bug three levels deep in an advanced sub-menu.
I'm more forgiving if the feature was only added because an important, yet lame customer demanded a feature that should never have been added in the first place, because they were too lazy to realize they are trying to use the software in the wrong way (but we've always done it that way). It's darn hard in practice to perfect the wrong basic approach.
In many other contexts, the obscurity of the function that blows up is directly proportional to the importance and gravitas of your first customer who trips over it. Does this person take the economic view (small bugs are expensive to fix, so I'm better off using a buggy piece of crap) or does he do what your management doesn't: evaluate the competence of the organization who produced the bug, from a psychology of extreme prejudice towards incompetence? I know I'm usually PEPTIC.
A triage culture lacking a robust root cause determination (e.g. five whys) is deep into the management zone "run, baby, run".
Does this economic wisdom boil down to anything more intelligent than the maxim that "if you can smell the fuel leak all the way back to mission command DON'T press the big button"? Yes, there's a natural priority in the order of things to first rooting out egregious incompetence. Then the serious work by serious people begins.
There's no better quality culture than one were every minor lapse of competence sails directly and efficiently back to its rightful owner. In the five whys culture, every defect generates a list of rightful owners, all the way up the chain. Now you're really getting somewhere. Along with that, it's nice if everyone buckles down to fix their corner of the problem rather that groping around for plausible yet ultimately failed excuse perspectives.
Ahh, the joys of the Dunning-Kruger effect: being too unqualified to realize one is unqualified.
The author of that blog post basically reinvented Stress testing (yes, software which can replay input sequences and even variations thereof, and compare the results to expectations, already exists and is used), but is too ignorant to understand that it exists, or why it's not a complete silver bullet. Hence he thinks he invented how to write 100% perfect software.
Well, so far that would be just ignorance at work. Too ignorant to realize ignorance.
But when he's sufficiently full of it to post stuff along the lines of "Academics can kiss my ass" when they disagree, now _that_ moves it to the realm of plain old stonking stupidity.
A polar bear is a cartesian bear after a coordinate transform.
That is nearly bug free. The "trick" is to have well defined interfaces and to write tests at unit, integration and program levels that exercise every line of code with boundary conditions. When you find new bugs, add them to the tests, then work to make the tests you added pass without breaking anything else.
You can even do things like looping the tests and profiling your program to make sure it's performance is as good as it can be at every level.
there are NO excuse for software that offers features that don't function properly.... who implemented the feature? they didn't test it first?
If it is OK for some obscure features to have bugs, then this is an indication that these features are not really needed. The solution is neither to fix or not fix bugs in this feature but rather to remove the feature entirely.
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 framing carpenter and his techniques of chopping off a 2x4 with a hand help skill saw to the techniques of a finishing carpenter laying a hardwood floor who uses a $1000 sliding compound miter saw?
You see every one of those cracks and bad cuts cannot be fixed later. The whole floor has to be torn out and done right.
In house building the miss-cuts behind the drywall often won't be seen unless the job is so badly done that main support beams are left out - and I've actually seen this done!
In programming the cracks will become apparent. These will be things like error codes not checked and code to handle unlikely cases not being tested. In windows 95 for instance we found that one could shut a SCSI disc drive off while the operating system was accessing it and there were no errors or warnings... it just went to normal end of job! Now that is crappy coding if anyone asks me!
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.
" It's buried deep, and when the user hits it, he says 'huh,' clicks a button, and then goes on his merry way... having a few users hit some bugs they won't care about." For commercial software that people are paying for, this line of thought is a bit of a misnomer. if that user took the time to go down to that 3rd level menu item, then for THEM, it DOES matter, and they won't say 'huh', they're going to be pissed & wondering why that company would add a feature into the program that doesn't work right. I think the challenge that people in our (I.T.) industry have, is that they don't always realize that most people do not think like we do about software. WE realize that it can't be absolutely perfect, and we understand what programmers do and have to deal with. A normal user who is a plumber, or a teacher, or a doctor, or a student will be less than understanding about functionality that does not work properly. So, it's not about fixing every bug and that it will cost way too much to fix it; it's more about that software companies should look at fixing every bug that they DO know about, and if it looks like that cost will be way too high in comparison to the number of paying customers that might want to use that feature, then they should look at perhaps removing that feature until such time that it can be added back in and also work properly.
Cheers! - Steve from MyBrotherSteve.com
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 exception! I don't care how tight the deadlines are - I'll buy you guys the time and I want tight code! We were building a major database and I didn't want it full of garbage because of crappy code!
Everyone agreed.
A month later one of my programmers was having trouble getting some code to work. She just couldn't find the problem! So she brought the code to my office and we started going through it. Return codes were not tested! I asked why? She said she didn't have time. I told her she did have time and told her in the project meeting the month before I specifically said we do have time. I asked her to put in the code to test the return codes and run the program and come back to me.
Off she went.
2 hours later she was back and said she couldn't understand why her program was saying the database could not be opened. I looked at the call to open the database. It was correct. So then I looked at how the variable that held the name of the database had been set up. There was a typo. She went off to fix it and had it done in about 15 minutes and the program had been re-run and tested by then and it worked. We were able to complete testing in a day or so and it went into production.
My point is this. It was less than 2 hours work to test the return codes but because she was cutting corners we lost more than a month of project time! Not only this the company was expected to pay her salary while she spun her wheels pointed in the wrong direction due to her shoddy code.
It simply does not save project time to write sloppy code. I've seen a lot of sloppy code in my day too!
Check out his free energy rants, and other quality postings which involve denouncing science and insulting every forum that mentions his blog in a bad light. He could be a professional troll for his day job, but this is the internet.
Oracle shipped their database ported to Dos. I don't use their products anymore. This is what they did.
In SQL*FORMS one could define a field and indicate that is its numeric. One should not be able to type in "ABCDE" in an numeric field. Indeed if you did then SQL*FORMS trapped the error. However SQL*FORMS also allowed a trigger to be set for the field. If the trigger was set they disabled the error trap! That software was so buggy it was almost impossible to use! In the next version they had the error trap enabled but they changed so much other stuff that I had to re-write the code. It does not feel good having to go to the client and advise that after months of work the product cannot be delivered and that they will have to wait months longer for the next version and hope for the best!
Borland shipped C++ for OS/2. Again - a system full of crap.
IBM had so many problems with OS/2 that there were many things that could not be made to work! One was networking between windows NT and IBM OS/2. FTP transfers would just fail. No errors and no warnings.
Then IBM had the great "feature" in OS/2 that on a dual monitor system one could open a "DOS" window on on the VGA side. The other side was 8514. If the focus was in DOS then OS/2 windows on the 8514 ran. If the focus was in an OS/2 window then the DOS window not only froze - they blanked it out too!
When Microsoft brought out NT 4.0 OS/2 got the boot! Funny - OS/2 didn't make it in the market place. I had a tech support contract with IBM back then as well! Another thing that was funny is that NT ran command line OS/2 code better than OS/2 did. So how did IBM benefit from their buggy code?
Here's one Microsoft pulled off. In their Fortran for Dos compiler we found a serious bug. I don't know what triggered it but the compiler would remove certain "if" statements. I managed to find it by looking specifically at the machine code and sure enough the instructions were not emitted. I submitted a report to Microsoft and went to the client and fortunately I was dealing with engineers who did know something about programming. I showed them via the debugger that the code was not there! We figured out a way to get that specific "if" statement working... but we were dealing with 100's of 1000's of lines of code! How does one check what other "if" statements might have been discarded by that crappy compiler?
So over the next year I checked up with Microsoft every few months. Eventually they told me to buy the new version. I did and when it arrived the first thing I did was to check to see if the bug had been fixed. It wasn't! They never did fix it that I know of. Eventually we got to move off DOS into windows. So I ordered that version. I found the package actually contained two (2) compliers. One was for 16 bit DOS mode. The other was for windows mode. They were incompatible with each other. I gave up. I have never programmed windows in my life! I do not use it! I did run NT for a while but never wrote any "windows" code. I use Linux today and OpenBSD and that stuff works!
Where I am, bugs, half-baked functions and missing features allow expensive software contracts to keep development teams alive. As soon as software become stable, customers tend to start killing off support contracts. Well, a little pain, is good for the soul. In this case, the user's pain, for the developers' soul.
I've always been inherently suspicious of people who claim to be programmers and then recommend articles like this. Instead of reading the fucking article, why don't you go fix some of your fucking bugs? ;)
After all, they're both mythical beasts.
He pisses you off, doesn't he? LOL.
That is why i always leave bugs, it is not because i am a sloppy programmer
My code does its basic job so well, nobody wants to pay for upgrades or maintenance.
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 it stopped at that).
With no particular effort on my part, and quite ironically, I stumbled upon the cause of the bug about a week later and fixed it. I never mentioned to anyone that I had in fact fixed the "not worth bothering with" bug. But secretly I was pleased that my work would not suffer from the mandated compromise.
Of course, this is just the bug I "knew about." :-)
Why is it that software is one product in which bugs are acceptable? What if other products were this way?
- Sorry, the car will not shift into 5th with the radio tuned to FM the rear pasenger window down halfway, and the armrest up, you have to put the armrest down to go on the highway.
- Sorry, we don't serve coffie on the 3rd tuesday of the month, please come back tommorow.
- Sorry, this dictionary does not include the letter p. lease use another word.
I understand that programmers are pushed to continually do more with less, and still get the product out, but every industry is this way. Only software has a cheap mechinism for improvements to be incorporated after release (patches, updates, versions, etc). In other products, the cost to correct errors is very high (recalls, discounts, or scrap), and are borne by the supplier, not the users. In software, the costs are borne by the users, not the suppliers, and so there is an incentive to release suboptimal products.
PC computer games have a low cost to the supplier to fix after release, and so there is an insentive to release on specific deadlines. On the other hand, consele games have (traditionally) had a higher cost to fix (impossible, prior to the newest generation of consels) after release. There is a long history of PC games being practically unplayable at release, and some are never adequatly fixed, whereas is is very rare in which there are significant problems with a consel game.
- Masters of Orion 2 PC (Misiles incoming should we raise sheilds captain? No, lets wait until we lose one death star class ship, before we raise shields or open fire)
- Enter the Matrix PC (don't enter that room)
- Empire total war PC (It sure would be nice to finish a game in that dosn't just crash, but the error is at least 20 turns back in the saved game file, so you just can't go back and try again)
- KOFOR2 Xbox, then PC (I will give you this one, at least it did not crash).
The only way that this is shifted back to the supplier is through "goodwill". Until users demand bug free software, and shift the costs back to the developers, this will not change. From the posts above, there appears to be split on this issue, with some programmers accepting the need not to use up goodwill, and others stating that bugs are a fact of life.
Wouldn't it be "fristbr0n"?
dom
If you're trying to ship quality software, you don't just _fix_ bugs,
you treat each one as a learning experience, a mini-laboratory of
"what went wrong" here. You don't just fix _this_ bug; you adjust
your processes/standards/whatever else so that this bug can never re-occur.
You also find out where _else_ this bug may have manifested; often
in slightly different ways. It's unlikely to be the only exemplar of
this type of bug in your system.
Just doing a cost/benefit analysis saying: nah, unimportant, don't fix
it is stupid. _This_ bug may be unimportant, but it may exist somewhere
else where it is important, or someone may write the same bug tomorrow
where it will be important.
You seem to misunderstand my point. Yes, you'll never have a perfect system. But if you aim for anything less, you'll hit even lower.
And experience... well, I admire your optimism, but it was some pretty experienced teams that produced some of the worst bugs and vulnerabilities in history. The OS/2 Warp install bug which produced a non-bootable system when upgrading, for example, that was a major killer for IBM's hopes of market share. It wasn't done by some newbie inexperienced company.
Or as a more tame example, I've spent saturday night on Star Trek Online trapped on the Sol spacestation, because there wasn't a universe any more outside the space station. Eerily reminiscent of the "Remember Me" episode of The Next Generation, but I don't really think the devs were aiming to recreate that experience in STO. The servers for everything else than the space stations had crashed. They had been unstable all day too. There weren't many happy customers on Saturday, and it might just have lost them a chunk of subscriptions. It doesn't take too many of those to negate any savings from not testing thoroughly and generally from not fretting too much about finding and fixing everything.
That wasn't an inexperienced team. We're talking about a company who's made 3 MMOs so far. But they judged wrong. Or rather, as good as any wild uninformed guess about the unknown. Plus, again, they had aimed low (as Cryptic usually does) and unsurprisingly they hit even lower.
I don't believe there is any relevant experience which will prepare you for categorizing the bugs you didn't find.
A polar bear is a cartesian bear after a coordinate transform.
While I was in uniform, I couldn't afford to do anything less than perfect software. When the potential cost of an error on my part was the loss of life or limb by an individual, or group of individuals, and the penalty for it was a sentence to Ft. Leavenworth, Ks., being guarded by pissed-off US Marines, or possibly even death, that concentrates the mind wonderfully [to mangle a quote]. I think this is a major difference between in approaches that I see throughout this discussion. To wit, penalties.
Not once in the ten years that I was coding for the military nor in the two decades following (and yes, the software is still in use, typical of the military, and works just fine despite OS changes) was an error ever found. Therefore, it is possible to write (at the least near-) perfect software. However, this isn't just about just the penalties.
None of this was easy although it actually took me and my team far less time to successfully complete our projects than is typical of other teams and projects that I've seen over the years. That is almost entirely due to the fact that we did engineering rather than ego-driven 'development', i.e. we took already existing, provably (mathematically) correct algorithms and data-structures with a heavy dose of built-in error checking in the form of state-machines, what I took to calling design by contract (strictly constrained, enumerated, and validated inputs & outputs), and extensive inline documentation especially for compiler or OS bugs of which we found more than a few for which fixes had to be encapsulated (hopefully for later removal).
I specifically bring up the time savings since, at first, it didn't seem that way as we easily spent three times longer in the actual design phase (architecture, data-structure definition, algorithm selection, language(s) and tooling selection, etc.) yet the actual coding phase was just a few days and testing also only took days to identify the previously mentioned OS and compiler errors. This allowed more time to be spent on requirements collection (at least a week of hands on, anthropological interview style with the potential users) and user training during the installation and turn-over phase. The total project time was just a few weeks, at most, and these were neither unambitious nor small projects. It did take demonstrated, markedly positive (multi-million dollar ROI), results to convince 'management' that having people staring into space, scratching on legal pads, with stacks of books, and tapping the CompuServe fora (these were the pre-web days) was a good thing. Furthermore, we could often restructure a work-flow or the entire application in a few hours and they were doing exactly that with one app I had created just a few weeks before the door hit my ass as I was being (medically) discharged from the service. All my work yet the modifications (a total reversal of work-flow) was happening in mere hours and they were having fun (yes, fun) doing it.
However, I find it highly unlikely that we'll ever see these efforts in the 'real' world given a culture of (barely) 'good-enough', and no liability for fitness let alone correctness {RTF License/User Agreement}.
"[I]t is a wise man who admits the limits of his knowledge or skill, and that pretending either causes harm." --Terry Go
>> "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."
So... in other words, meh
-- I was raised on the command line, bitch
One shop I worked in assigned each 'issue' a severity level from 1 to 4:
1:
- program crashed
- loss of user-entered info
- wrong answer given and it wasn't obviously wrong (from customer's point of view)
2: obviously wrong answer, no workaround
3: obviously wrong answer, workaround available
4: minor issue, such as documentation typo, consistency of UI, etc.
The 'how easy' to trigger aspect of the issue was only informally considered when prioritizing issues w/in a level.
Are you Microsoft in disguise, demanding all firstborn on the planet?
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
And I got bugspray, because it makes bugs pray!
--- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..