It seems that there is a re-emergence of interest in software quality economics, especially as regards to what I termed the Cost of Software Quality [Krasner, 1998] which is a major component of the total cost of ownership of a piece of software.

The hot new term is “technical debt”, which was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a development approach or delivery schedule that’s expedient in the short term but that skips important steps, increases product complexity, decreases quality and is more costly in the long term.     Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive.   Determining which is which is problematic when technical debt is unseen until its too late.  The ability to take on debt safely, track debt, manage debt, and pay down the debt varies among different organizations.

Steve McConnell points out that there are 2 types of technical debt to consider.  The first type is incurred unintentionally (e.g. code defects) and likely unknowingly. The second type is incurred intentionally (e.g. release it NOW, to gain market share).  In the analogy, the main question becomes how long can one put off paying down the debt, and what is the burden of carrying it.  Once a debt is incurred there will be interest charges (debt service).  If the debt gets big enough, all company work will go into servicing the debt rather than other more productive activities (e.g. fixing all the bugs after premature release to make the product usable). Not all delayed work is technical debt – e.g. feature backlog, deferred features, cut features, and so on. These aren’t debt, because they don’t require interest payments.

Like financial debt, different companies have different philosophies about the usefulness of debt. Some companies want to avoid taking on any debt at all; others see debt as a useful tool and just want to know how to manage debt wisely.  In any case, the strategy is to make the debts explicit and trackable in the “debt tracking system”.  This is done just like problem and defect tracking.   A good approach to working down the debt is to take a specified development iteration and devote that to paying off high valued technical debt items, or carve out a small percentage of an iteration and devote that to retiring debt items (kinda like a minimum monthly payment). The more debt a project accumulates, the more a project’s rate of progress (i.e., velocity) will slow down. The goal is to keep the debt service at a reasonable level compared to a company’s other expenses and investments.

According to the the CRASH Report for the year 2011 the technical debt of the CAST Appmarq benchmarking repository shows an Average of $3.61 of Technical Debt per LOC, up from $2.82 the year before.   They state that the cost of fixing Technical Debt is a primary contributor to an application’s cost of ownership, and a significant driver of the high cost of IT.      http://www.castsoftware.com/products/appmarq

According to Capers Jones, technical debt only covers about 13% of the true costs of (software) quality, and it ignores canceled projects that are not even delivered. He claims therefore that technical debt is not suitable for economic analysis.

Will technical debt catch on, or is it just another fad to try and get executives’ attention in order to communicate the essential value of software decisions made over its useful lifetime.  Is technical debt just an agilist view of cost of quality?   I am betting that lots of papers will get written over the next few years on the topic, but how much useful data will be produced I do not know ?

What’s your opinion???  Have you experienced a discussion of technical debt in your organization???  If so, how would you describe that discussion?

There are many different stakeholders involved in the judgment of software (product) quality.  The most important quality views to consider are:

• From a commercial consumer perspective, the view of quality is value-based, or how much would you pay for the software, and does it provide good value for its cost.  This is usually a relative concept, where cost is often used as a surrogate for quality. One might believe that market forces would cause prices to reflect their value (or quality).  In software however this is rarely the case.
• In the transcendental view, as in beauty contests, the features of the product are compared to the perfect (impossible to achieve) software system.  Mentally constructing an idealized system with all possible features is usually quite difficult.
• In the manufacturing view conformance to requirements is paramount. This view assumes that the requirements are clearly stated and complete, and the product must conform. Any deviation from the requirements is regarded as a defect, and a good quality product contains fewer defects.   Unfortunately software is not a manufactured product, and so this view is often applied incorrectly.
• The user view assesses the fitness of the product for use. Whereas usability corresponds to the ease of use, fitness corresponds to how well a system can respond to user needs (functional or non-functional). A good quality product provides better user satisfaction.
• The internal product view judges the quality of a system by the quality of its components. A system would be judged on the quality of the code, its design, its architecture, etc.  This view is important for the long-term cost of ownership, e.g. to the maintenance group.
• The internal process view judges the quality of a system based on the quality of the process that produced it  (e.g. CMMI).   Theoretically a more mature process would routinely produce higher quality systems.
• The constraints view requires that the product and or process additionally meet identified and relevant standards. In many industries and organizations there are certain external and internal standards that must be complied with (e.g. FDA regulations).  A good quality product conforms to required standards of quality and development process (e.g. ISO 9000, 6 Sigma, etc.)

Trying to synthesize the concerns of all stakeholders to come up with a commonly held definition is difficult but necessary.    As developers we generally strive to create a software product that provides value (satisfaction) to its users, makes a profit (if sold) for our company, generates few serious complaints, and contributes in some way to the goals of humanity (or at least doesn’t do harm).

But the ground truth starts with an empirical perspective. In 1998, my late colleague, Watts Humphrey, noted that experienced software engineers inject about 100 defects per KSLOC (1000 lines of code).  That is 10% buggy code.  Typically, about 25 of these defects find their way into integration and systems test, at a cost of from 10 to 40 programmer hours each. Each of these 25 defects will cost (at least) several thousands of dollars to find, to repair, and to verify.

So now the obvious questions are why do so many bugs get injected and of what variety are they, and where did they come from?    What do you think?

Software is pervasive in the IT systems of modern society, but we are often unaware of its presence until problems arise.  Software is one the most important and yet one of the most economically challenging technologies of the current era.  As a purely intellectual product, it is among the most labor-intensive, complex, and error-prone technologies in human history.  Even though many successful software products and systems exist in the world today, an overall lack of attention to quality has also led to many problematic systems that don’t work right, as well as to many software projects that are late, over budget, or canceled.  In short, the quality of software should matter to us as professionals in order to enable the technological world we live in.  This blog will discuss the concepts, problems and solutions with respect to achieving high quality in modern software-driven systems.

Caveat – I need to state right up front that the opinions presented in this blog are my own, and do not necessarily reflect the opinions of the University of Texas at Austin.

Here is a little bit about my professional career in software, systems and IT, which I have been involved in for over 4 decades in various roles.    I started out my career in the early seventies as a practicing software engineer, and simultaneously, as a teacher of the art and skill of programming.  In the late seventies, I helped start software engineering degree programs at 2 major universities, while performing research in database engineering methodology.   In the early eighties, I had the opportunity to help create a multi company joint research lab (MCC), and then to initiate it’s advanced software technology research program, primarily serving as project leader for it’s empirical studies of professional programming project.   In the late eighties, I become the senior software technology officer in a large aerospace company, and through my affiliation with the CMU SEI, I was charged with raising all divisions of this company up the CMM ladder, which I did.   After a brief stint of starting up a new business unit of a major systems integration company, I established my own consulting company focused on helping organizations improve their software system development and management processes, and resultant system quality.   Over the last 20 years I have had the opportunity to help many different companies and organizations.  I have led over 60 organizational assessments in many different companies, business units and agencies.   All were well received.

As the Founder, former Chairman and now CTO of the UT Software Quality Institute (SQI), I was largely responsible for creating and shaping this software engineering educational outreach organization into a successful outreach business. I am the founder of the Austin Software Process Improvement Network.   I was also an Instructor for the American Society for Quality (ASQ) Certified Software Quality Engineer BOK training courses.   I was a member of the Board of Quality Examiners for the Austin Quality Award based on the Malcolm Baldrige National Quality Award. I am also known for my work on modeling the cost/benefits of software quality and reporting the ROI data for software process improvement programs, as well as, the reported results from the empirical studies of professional programmers that I did at MCC.   I have published over 55 papers, articles and book sections, and have spoken at many professional conferences and meetings.

In 1999, I became affiliated with the University of Texas at Austin, and now serve there in several roles.

• Senior Lecturer in the Software Engineering area where I teach undergraduate and graduate courses in programming, data structures, OOA/OOD, database engineering, software design, agile methods, software process improvement and software system measurement & metrics.
• Research Scientist, where I am engaged in a multiyear research program focused on Modeling and Forecasting of the Cost of Software Quality (CoSQ).   It turns out that the CoSQ model proposed by Dan Houston and myself in the 1990’s is now being used around the world as a basis for software quality consulting.
• Principle Investigator and Program Manager of the IV&V Evaluation Services Project
• Director of Industry Outreach Services for the UT Center for Advanced Research in Software Engineering (ARiSE) where I focus on helping UT ARiSE become a multi-disciplinary center of excellence whose goal is to become a world leader in software engineering, in terms of education, research and service. The UT ARiSE industry outreach program helps initiate and manage relationships with companies that seek collaborative research and technology transfer. Companies develop relationships with our faculty, researchers, and students to pursue a variety of projects.

 My current research interests include:

• Economic models of software engineering (cost of quality, ROI, technical debt)
• Empirical studies of software system engineering in realistic settings
• Models and metrics for software system quality
• The human factors of software engineering (e.g. teamwork models)
• Agile and lean development approaches
• Software engineering process improvement and best practices
• Interdisciplinary approaches to studying technology assisted aging problems

In this blog we will be discussing the state of affairs in the area of  IT/systems/software quality.   It turns out to be a more difficult subject than most professionals anticipate.