This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: How Important is Quality Software, Really? Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

This thread at Artima.com that Michael Feathers started encapsulates many of the ideas I've been having recently about raising the quality of software:

• If your code isn't testable, something is wrong with it.
• It goes without saying, if your code isn't tested, something is even worse.
• However, software isn't tested as much as it should be at all. Why?
• Software is much more forgiving than other "things" that we care about the quality of; you can just display an error message if something goes wrong, perhaps rebooting. Relative to, for example, a TV where a bad CRT destroys the whole thing, most software is easy and "cheap" to recover from. (Obviously, if for example, the software is navigating a vehicle of some sort, this tolerance for failure is much lower).
• It's become acceptable for low quality to software to be produced: people buy it, so it must be OK! Ship It!
• The idea that an experienced coder is better than an inexperienced one is often forgotten when you realize how much cheaper the inexperienced one is. That is, the primary thing that matters is cost, not quality. (Any possible connections between keeping down cost by using experienced coders over inexperienced ones is rarely acted on.)
• Very few Gold Owners act as if they care about the long term, instead they favor the short term. They want their Gold back, with profit-interest, ASAP.
• Nothing seems to matter more than delivering product as quickly as possible, as cheaply as possible.
• Even if you do everything "right," someone else will do everything "wrong," and deliver faster and cheaper than you.
• All of this applies to process as much as the actual code.

The most depressing thing in that train of thought is that (1.) long-term results are given such small value, but, (2.) the majority of the pay-off of quality software comes in the long term(support, flexibility for new changes, maintenance, etc.), not in the short-term (getting it out the door, keeping initial production costs down, etc.).

Thus, if the Gold-folk care more about short-term rather than long-term, the importance of quality goes down significantly. (I know there are short-term benefits to quality, e.g., the shit simply works rather than doesn't work.) Someone's priorities, or perspectives of the above, aren't quite right: mine, the coders, or the Gold-folk. Maybe all 3.

For a somewhat related post, see Fowler's recent one asking "Is agile development good for teams of all levels of experience, or just the highly experienced ones"?.