Building bugs in double-quick time
Never mind the quality, feel the speed
The first bug was a small insect caught in an early 1940s computer. Today bugs are very different in their nature, and fixing and removing defects in computer systems has become a long and labor-intensive process.
Software development project teams do little to help themselves, it seems. All too often, the focus of a software project will be on the "visible sides" of development: the functionality and user interface. Actually, errors in software requirements and software design documents are more frequent than errors in source code itself.
Not only are requirements and design errors more numerous, they are also more severe and more difficult to remove. Front-end errors in requirements and design cannot easily be found and removed with software testing, but instead need pre-test reviews and inspections. Yet there is rarely enough time set aside for that in the software build process.
Time to market seems always to take precedence over build quality, and developers are compensated accordingly. Few organizations reward good quality. All too often, the quality-conscious software engineer is accused of simply working too slowly.
Yet surveys show that the occurrence rate of bugs in the average organization is almost twice that found in best-of-breed shops. And evidence suggests that with improvement to both the occurrence rate of defects and the defect removal process itself, there is scope for a reduction by a factor of five in the number of defects actually delivered by the average IT shop.
It is that combination of high levels of potential defects and low levels of defect removal efficiency that contributes to the dominance of error-related work patterns in the software community.
More than twice as much effort is associated with defect removal than with actual product development. Too many people are involved in fixing too many errors. It is a crazy situation that simply would not be tolerated in the financial services markets, in retail or the automotive industry. Why should it be accepted in IT? There is a degree of waste and rework that seems to permeate the software development process, and it is unacceptable.
What is surprising is that almost all IT organizations now face either a shortage of labor or some arbitrary headcount cap, and almost all have not yet successfully attacked the inefficiency of the software development process.
Lone bugs are no longer the issue. It is rogue software development practices that are the real problem. It could be down to problems with the people or the process, the methods, or the tools. More likely, it is a combination of all four aspects that has been the cause of the runaway software development process, and it is going to take some fixing.
Related Research: Datamonitor, MarketWatch - Technology, Annual Subscription