How to strike a balance between rapid value delivery and software quality (1/2)

Quality assurance - the poor relation of software development

Today, 75% of the IT budget is spent on maintenance and operational costs. This leaves only 25% of the budget available for creating value and meeting customer needs. In 2016, the Government Accountability Office, the audit, evaluation and investigative arm of the U.S. Congress, found that three-quarters of IT systems spent their entire budget on operations and maintenance. Identifying what goes wrong in software product development is more than necessary.

Many managers don't make software quality a top priority... a costly mistake. Think SaaqClic, Equifax, Boeing and its Max 7, the federal government's Phoenix payroll system... to name but a few. In addition to the costs associated with patching, it's the company's reputation that is compromised when quality problems occur.

More generally, lack of attention to quality contributes to systems that malfunction, or to software projects that are late, over budget or cancelled.

Yet 65% of customer and business interactions are digital (work, shopping, training, etc.). What's more, rapid digitization is accelerating global demand for software solutions. Many digital transformation initiatives fail because of poor software engineering and a lack of attention to quality issues.

How can we turn things around?

What causes poor software quality?

According to Bill Curtis, the main causes of poor software quality are :

1. Lack of domain knowledge, leading to poorly defined requirements.
2. Lack of technology knowledge
3. Unrealistic schedules due to poor estimating practices.
4. Poor software design due to lack of discipline, immature practices and less qualified personnel.
5. Poor acquisition practices
6. Lack of team communication and coordination.
7. Lack of useful metrics on the state of software quality.

Creating the quality-value amalgam

Value creation is an ambiguous concept, as there is no universal definition of value. In the field of digital transformation or information technology, I'd say it's transforming a need into products and services that bring value to all stakeholders. As ITIL reminds us in its principles:

"A service is a means of enabling the co-creation of value by facilitating the achievement of results requested by customers, without customers having to manage specific costs and risks."

Clearly, without customer involvement, suppliers will not be able to meet customer expectations. The definition and implementation of products and services is therefore a co-creation between customer and supplier.

Customers now regard quality as a fundamental measure of their perception/experience of a product or service. The result is this amalgam of quality and value. A kind of measurement.

Convincing management

Contrary to popular belief, companies don't have to choose between quality and productivity. Quality does not interfere with productivity; on the contrary, it enhances it. Quality is not an expense, but an investment. Doing it right the first time is far less expensive than reworking it.
By improving quality throughout a software product's development cycle, you'll reduce the time it takes to make corrections, and thereby increase productivity. This saved time can then be devoted to prevention.

First and foremost, it's important to make management aware of what software quality assurance is all about. Management must be motivated to change, not to follow trends. How can we convince management that investing in quality is a good business decision? With concrete elements:

• Assess the level of customer dissatisfaction, its impact and the costs (in man-days or $) of remedying it.
• Present a review of perpetual or recurring problems and assess the resources mobilized (and therefore their cost) to resolve them
• Train managers in QLA or software testing best practices (it's usually an eye-opener)
• Involve management in the implementation of a quality program

Presenting the direct losses due to non-quality remains the most convincing argument.

How much does non-quality cost?

Many of the costs associated with poor software quality are difficult to identify, like the tip of an iceberg. Being able to identify them will enable a company or organization to considerably reduce its operating costs.

Generally speaking, the visible part of these costs is :

• Customer-reported problems
• Service calls
• Lawsuits and warranty claims
• Quality group or coach costs
• Test team or tester costs
• Service interruptions

The portion of costs that is more difficult to identify/calculate:

- Research and problem-solving time.
- Projects that run into difficulties, are cancelled or abandoned
- Overtime not accounted for because we're in crisis mode.
- Work set aside (done for nothing) and reworked ("rework").
- Cyber-attacks that disrupt our operations or ransomware.
- Staff recruitment or turnover problems.
- Poor collaboration or working in silos
- Poor planning or estimating
- Poor return on investment (ROI).
- Astronomical costs of maintaining or upgrading systems.
- Lack of best practices and quality standards
- Lost market opportunities
- Time spent understanding complex code
- Technical debt
- Poor-quality data

-> Non-quality costs are all costs that could be avoided if the product were right the first time.

The classic model for calculating non-quality costs is as follows:

Control costs:
These are the costs incurred to detect anomalies.
Ex. reviews, audit, TU, TI, TS, approvals, team meetings, etc.

Cost of internal corrections :
These are the costs incurred to correct anomalies before the system or software is deployed in the operational environment.
E.g. redone work, waste, overtime, etc.

External correction costs:
These are the costs incurred to correct anomalies when the system or software is in production and being used by customers.
Ex. lawsuits, de-installation/installation, service calls etc.

Flower S. proposes in his book "Software Failure: Management Failure" to extend the model by adding the whole aspect of management costs associated with the three categories of the classic model. This proposal reflects more specifically the peculiarities of software development than those of manufacturing. The avowed aim is to arrive at a cost as close to reality as possible.

Quality control management costs
Typical management costs for preparation and quality controls.
E.g. cost of periodically updating the project plan and quality plan.

Cost of managing internal anomalies
All contingency costs in terms of project risks, schedule and budget.
E.g. underestimation of resource requirements or additional costs for subcontracting etc.

External contingency costs
All contingency costs incurred after the software is released.
Ex. Penalties paid for delays or damages due to mismanagement.

Another proposed extension of the model includes the costs of technical debt and cybersecurity. Two important categories in the world of digital transformation.

Cost due to technical debt:
Represents the effort required to resolve problems that remain in the code when an application/system/software is released.
Intentional - code refactoring
Unintentional - the bug log/backlog or latent bugs.

Cybersecurity costs :
Represents all costs related to data theft, cyber attacks (intrusion), cyber crime, which in extreme cases can lead to company bankruptcy.

Some common mistakes to avoid!

1. Looking for perfection in numbers.
   In a short space of time, it's possible to produce an estimate of 85%. Increasing accuracy to 95% can be very time-consuming and expensive.
2. Avoid endless discussions to position costs (good category).
   It's just a question of being consistent to enable comparisons over time.
3. Try to reduce quality costs to zero.
   It's normal for the total cost of a project to increase as you try to reduce non-quality costs.

Conclusion

According to the CAST analysis repository, the average cost of technical debt is $3.61 per line of code. This cost can be as high as $5.45 per line of code, depending on the language used.
On average, a software developer generates 100 to 150 errors for every thousand (1000) lines of code.
According to Grady Booch, in 2005 he estimated that around 35 billion new lines of code were written worldwide every year. Today, in 2023, we're much closer to 100 billion new lines of code per year worldwide.
A medium-sized application (less than a million lines of code) comprises 200 to 300 components on average.
According to the Meta Group, up to 80% of problems are attributed to a poor understanding of requirements.
On average, software testing costs 40% to 75% of the total cost of a project.
Non-quality is estimated to account for 30% to 70% of total project costs.

As you can see, quality is better thought of first,

In our next article on the same subject, we'll look at how to define quality objectives, focus on prevention, improve processes and introduce continuous improvement.

To find out more :