A recent article on Slashdot asks the question "Why do computers still crash?". And a fair question it is, too, which got me thinking...
Some interesting discussion follows. Many comments suggest that reliability is simply too costly for some markets to bear. Many conclude that the PC consumer marketplace is not prepared to pay for quality. They also point out that vendors frequently favour new features at the expense of quality, and that users have come to expect this.
But is that good enough? What quality attributes are important in your projects? How are your processes supporting your quality goals?
Performance seems to get most of the focus, even though it is frequently handled poorly. But other quality attributes, such as reliability, correctness, security and maintainability (to name a few) seem all too often to be ignored. The general perception is that it takes too much time and effort to address all these issues.
But is it really so hard to do things "the right way"? Is it really too hard to produce quality software for the PC marketplace? Do we not have the tools, processes, knowledge and experience to address all these quality attributes?
Just because the market has been desensitised to software faults, should be continue to produce software that is just "good enough"? Are we better off just shipping the next version, and worry about the problems as they arise? Is this somehow more efficient?
I would argue that not enough value is placed on quality by management. Since users (at least in the PC marketplace) will accept low quality software, management is not prepared to accept the cost of "getting it right". I frequently hear stories of developers instructed to cut corners to meet unreasonable deadlines. Even the most hardy of developers wanting to do their job properly will eventually get worn down by this culture, become cynical and learn not to bother. All too often, management takes a terribly short-term view, and does not consider the hidden costs of not fixing things up front. Just about every Software Engineering textbook ever published will repeat the fact that the later change occurs in a project, the more expensive it is to implement. So why don't we do things right the first time?
It would also be interesting to compare development practice between those targetting the PC market versus those targetting midrange or mainframe systems. Are the processes the same? Are the quality goals the same?
Please add your experiences and comments below...
I remember reading something
I remember reading something about this topic a while back, but it was presented on a political angle. If i remember correctly, it was debating the production of quality COTS products and versioning. One of the reasons was simply due to the fact that if they produced a high quality product first up, they would not be able to rake in more dollars from successive improvements (yes I think it was a M$ article!).
Maybe its a similar motive here? That when decision makers get pressed with a choice to ensure quality or "get something working", they choose the latter to retain the customer's interest and hope subsequent releases will keep them onside.
For some reason the consumers psyche allows for this right? I mean you look at all the microsoft consumers who want particular features but use their products anyway hoping that in future releases their problem will be addressed. If buying history is an anecdote, then it shows that most consumers don't stray from particular vendors unless there is a strong reason to migrate. So really it comes down to how well COTS (and maybe custom) software houses understand the psychology of their customers.
That just might be one factor in a fairly concerning area of software development that you pointed out.
Mark
ps. Hi Gav!
No competition
This assumes you have not got a viable competitor with a better quality product that disenchanted customers can switch to.
Marketing is also a big factor in being able to sell rubbish to customers and get away with it.
Steve (www.step-10.com)
Doing the "right thing" is not the utmost priority
Gavin,
They have other higher priorities than doing the right thing, one of them is - survival - that means making money. Even if at the expense of loosing money in the long run. In the long run we're all dead, why worry about tomorrow when there is today to contend with :) Getting it right is a luxury that only the wise or resourceful (time, money) can entertain.
Related, is Gabriel's discussion of "The Right Thing" vs "Worse is Better" in the domain of software design, original in his paper, Lisp: The Good news, Bad news, how to win big. As an example, he compares the virtues of getting an elegant API that is hard to implement versus that of an easy to implement design with a user-beware API for the lusering problem.
Doing it right is not always desirable.
Just about every Software Engineering textbook ever published will repeat the fact that the later change occurs in a project, the more expensive it is to implement. So why don't we do things right the first time?
Doing it right (the first time) is not always possible. Agile Processes recognises that (Highsmith, Agile Software Development, 2000).
mark
doing it right the first time
Doing it right (the first time) is not always possible. Agile Processes recognises that (Highsmith, Agile Software Development, 2000).
Why do you say that?