This is the first of a three part series:

1. The Cause of Poor Software Quality
2. Quantifying the Return from Improving Software Quality
3. How To Improve the Quality of Your Software While Improving Your Time-To-Market

The Cause of Poor Software Quality

We have seen many patterns that result in poor software quality. It is important to understand the root causes of poor quality in order to be able to efficiently improve your methods in order to improve the quality of your software. Serendipitously, we also find that improving quality improves time-to-market of our most valuable features.

We consider defects to be: bugs, features that weren't asked for, features that were asked for but are of little value, and complexity in your code that is higher than need be (e.g., overbuilt frameworks). Our experience is that one can expect a reduction in defects of 50-80% by some basic quality improvement methods which will be discussed in the third blog. The time frame for full improvement and achieving sustainability is typically 1-3 years, but some significant improvement should occur immediately.

Our experience at the larger scale (>150 folks) is that poor quality mostly results from the following:

1. Too many requirements being analyzed prior to work taking place (waterfall analysis)
2. Lack of acceptance criteria for all requirements
3. Poor coding methods
4. Lack of automated testing
5. Lack of test-first development methods
6. Poor integration methods (too much big integration at end)
7. Thrashing between teams as they try to integrate their work
8. Little coordination of how work is given to teams but expecting teams to self-coordinate
9. Lack of alignment across the organization

Sounds like a long list. But the root cause of all of these things boils down to two main, core process issues – working on too many things and doing work in the wrong order – and one technical issue – not understanding how to write code incrementally.

All of these contribute to delays that literally cause extra work to take place.

These include delays from:

• getting requirements until they are used
• misunderstanding a requirement until that misunderstanding is detected
• writing a bug until it is detected
• when two teams get out of synch until this is detected (typically in integration)
• needing a question answered until the required person is available
• making a design decision until validating it

These delays occur because people are working on too many things. This often occurs because the business stakeholders demand more and more be done not enough real work (that is, delivered, valuable features) is being produced. Ironically, these delays typically create as much or more work to be done as the real work. This additional work shows up as:

• redoing requirements
• time spent finding bugs (fixing bugs does not take nearly as long as finding them)
• teams thrashing as they try to integrate
• working on the wrong things because the right person to ask was not available
• bugs
• features that are not really useful (or wouldn't have been selected had their true value been known)
• frameworks or complex code that is more complex than is needed

Improving the quality of your software and reducing the delays in your process are not achieved just by technical practices. See our Extended XP Engineering Practices page for how they can help. However, Lean-Agile methods in general, be it Scrum, Kanban or a hybrid approach will reduce delays in your process and improve quality as well – and probably make it easier to adopt some of the XP practices that are very valuable. This will be discussed in the third blog of this series – "How To Improve the Quality of Your Software."

Alan Shalloway
CEO, Net Objectives