Bugs should be obvious, but we say It's not a bug, it's a feature because often it isn't obvious. Watson Humphrey felt that we should use the term defect and not bug because most people don't take bugs seriously, so let's use the term defect instead.
So when does a defect become a defect?
- When quality assurance tells you that you have a defect?
- When product management says that it is a defect?
- When the customer says that it is a defect?
Incomplete and Inconsistent Requirementsbefore starting development, either because they don't know how to capture requirements properly or because they don't have resources capable of capturing complete requirements.
Incomplete (and inconsistent) requirements and unrealistic deadlines often force developers into making decisions about how to implement features. The end result is that developers are regularly told that they have defects in their code.
While this process is common, it is destructive. When requirements are under specified and inconsistent developers end up needing to perform serious rework. The rework will can require dramatic changes that will impact the architecture of the code.
The time required to find a work around (if it is possible) is rarely included in the project plan. Complicating matters is that the organizations that are reluctant to spend time creating requirements also tend to underestimate their projects. This puts tremendous pressure on the engineering department to deliver; this promotes the 5 worst practices in software development (see Stop It! No… really stop it.)
When poorly or undocumented systems require changes that are not specified we should call them change requests rather than defects.
Only 54% of Issues are Resolved by EngineersThe attitude that all defects must be resolved by the engineering department is severely misguided. Analysis by Capers Jones of over 18,000+ projects shows that only about 54% of all defects can be resolved by the engineers! (only the 3 highlighted rows below)
|Defect Role Category||Frequency||Role|
|Requirements defect||9.58%||BA/Product Management|
|Architecture or design defect||14.58%||Architect|
|Testing defect||15.42%||Quality Assurance|
|Documentation defect||6.25%||Technical Writer|
|Database defect||22.92%||Data base administrator|
This means that precious time will be wasted assigning issues to developers that they can not resolve. The time necessary to redirect the issue to the correct person is a major contributing factor to fire-fighting
Getting Control of the Defect ProcessBug Tracker Hell and How To Get Out!
requirements defect, once you identify issues that are caused by poor requirements it will shine the white hot light of shame onto the resources that are capturing your requirements.
Once you realize how many requirements defects exist in your system you can begin to inform senior management about the requirements problem.
- Not enough time is allocated to the requirements phase
- Unskilled people are capturing your requirements