Top Five Causes of Poor Software Quality

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Causes of Poor Software Quality

Poor quality is not an inevitable attribute of software. It results from known causes. It can be predicted and controlled, but only if its causes are understood and addressed.

With more critical business processes being implemented in software, quality problems are a primary business risk. I’ll discuss five primary causes of poor software quality and how to mitigate their damaging effects using methods other than brute testing.

Lack of domain knowledge

Perhaps the greatest contributor to poor software quality is the unfortunate fact that most developers are not experts in the business domain served by their applications, be it telecommunications, banking, energy, supply chain, retail, or others.

Over time they will learn more about the domain, but much of this learning will come through correcting defects caused by their mistaken understanding of the functional requirements. The best way to mitigate this cause is to provide access to domain experts from the business, proactively train developers in the business domain, and conduct peer reviews with those possessing more domain experience.

Lack of technology knowledge

Most developers are proficient in several computer languages and technologies. However, modern multi-tier business applications are a complex tangle of many computer languages and different software platforms.

These tiers include user interface, business logic, and data management, and they may interact through middleware with enterprise resource systems and legacy applications written in archaic languages. Few developers know all of these languages and technologies, and their incorrect assumptions about how other technologies work is a prime source of the non-functional defects that cause damaging outages, data corruption, and security breaches during operation.

The best way to mitigate this cause is to cross-train developers in different application technologies, conduct peer reviews with developers working in other application tiers, and perform static and dynamic analyses of the code.

Unrealistic schedules

When developers are forced to sacrifice sound software development practices to ridiculous schedules the results are rarely good.

The few successful outcomes are based on heroics that are rarely repeated on future death marches. When working at breakneck pace, stressed developers make more mistakes and have less time to find them. The only way to mitigate these death march travesties is through enforcing strong project management practices. Controlling commitments through planning, tracking progress to identify problems, and controlling endless requirements changes are critical practices for providing a professional environment for software development.

Badly engineered software

Two-thirds or more of most software development activity involves changing or enhancing existing code. Studies have shown that half of the time spent modifying existing software is expended trying to figure out what is going on in the code.

Unnecessarily complex code is often impenetrable and modifying it leads to numerous mistakes and unanticipated negative side effects. These newly injected defects cause expensive rework and delayed releases. The best way to mitigate this cause is to re-factor critical portions of the code guided by information from architectural and static code analyses.

Poor acquisition practices

Most large multi-tier applications are built and maintained by distributed teams, some or all of whom may be outsourced from other companies. Consequently, the acquiring organization often has little visibility into or control over the quality of the software they are receiving.

For various reasons, CMMI levels have not always guaranteed high quality software deliveries. To mitigate the risks of quality problems in externally supplied software, acquiring managers should implement quality targets in their contracts and a strong quality assurance gate for delivered software.

Thoughts on the List

The first two causes distinguish between functional and non-functional quality problems, a critical distinction since non-functional defects are not detected as readily during test and their effects are frequently more devastating during operations.

The third and fourth causes have been perennial, although the fourth problem is exacerbated by the increase in technologies integrated into modern applications.

The final problem is not entirely new, but has grown in effect with growth in outsourcing and packaged software. Just missing this list but deserving of attention are breakdowns in coordination among distributed software teams, a cause that would make the top five in some environments.

In well run software organizations testing is not a defect detection activity. Rather, testing should merely verify that the software performs correctly under a wide range of operational conditions. By understanding and addressing the top five causes of defects, quality can be designed in from the start, substantially reducing both the 40% of project effort typically spent on rework and the risks to which software exposes business.

Dr. Bill Curtis is the SVP & Chief Scientist at CAST Software.