Selected Rules of Thumb in Software Engineering

BY MARKUS SPRUNCK

The following rules of thumb should be helpful to get quick effort estimations. They explain typical scenarios in software development projects and/or maintenance tasks. Collecting just some quotations is always dangerous - because of missing context information - but I tried here to select more likely true numbers. All this should motivate you to collect some own rules and indicators.

How Large is your Hidden Factory?

An important thing to understand about software engineering is: "If a software developer works hard - it doesn't mean that he/she is productive". About 40% of working time of a software developer is spend with rework, debugging and bug fixing. This time is also called the hidden factory.

I like the term hidden factory because a lot of managers and customers are not aware of it. Maybe this is the reason, why we see so many inefficient development organizations and teams these days. This is not in the curriculum of a standard MBA program. In Figure 1 the hidden factory from one typical investigation is depicted.

Figure 1: Sample for effort for productive development and rework [Wheeler96]

My personal observations indicate - that this distribution is true for most development project and/or maintenance teams.

Relative Cost for Fixing a Defect

It is also important to understand that the earlier a defect can be fixed the cheaper it will be. These values are very dependent from the context of development. For shrink wrap product development and/or embedded systems the cost may be significantly higher. An in-house web application could show cheaper fixing costs for a defect.

Figure 2: Relative cost for fixing a bug, dependent of the time of discovery [Gilb]

This graph leads us to the idea that methods to find defects early are worth their investment. One proven method to find defects earlier are code inspections and/or reviews in general. You may read The Best Code Review Tool is a Simple Ball Pen and a Listing on Paper! to get some motivation to do lightweight code reviews. But also requirement and design reviews are important as you can see in Figure 2.

Some General Rules

'Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.' [Boehm01]
'Current software projects spend about 40 to 50 percent of their effort on avoidable rework.' [Boehm01]
'About 80 percent of avoidable rework comes from 20 percent of the defects.' [Boehm01]
'About 80 percent of the defects come from 20 percent of the modules, and about half the modules are defect free.' [Boehm01] (aka Pareto principle)
'About 90 percent of the downtime comes from, at most, 10 percent of the defects.' [Boehm01]
'Peer reviews catch 60 percent of the defects.' [Boehm01]
'Perspective-based reviews catch 35 percent more defects than nondirected reviews.' [Boehm01]
'Disciplined personal practices can reduce defect introduction rates by up to 75 percent.' [Boehm01]
'About 40 to 50 percent of user programs contain nontrivial defects.' [Boehm01]
'More than 60% of the errors in a software product are committed during the design and less than 40% during coding.' [Bernstein05, page 47]
'Testing efforts consume 50% of development time and 20% of project cost. Regression testing halves the time and cost.' [Bernstein05, page 386]
'Only 60% of the features in a system are actually used in production.' [Bernstein05, page 249]
'When lines of Comments exceeded Lines of Code, code is hard to read.' [Bernstein05, page 363]

Recommendations

Collect some own numbers of your last projects and find your rules of thumb. “If you don't know history, you're doomed to repeat it.”
Compare these numbers with the rules of thumb from book, articles like this and web sources. Try to understand the reasons for contradictions. Rules of thumb are never true, in the best case they are consistent.

References

[Boehm01] Barry Boehm and Victor R. Basili; Software Defect Reduction Top 10 List; http://www.cs.umd.edu/projects/SoftEng/ESEG/papers/82.78.pdf
[Bernstein05] Lawrence Bernstein and C. M. Yuhas; Trustworthy Systems Through Quantitative Software Engineering; ISBN-13: 978-0471696919; Edition: 1; (Oct 19, 2005)
[Wheeler96] Wheeler 1996, Software inspection: an industry best practice; ISBN-13: 978-0818673405
[Gilb] Tom Gilb, Software Engineering Management, Daten der Standard Chartered Bank; http://www2.informatik.hu-berlin.de/~hs/Lehre/2004-WS_SWQS/20050126_Reviews.ppt

Google Sites

Report abuse