Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

Producing Quality Software (4 of 4): Why should we produce Quality Software?

By: James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company

 

check.jpgSo far, we have considered a better definition for software quality (What is Software Quality?) than the usually offered definition—e .g., defect-free—and have established that every role on a project is responsible for software quality (Who is Responsible for Software Quality?)—not just the testing team, as it is often suggested. We have also identified the three most critical factors for producing quality software—following a disciplined process; using skilled, experienced, resources in all roles; and paying attention to the details (How Can We Produce Quality Software?). This final blog in the series considers why we should produce quality software.

 

Some people might respond to my question with a question, “Isn’t it obvious why we should produce quality software?” But if it is so obvious, then why do so many custom systems not come anywhere close to meeting our definition for software quality? Like the quip, “common sense isn’t all that common”, the reasons for producing quality software aren’t well understood.

 

In reality, far more effort is given in lip service to the concept of software quality than to actually producing it. Every vendor proposal for the production of a new system will include the required buzzwords for quality. However, in practice, an emphasis on quality is often thrown out as soon as a project falls behind schedule. The collective attitude changes to: just get it done, and at lowest cost.

There are two primary reasons for producing quality software.

 

It costs less to produce

It seems to be counter-intuitive to most software project managers and executives that producing quality software is less expensive than producing software of inferior quality. Their perspective is short-sighted. During the early phases of a project (e.g. analysis, architecture, design) they begin cutting resource costs as soon as they see budget and schedule issues looming. Cost cutting at the early stages (e.g. eliminating peer reviews or substituting less experienced resources for more experienced ones) always affects the ability of the team to establish a quality foundation for the system.

 

Then, when their project runs into challenges during later stages, they cut costs again (e.g. system testing or configuration management resources). Instead of addressing what are often the real issues—ambiguous requirements, a lack of disciplined scope management, inadequate peer reviews of work products, poor estimates, scheduling errors, inaccurate progress data, and leadership indecisiveness—their mantra becomes, ‘hurry up and get it done’ or ‘just do it’. The result is they end up with exorbitantly higher costs in defect resolution and rework in the latter stages of their project. It is a simple reality that the cost to rectify problems later far exceeds the cost of doing it right the first time. Projects which are not cancelled are always able to find money to fix problems, but never seem able to find it to do it right the first time. Producing quality work products at every step in the process improves overall productivity.

 

It costs less to maintain

There are on-going maintenance costs associated with a production system. The poorer the quality of the software at the time it is deployed, the higher the maintenance costs will be. Poor quality software deteriorates faster (e.g. through layers of bug fixes on top of previous fixes), and reaches end-of-life faster than robust, adaptable, high-quality software. The cost to fix software post-deployment far exceeds the cost of avoiding the problems in the first place. Likewise, a quality system will last longer and defer replacement costs.

 

Consider a manufacturing analogy: Toyota was famous for its emphasis on quality production processes. Initially, their approach appeared to cost more because of the emphasis on quality at every step in the process—North American auto manufactures argued that Toyota’s costs were lower because they used off-shore resources. However, their overall production costs were competitive even in their North American manufacturing plants. Their reputation for quality cars was such that two versions of the same vehicle produced in one assembly plant—one with a Toyota badge and the other with a GM badge—had markedly different quality ratings and re-sale values. However, when Toyota took its eye off quality and started to covet market share, they made mistakes and had to recall millions of vehicles. In February 2010, Akio Toyoda made a public apology and emphasized that Toyota would redouble its effort to produce quality automobiles.

 

There are other reasons for producing quality software such as it engenders an esprit de corps, it is more fun, and it builds positive long term relationships between customers and suppliers. However, since cost is often the main (and only) consideration project managers and executives are allowed to focus on, we have to appeal to their pecuniary interests; we must produce quality software systems to save money. The challenge is how to convince project managers and executives of this truth: it costs less to produce quality software

 

Previous blogs in the Producing Quality Software series by Jim Hughes

Previous Focus on Fundamental blogs by Jim Hughes:

Other blogs by Jim Hughes:

About the Author

 

Jim-150X210.jpgJames (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He currently lives in Toronto, Canada.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author
Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Ana...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation