Bugs Kill Productivity and Schedule Accuracy 3
The title may seem obvious. Here is some hard data.
SD Times recently reported on a survey done by Forrester Research on the pernicious effects of bugs on development productivity. The developers and managers surveyed said they take an average of six days to resolve issues and they spend an average 3 out of every 10 hours working on various stages of troubleshooting, including initial investigation, documenting their findings, and resolving the problems.
The survey puts some data behind an intuitive sense (of gloom…) that many teams have about the problem.
For me, this is further evidence of why the practices of Extreme Programming (XP), especially Test-Driven Development (TDD), are so important. To a high degree, TDD ensures that the software is really working and that regressions are caught and fixed quickly. TDD also provides an unambiguous definition of “done”; do the automated tests pass? The feedback on which stories are really done tells the team its true velocity and hence how many story points will be finished by a given target date. Also, you spend far less unplanned and unpredictable time debugging problems.
Hence, productivity and schedule accuracy tend to be much better for XP teams. Over time, as the software grows in size and complexity, the automated test suite will keep delivering “dividends”, by continuing to catch regressions and by empowering the team to do the aggressive refactorings that are necessary to keep the software evolving to meet new requirements.
The SD Times article goes on to say that
... two-thirds of the responding managers indicated that a solution that reduced the time spent on resolving application problems would be of interest if it created significant efficiencies and improved quality.
The article concludes with a quote that automated testing is one solution. I agree. Just make sure it is the XP kind of automated testing.