The Cause of Poor Software Quality

March 27, 2012 — Posted by Al Shalloway

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

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, SAFe
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban