Monthly Archives: September 2011

Quality saves time and money!


In software projects quality saves time and money!.   

This principle is based on the observation that one of the most time consuming activity is rework. The rework arises from changes in requirements, change in design, or debugging. The single biggest activity of building software is debugging and correcting code that doesn’t work properly. Following my experience this activity account for about half of the time spent on development. Think at what you really do when you code, generally the time spent in writing production code is ridiculous compared to the time spent at debugging, fixing infrastructure issues, reading code, fixing bugs…

Therefore, the most obvious method to reduce our development cost is to improve the quality of the product and decrease the amount of time spent debugging and reworking our software. This analysis is confirmed by external field data. In a review of 50 development projects involving over 400 work-years of effort and almost 3 million lines of code, a study at NASA’s Software Engineering Laboratory found that increased quality assurance was associated with decreased error rate but did not increase overall development cost. Statistical analysis conducted at IBM found that software projects with the lowest levels of defects had the shortest development schedules and the highest development productivity. They explained their findings by staying that software defect removal is actually the most expensive and time-consuming form of work for software (Jones, Capers 2000: “Software Assessments, Benchmarks, and Best Practices.” Addison-Wesley).

Because the duration at which a software defect stays in a program is directly correlated with the cost of fixing it, quality practices should focus on solutions that enable to remove and/or detect errors as soon as possible in each stage of the project lifecycle. Indeed other studies have proven that one of the most important cost factors is the time in which errors are found. The longer the defect stays in the software production chain, the more damage it causes further down the chain. Since requirements are done first, requirements defects have the potential to be in the system longer and to be more expensive. Defects inserted into the software upstream also tend to have broader effects than those inserted further downstream.


Average Cost of Fixing Defects Based on When They’re Introduced and Detected

Time Detected 
Time Introduced  Requirements  Architecture  Construction System Test Post-Release
Requirements 1 3 5-10 10 10-100
Architecture 1 10 15 25-100
Construction 1 10 10-25

 

Based on book “Code Complete” and studies* -> Fagan 1976; Leffingwell 1997; Willis et al. 1998; Grady 1999; Shull et al. 2002; Boehm and Turner 2004.