Enterprise Services
Showing results for 
Search instead for 
Do you mean 

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

‎03-11-2014 11:57 AM - edited ‎09-30-2015 07:02 AM

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


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



Blogs in the Producing Quality Software series 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.

0 Kudos
About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. 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 lives in Toronto, Canada.

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all