Quality is an after thought in software products (excluding critical applications like medical devices, FAA software, etc. ). I believe there are a number of reasons, most of which have to do with money and market place.

If there is a software defect, the customer will ask the vendor for a fix. Often the software manufacture will not fix the defect if the customer is a small part of the business. And many times the software vendors will say, "that will be fixed in the next release." Many times the next release is 8 months to over a year away. How many other products are like this?

Compare a software defect to an auto defect. Auto manufactures recall automobiles and fix the problems because they have to. Lawsuit's over bodily injury are feared. That is the only reason auto manufacture's fix problems with products: the threat of profit loss in a suit. Fixing auto design defects costs millions of dollars. Auto manufacturers maintain a standard of quality because they must, not because they want to.

The potential for body injury when using a car is much higher, however, even for a flaw that does not have an effect on safety-for instance, the car paint fades in 3 years-auto customers get money back or the auto manufacturer gets sued. In the software industry, if a customer has a problem with software and it costs thousands in lost productivity time or lost revenue, there is usually no legal recourse. Customers can plead for the vendor to fix the problem, but ultimately, the software vendor has the upper hand.

Software customers must spend time with training, infrastructure, and maintenance for the software they purchase, and the cost of fixing the problems caused by deficient code is often more than the cost of the product in the first place-a situation that would be unacceptable if the software industry, like the automobile industry, had to fix its own mistakes.

Software consumers do not have legal recourse for getting restitution on damages due to software defects. Consumers therefore accept the back-end costs associated with product updates that are needed to fix defective products.

Customers may be able to get custom software engineered to exacting "must work" specifications, but, as we all know, there are few situations where customers can afford this.

The software market will continue to deliver "good enough" software rather than high-quality software. What choice or recourse is there?

Edward Marsh

Hello Edward,

Part of the problem is, as you say, that the standards are somewhat lower for software than in other industries. What I am trying to do, however, is to motivate developers to improve the quality of what they do independently of any other influence. I believe a lot can be accomplished that way, even with very little expenditure of resources. In other words, quality of design and code practice can be more an integral part of daily development than it is, whether or not the boss knows about it or schedules it into the project. People can improve on their own just because they want to excel.

The day may come when lawsuits force more quality into the software development process, but I have not yet given up hope that software professionals can make great strides in producing better software without litigation. That has always been the traditional connotation of the word "professional."

ca

Perhaps my knowledge of thermodynamics has grown stale, but I couldn't grasp what you meant with the sentence:

"The efficacy of refactoring in reducing software entropy is now well established, for example, but few managers allow room for it in project schedules."

Would you re-word it for me, please?

Software doesn't get worse if nobody changes it: it is the rest of the world that gets better Once in a month of Sundays, software changes with no apparent intervention on it. When that happens, one must restore it from the backup. Backups reduce entropy?

Also, the software that is not in production can be changed more easily. Programmers write no nonsense to it. However, releasing software is a sudden snap not a continuous growth, so that's not related to entropy either.

I largely agree with the rest of your editorial(s) and look forward to reading more of them on this subject.

Regards,
Alessandro Vesely

Software entropy, as coined by Luke Hohmann, refers to the increasing state of internal disorder of a software system that occurs the more it is "patched" (without refactoring), as is done in traditional maintenance. Refactoring modifies the internal structure of the software to accommodate the needed maintenance change in such a way that the tendency towards disorder is lessened. That's all I was trying to say.

Thanks for writing.

ca

I'm a recent re-subscriber and am writing to let you know that the very first issue I received has made the subscription worthwhile.

I have a great deal of experience with non-embedded C++/OOP design, but I am not yet up to speed on extending the polymorphic, object hierarchy architecture to state machines. Lo and behold, "The Embedded Angle," by Miro Samek was in the first issue I picked up. Samek's column provides lucid examples of easily understood basic principles and, more importantly, excellent references to more in-depth resources. Very nice.

Dave Devoy

Glad to hear it. I relish every article Miro writes. Thanks, and welcome back!

ca

CUJ would like to make a correction with regard to the byline for the excellent article "Function Overloading Based on Arbitrary Properties of Types" in the June 2003 issue of CUJ. As stated in the original manuscript submission, the names should have appeared in the following order: Jaako Jarvi, Jerimiah Wilcock, Howard Hinnant, and Andrew Lumsdaine

All future references to the article in CUJ, the CUJ CD, and CUJ's web site will reflect this correction.

jc