This is the first of a three part series:
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:
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:
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:
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