[TMMM] Ch 8 – Calling the Shot

Chapter 7: Why Did the Towers of Babel Fall?

How does one estimate?  Recall that back in Chapter 2 we developed the following ratio:

• 1/3 planning
• 1/6 coding
• 1/4 component test & early systems test
• 1/4 system test, all components in hand

It would be a mistake to estimate the coding first and then develop the rest of your estimate from that.  A miscalculation in the estimate of the coding can result in ridiculous estimates of the other components.

In the same way, estimation and performance data on a small project cannot be used to scale estimates for larger products.  For example, extrapolation of times for the 100m dash shows that a man can run a mile in under 3 minutes!

In fact, the effort equation can be described as:  effort = constant * (number of instructions) ^1.5

Portman’s Data

Teams only realize 50% of the working week as actual programming and debug time (machine downtime, higher-priority jobs, meetings, etc. take up the other 50%).  Unfortunately, estimates are usually made with an unrealistic assumption about the number of technical work hours per man-year.

Aron, Harr, and OS/360 Data

Projects that require fewer interactions between programmers result in higher productivity, and vice versa.

Compilers are 3 times harder than normal batch apps

Operating systems are 3 times harder than compilers

Corbatos Data

Productivity is constant in terms of elementary statements

Productivity is increased by up to 5x when a suitable higher-level language is used

Chapter 9: Ten Pounds in a Five Pound Sack >>