Is There Ever Going To Be Sufficient Economic Incentive To Do Software Right
Is There Ever Going To Be Sufficient Economic Incentive To Do Software RightIs There Ever Going To Be Sufficient Economic Incentive To Do Software Right ?
Could it be that because of the ImbalanceOfPower, and its concomitant ImbalanceOfEconomicIncentive? there will need to be a deep change in our industry before it becomes economically viable to do the job right? To, in the words of RichardDrake, "reform the economics and ethics of our business."
In a word? No.
In two words, "Why not?"
Sure. At the EndOfMooresLaw (where the reason is explained also - more or less).
Because they certainly do need reforming. It embarrasses me that my work gets sold under the kinds of "warranty" that are endemic in the industry, that is, no warranty at all (but with generous terms for after-sales support!) Only the automotive industry has this kind of brass neck.
Coincidental that both industries make more money the more defective their product is? In software more bugs means more support/upgrade profits. With cars it's more profit from auto parts. That alone renders the entire subject line of this page moot. Microsoft has made way more money from forced upgrades than if the original products had been near-perfect.
On a recent internal course, which dealt in part with the commercial and cost-accounting aspects of running a project, I did suggest that maybe there might be a market for software done right, with a real "it will work" style warranty attached. I was damn near laughed out of the room.
I feel that this connects with the question: WhatIsSoftwareEngineering?. If we were software engineers, accredited by a professional body, with the quality of our work guaranteed by that body, then we would be accountable for the compromises we introduce into our work.
The people that wrote the software in the radiation therapy machine that killed the patients would never work in software again. We would have to guarantee that delivered software would work as required, or not get paid And so on.
I am not sure how "accreditation" would be anything more than a big bureaucracy. If we don't know how to teach people how to build software, how would an after the fact investigation help? Software working "as required" is largely a matter of opinion. --WayneMack
It is quite normal for Lawyers, Accountants or Architects to be accredited professionals. Why not SoftwareEngineers?
Perhaps never work in software again is a bit extreme. After all, should they be totally disbarred from writing web sites and non-mission critical databases due to such a mistake? I don't really think so. I think that were there a formal system there would need to be degrees of qualification. So, after the TheracTwentyFive Incident, the involved programmers' qualifications are reduced to never be allowed to work on anything life critical again.
I have refused to work on life-critical systems where insufficient hardware interlocks were present to prevent software failure from taking lives and limbs. They should have, too. -- WayneConrad
I think this is unfair. Two points:
In the case of TheracTwentyFive, the ones actually doing the reuse should have refused. If they didn't have the experience to know that they should have refused, then the blame goes to their bosses for hiring inexperienced workers. -- WayneConrad
The Space Shuttle folks do it - TheyWriteTheRightStuff - but they have a client who will spend large amounts of money. For the rest of us, we need to find TheBetterWay? -- RobertField
Don't forget the Mars lander. Money does not solve the problem.
I will probably be embarrassed by this paragraph some time in the near future, but here is a vision unsupported by any facts:
I must be missing something. What do we mean by "right"? I've always done software as rightly as I know how ... why don't you?
The judgment of "doing software right" is based on results, since that is really all that matters in an economic task. If you do software as rightly as you know how, that doesn't mean that your results will be "right". (See also DoingThingsRightvsDoingRightThings).
Results can be both quantitative:
This page reminds of the traditional problem with FormalMethods - frequently, it's much harder to specify "the right thing" than it is to implement it. People often lose the will to carry on when they realize just how much work goes into specifying "the right thing". The data acquisition case study in chapter 8 of ObjectOrientedAnalysisAndDesign looked simple and plausible until I wrote it up as a formal spec. The C++ code in the book looks so plausible. It was amazing how many questions it leaves unanswered. Let's hope nobody copies the TimeFrameProcessingArchitecture as its described in the code.
Assuming that we have the technology, management processes, and people to "do software right", there is still the following informational imbalance:
Vendors have some idea of what it will cost them in terms of time, money, and market share to make a product "right" vs "wrong". Customers generally have little idea of what the flaws in their software are costing them. The people who make customers' buying decisions may have less idea than the people who actually have to use the software or make it work. I suspect that this causes a bias toward producing lower quality software than would be produced under conditions of perfect information. If software moves to an ASP model, where the "customer" has a more equal relationship with the software vendor, I suspect this bias would lessen. -- MatthewWilbert
Right isn't perfect. Right is delivery of value that people will pay for, at a cost of creation less than what people will pay.
Or, if you can find a way to do it, right is building software and giving it away. What you do to eat is a problem. I choose not to address that mode of rightness here.
Software has value. Our economic system here and in much of the world is about providing value for profit. Since the cost of perfection is very high (as far as we know), there is a place for software that is imperfect but provides value that's in proportion to its quality.
My products have always sold essentially at the "market price" for things of the kind they were. Because of the values of my teams, and the skills of my teams, they have generally been on the high end of quality for such products. But they haven't been perfect.
The trick, therefore, is to find ways to build software that is of substantially higher quality, without increasing the cost substantially. Then you can choose between charging a premium and increasing profits, if the market will pay for quality, and between holding the price down and increasing market share, since surely the market will choose higher quality at the same price. (Marketing skills affect this. Better mousetraps don't always sell.)
This would seem to lead back to the issue of the marketing of quality over the quality marketing.
Improved development process offers the prospect of higher quality for similar or lower cost. XP-style testing, for example, can reduce debugging time and pre-ship testing time. XP-style business value orientation can increase quality at any given point in time.
There is sufficient incentive now. Just do it. -- RonJeffries
Is that last sentence Ron in profit mode or prophet mode? It's a cool situation when it could genuinely be both.
Right is consistent delivery of value that people will pay for, at a cost of creation less than what people will pay.
Well, that's exactly what I meant in ImbalanceOfPower, with just that one word added. I think XP has a lot to offer in delivering the consistency too, and that is part of the opportunity we currently have.
Although it's nasty to talk about, short-term economic incentives often exist (or have often existed, depending on how optimistic you're feeling about the current SoftwareRenaissance) not to do software right in this sense. To make the customer more dependent on you as developer than they really need to be, so that they end up paying more than they would originally have been willing to, for example. Sometime the boot is on the other foot, with the customer finding a way to screw the suppliers, of course. But these two wrongs certainly will never make a right.
Better educated purchasers and suppliers of software development have got to be the answer, leading to a marketplace that is both highly competitive and very rewarding for those that deliver superior business value. I want to be part of that industry!
To put another spin on it, it's all about freedom. Right means that the customer has the freedom to choose what features at what cost. Right means that the developer has the freedom to estimate cost without pressure and to implement without interference. For me, the beauty of XP is that it supports these freedoms to a degree that I have not seen in any other process.
There is also a theory oft-floated that there indeed will never be such an economic incentive. OpenSource is supposed to solve this by using peer review and public humiliation to pressure would-be authors into making quality software. Unfortunately, as seen by the glut of half-started projects on FreshMeat, this isn't working so well.
The number of moribund projects on FreshMeat, SourceForge, etc. isn't really a testament to the failure of OpenSource - it's just an indicator of the low BarrierToEntry on those sites. I can create a project, add no source (or minimal junk), and forget about it. Nothing about peer review there. The same thing happens in closed-source shops all the time--it's just not publicly announced.
I don't believe quality software is a matter of economics, it is a matter of knowledge.
Once you have appropriate knowledge, good quality software is simply easier to produce than poor quality software. The problem is the low level of knowledge in general about software construction and the limited communication of this knowledge to others.
A pet peeve of mine is the way software is taught in school. A student will typically have a 1 semester course teaching the grammar of a language. He may also take a second "advanced" course still limited to the basics of the language. Most students come out of school without even a basic idea of how to develop anything beyond a trivial, one feature program. Forget about program structure, ideas like writing a separate test program, or any sort of systematic debugging skills. We teach developers how to be spelling bee champions and then wonder why they can't write novels. (See BadStuffWeLearnInSchool.)
Forget about economic incentives. If you don't know how to do the job better, more money won't help. If you know how to develop better software, it will be cheaper, both in the long term and short term, to develop higher quality software than lower quality software.
If you don't know how to do the job better, more money won't help. -- WayneMack
And also, if you don't know how to want to do the job better. Somewhere behind all of this there must be a motivational system, not necessarily money, most likely not money. Where in the bejeezus is that system? Why is caring such an unpopular emotion in this day and age?
--WaldenMathews (wishing I'd been born at least a century ago)
Why must there be a motivational system? I believe most people want to do a good job. In my experience, the only exception I have seen was one college intern who was only motivated by the money. I am not certain if we could have raised his salary high enough to get him to do a good job (or even show up reliably). People do care about their work. Try telling someone he did a lousy job sometime if you want to verify this. -- WayneMack
Wayne, your pet peeve above has been around for decades. Why must there be a motivational system? I don't know. Are you expecting something to change in the schools? -- Walden
Certainly, people want to do things right, but as you (Wayne) pointed out above, you need knowledge. They need the motivation to learn and improve their skills so they are capable of doing better. I've met a lot of poor programmers who spent no effort learning. Sometimes, this was because they felt they already knew how to program. Often, this was because learning takes time - time they didn't get paid for. (See HindrancesToLearning.)
Yes, I am hoping that things will change both in schools and in business. Schools need to do a far better job of preparing students to work in the real world and businesses also need to do a far better job of preparing their employees to do their jobs successfully. Why should an employee have to play martyr and work full time and then spend additional time (and often money) to learn how to do his job better? I don't view this as a motivation problem on the part of the employee, but rather an unreasonable expectation of the employer. -- WayneMack
Most commercial software does not meet up to the quality standards we expect from other goods because of two forces. The first is that it doesn't have to, and the second is that people would rather have features than quality.
Compare a piece of software to the lowly electric pop-up toaster. Even the toaster, however, is considered a LifeCritical system--if it fails, it could start a fire. Thus, some actual engineering goes into it, as well as testing to show just how much abuse it can take before it shorts out.
Most software is not LifeCritical - at most, it's MoneyCritical. Thus, there is less reason to remove defects in such software than in a toaster. You reach the point of diminishing returns faster.
Meanwhile, software is the ultimate plastic, morphable into new things every day. The customers demand new features. They want the new features even when they have to pay the price in defects.
Thus, the economics is skewed in most cases to quality (defined here as the inverse of defects) falling prey to features.
I believe we should be reviewing the ProductLifeCycle
"The customers demand new features. They want the new features even when they have to pay the price in defects."
What make you think they "want" to pay that price? It might be more truly said: ''The customers demand new features. They want new features, even though they are delivered with defects!' The customer is not responsible for the "defects" in a software product. It is delivered by those who just can not say "No, not yet - we are not done". The pressure to deliver the product is made by the customer - TRUE - but the choice to deliver a package that pays the price in defects is that of the developer.
I have rarely met an actual customer who demanded a new feature. How could they? Customers are most likely to request changes and corrections to existing features. Few companies actually invest the time and effort to talk to and understand their customers (this is true both for software and companies in general), so most new feature "demand" is internally generated by the companies themselves. -- WayneMack
Several Companies - Including Autodesk (the company producing Autocad) - provide user input via a "Wish List" - And to Autodesk's credit, they often deliver the new feature without the defects!
Don't forget that consumers don't act in a vacuum. The propogandists/advertisers drive much of customer demand.
No! There will never be an "economic incentive" to do software right. You can do all sorts of cost/benefits projections, but none will ever prove that one approach is more economical than another. As long as people fundamentally believe that quality costs more, any logical arguments otherwise will fall on deaf ears. Even among software developers, there is a belief that mistakes are an inherent quality of software development and cannot be prevented. Until this attitude changes, there will never be enough economic incentive to do software right. -- WayneMack
See also: BugFreeDoesntSell
I discuss a different take on this issue in ProfessionalPerfectionism...
Along the lines of DoingThingsRightvsDoingRightThings.
I'm interested in IsThereEverGoingToBeSufficientEconomicIncentiveToDoRightSoftware?
I'd like to suggest that there is a simple reason for limits to software quality. When it comes to mass-distribution software (as opposed to custom corporate stuff), the maximum price that can be charged for one license, is the equivalent of the inconvenience factor of copying the diskette or the CD.
Software is like the replicator in Star Trek. You can make as many copies as you want for little or no cost. How can I be stealing if, after I have copied your software, you still have physical possession of the original? (I say this facetiously).
Would Ferrari or Porsche still be developing new cars if we could replicate them at the push of a button, and all they ever got to sell was one copy?
The only people getting full price for their software, are those who bundle it with a piece of hardware (printer drivers, aircraft, VCRs). The rest of us have to deliver the best quality & features possible, while staying under the aforementioned price ceiling.
I'm sure someone could produce a rock-solid, perfect word processor or spreadsheet, for $1,000 a pop. I suspect people would buy one copy, and duplicate it for their friends.
Quality costs, be it software, bridges, buildings or food. You don't get what you don't (or are unwilling to) pay for.
Peace & serenity.
I posed the question IsThereEverGoingToBeSufficientEconomicIncentiveToDoSoftwareRight to a colleague and his response was that there already is. His example is Blizzard, a game software company. I don't play games -- so I wouldn't know -- but he claims that this company is successful precisely because they do software right. He claims they spend as much time as needed to get the software right before release, and that there must be sufficient economic incentive to go about doing things this way since they are the most regarded game software company around and also one of the most successful. I've never played a blizzard game, so what do I know.
Your friend hit right on the mark. I have played Blizzard games (WC, WC2, SC+exp, WC3), and I tell, their releases are very stable. All their patches are basically minor tuneups for play balance. I think the difference with Blizzard is their management has the willpower to delay a release to do it right than to succumb to the financial pressure to just get it out for some cash flow. Everyone can tell you releasing a buggy software will probably cost more in the long run, but it takes guts in the part of management to delay a release, and not every manager has such guts. Delaying a release puts the manager on the line, while the blame of releasing a buggy version can be (and frequently is) passed to the techies.
I disagree. Blizzard does make very successful, generally bug free games. However, there are many other companies making successful, bug ridden games. Game players buy games based on fun factor, not based on lack of bugs. Of course bugs are not welcomed, but they are accepted. The complete lack of bugs would not be a significant reason to buy a game, so Blizzard's success is more likely due to their dedication to creating games that people will find fun and making simple, intuitive interfaces that allow both casual and hard core gamers to play the games easily. --BrianRobinson
IsThereEverGoingToBeSufficientEconomicIncentiveToDoSoftwareRight ???
Not from me there isn't. I'm sure as heck not going to pay three times as much for my software just so it will crash every six months instead of every month! The supply curve intersects my personal demand curve at software that is cheap, buggy, and does mostly what I want.
Of course if better software comes along at the same cheap price, that's a different story... ---
Two words: Lemon Laws. I first read the idea in the non-technology magazine TheEconomist, but I think it could be sound. Such libality could also be insisted on by customers, if they knew that lower error rates were possible.
With IncompatibleGoals such as "cheap, soon, and good, pick any two", time and money are the easiest to measure. Thus, "good" gets the slight. SovietShoeFactoryPrinciple.
The underlying assumption with this page is that software quality is a problem of economics. I do not accept that premise. In my observation, the opposite is true; the more a project overruns its budget and schedule, the more likely the software is to have poor quality. When software development is going well, the programmers are roductive and efficient. When the software developers are struggling with the code, it takes longer to get the initial code written, the code is much more likely to be fragile, the code will take more testing cycles, and the delivered code will have a higher bug rate. The issue is not that we are not spending enough money on sofware, but that we are not developing software in an appropriate manner.
I have refused to work on life-critical systems where insufficient hardware interlocks were present...
I have a tremendous amount of respect for you and anyone else who does the same. I hope I would do the same.
However, greed might tempt me to believe a seductive argument like:
I am very concerned because there appear to be insufficient hardware interlocks. No matter how carefully I write the software, people might die. However, if I refuse this job, then they'll just hire someone who cares less about human life -- those same people will die; perhaps even a few more. People will die no matter what I choose, so I might as well keep working to try to reduce the death toll, even if I can't eliminate it.
What's the flaw in that logic ?
Is There Ever Going To Be Sufficient Economic Incentive To Do Software Right ?
If I tilt my head and squint at the problem, it looks like yet another TragedyOfTheCommons.
The only solutions I know to that problem are
Is there any way to apply the "privatization" solution to this particular problem ?
privatization *only* works if theres economic incentive to do things right - if market forces will create an optimum outcome. For this to work with software, there would have to be a signifigant economic advantage to providing "perfect" software and in my experience thats not so. I reject a lot of the arguments on this page as failing the practical experience test - perfect software *does* cost more. It *is* more involved. More testing is required. More control over the final environment is required - I certainly wouldn't certify my software on hardware I hadn't vetted, not when my professional career is on the line. More expertise is required (obviously), and more imporatantly, infrastructure and theory that haven't yet been fully developed are needed. Software isn't like a mechanical good, and it's not like a service - it's like both of those things, and neither, and we as a profession and as a society don't have the tools in place to judge them. Just writing a sufficiently precise specification, such that you can reasonbly define a "defect", would add an enormous expense to most software projects. I think people over-estimate the perfection of other engineering disciplines too - the medical scanner thing is a good example. Why didn't it have sufficient hardware interlocks? Sure, thats a failure of the software, but why is the hardware designer getting off easy? Companies and engineers skimp on perfection every day in order to save costs, or because it's too hard, or just because they don't think of it. This is not to say that we don't have room for improvement - we always should strive to improve - but flag waving about software errors and pointing at idealized examples of other professions doesn't help either. You can draw some parallels to the medical profession - even with the strong theoretical and scientific basis, theres a lot still unknown or in debate, and economic pressures excaberate that problem. The result is a profession totally dominated by the insurance industry, patients/users/customers whatever are unhappy, and it's not unsual for an MD to pay *half* his salary in malpractice insurance. We could do better than to emulate that model.--ChrisMellon?
If you were forced to certify your software regardless of the hardware it's used on, you would quickly adopt the best practice of writing to a virtual machine dialect like VisualWorks.
If I were forced to certify my software regardless of the hardware it's used on, I wouldn't be a programmer any more. This would never happen, though, because nobody else sane would be one either. Software does not exist in a vacuum and thats one of the problems with the idea of licensing programmers. At the very best, I'd demand that my software be used in a one-off system, where I have direct contact with the hardware architects, I'd ensure it's correctness on that precise hardware, and I'd demand indemnity if any of it is changed. Interestingly, this is in fact exactly how extremely high reliability needs (NASA, most (but sadly not enough) medical firmware, etc) software is done.
And you know, it's only in the USA that the medical profession is privatized. Despite this, medical personnel in other countries are indeed professionals. Often more so than in the USA. -- RK
Note *only* in the USA, but true. My point is that privatisation will not fix this issue unless the economic incentive is to do software right. Since the whole point of this page and others like is that that incentive is not there, privatisation will not fix software.
I remember reading an article about economic incentives and the quality of software. It was mostly anecdotal information, but the author interviewed multiple companies and individuals and concluded that quality software simply doesn't sell well enough to justify the extra cost.
Part of the problem seems to be it's hard for potential customers to verify quality. About the best a potential customer can do is interview other customers of the software. However, this is often a small samples size, can be manipulated using "buddy" techniques, and users often remember other details such as user-interface interaction more than outright bugs. (Apple has shown there's a market for quality UI's.)
Another problem is the pace of change. By the time a given piece of software is perfected, some new approach or technology comes along and makes it obsolete. Just when you perfect your DOS version, Windows becomes "the thing". Just when you perfect your Windows version, web-based becomes "the thing", and so forth. Maybe touch-based tablets or brain-readers will be the next thing, who knows? There's some interesting research and experiments going on right now.
Sadly, this is true of almost every engineered thing; appliances, cars, tools, electronic goods, passenger airplanes, beer, etc. I used to collect vintage electronic test equipment, and I owned a pair of 40ghz military spectrum analysers made in the 1960s. Each was the size of a bar 'fridge, weighed about 100lbs, and was built to quality standards that make a Swiss watch look like the output of a spastic child constructing papier mache busts with a hammer. I've never seen the like before or since. Of course, these analysers were very limited production -- the serial numbers were, as I recall, #66 and #67. I can't imagine what they must have cost when new, but I wouldn't be surprised if it was in the low six digits, each. I've no doubt there is software of equivalent quality, but it will be of equivalent price. Consumer-grade software is, like all consumer-grade stuff, crap.
Some models of cars are remarkably reliable considering the complexity of cars these days.
EditText of this page
(last edited April 10, 2012)
or FindPage with title or text search