It's Not A Bug, It's....

The page says a bug or defect is not defined by who names it, but by whether the code behaves differently from the requirements specification. It argues that many systems are under specified, so what gets called a defect is often really an undocumented feature or a change request.

Reading notes

#

• A defect exists only when code differs from the requirements specification.
• Many systems are under specified or not specified at all.
• Incomplete and inconsistent requirements, plus unrealistic deadlines, push developers into implementation decisions that later get labeled as defects.
• Poorly documented or undocumented changes should be treated as change requests rather than defects.
• Capers Jones’s analysis of 18,000+ projects is used to show that only about 54% of defects can be resolved by engineers.
• Defects come from different roles, including requirements, architecture, code, testing, documentation, database, and website.
• Assigning all issues to developers wastes time when the real source is elsewhere.
• Getting control of the defect process means categorizing defects correctly and tracking their different sources.
• Better requirements writing is presented as the best way to reduce fire-fighting.
• The page says organizations should check whether too little time is allocated to requirements or whether the people capturing requirements lack skill.
• If there is no documentation for a requirement, the author says to stand your ground when someone claims the code has a defect.