There is a popular quote used by many in the #NoEstimates community, that is sadly misinformed.
Those who have knowledge, don’t predict. Those who predict, don’t have knowledge. − Lao Tseu
This of course was from a 6th Century BC Chinese philosopher, who was not likely familiar with the notion of probability and statistics developed some 900 years later. The quoting and re-quoting of Lao Tseu as an example of why estimates can't be made brings to light one of the more troublesome aspects of our modern age.
The lack of understanding of basic probability and statistics when applied to human endeavors.
Or possibly the intentional ignorance of probability and statistics as it is applied to the development of software systems. I can't really say if it is for lack of understanding, lack of exposure, or just a simple intent to ignore.
But for any of those reasons and more, here's a starting point on how to actually become a member of the modern of statistical estimating community, once it is decided that is better than ignoring the basic knowledge needed to be a steward of other peoples money.
Here's some starting points in no particular order, other than that's how they came off the office book shelf.
- How Many Licks, or how to estimate damn near anything, Aaron Santos, Running Press, 2009. - this book needs to be read before any more discussion of estimating can take place. It's the basis of all discussion about estimating and forecasting. Without this basic understanding, conversation is going to be hard.
- Software Cost Estimating with COCOMO II, Barry Boehm, Chris Abts, Winsor Brown, Sunita Chulani, Bardford Clark, Ellis Horowitz, Ray Madachy, Donald Reifer, and Bert Steece. Prentice Hall, 2000. - some have suggested this is "old school" without having actually looked at the book, managed a non-trivial interdependent project, or had to formulate an Estimate At Completion before there is sufficient data from past performance to do so.
- Facts and Fallacies of Software Engineering, Robert Glass, Addison Wesley, 2004. - a mandatory read for anyone wanting to detect the BS in the unsubstantiated statements on twitter.
- Software Sizing and Estimating, Charles Symons, John Wiley & Sons, 1991. - software cost estimating is part of all business that writes software for money.
- Estimating Software-Intensive Systems, Projects, Products, and Processes, Richard Stutzke, Addison Wesley, 2005. - Software intensive systems include enterprise systems, real-time embedded systems and system-of-systems. Both need rigor when estimating cost, schedule, and performance.
- Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte-Carlo Simulation, Troy Magennis, 2011. Troy's book is one of the best for agile software project management.
- How to Think About Statistics, John Phillips, Freeman, 1996. A straight forward stats books, every high schooler should have read.
- Short-Term Forecasting, Mathematical and Statistical techniques for Industry, I.C.I. Monograph No. 2, 1964. This started is all, with the Box Jenkins algorithm.
- Probability Methods for Cost Uncertainty Analysis, Paul Garvey, CRC Press, 2000.
- How to Lie With Statistics, Darrell Huff,W. W. Norton, 1954.
- Introduction to Stochastic Models, Roe Goodman, Dover, 2006. - there are many books on stochastic modeling, this is an accessible one. All project work is a collection of dependent stochastic process. The INVEST notion of agile demands verification that all the work in the backlog is Independent of other work, independently and identically distributed in a statistical manner. This would be exceedingly rare on any non-trival project where integration is present.
- The Economics of Iterative Software Development: Steering Toward Better Business Results, Walker Royce, Kurt Bittner, Mile Perrow, Pearson Education, 2009. - Steering is the operative work here. Without a steering target, the control of the project is open loop. Closed Loop control is needed to arrive on or near the planned time, for on or near the planned cost, with or close to the needed capabilities. To do otherwise is to ignore the back principles of project management.
These are just a small sample of the information readily available at your local book store or through the mail. If you google "software cost estimating," (all in quotes) there will be 100's of more articles, papers, and web sites. As well tools for estimating software are used every single day in a variety of domains.
The Value at Risk is a starting point as well. Low value - this is defined by those providing the money, not by those doing the work, and low risk - this usually defined by those doing the work, not by those providing the money - at least in the domains we work. This Value at Risk, sets the tone. Low Value, Low Risk - and this is in absolutely no way an assessment of the relative value and risk - usually doesn't need much estimating.
Got a 6 week, 2 person database update project. Just do it. Got a 38 month, 400 person National Asset sofwtare project, probably so. Everything and anything in between needs to ask and answer that value at risk question before deciding.
So poor Mr. Tzu was sadly informed when he made his quote. As are those repeating it. In the 21 century
Those who have knowledge of probability, statistics, and the processes described by them can predict their future behaviour. Those without this knowledge, skills, or experience cannot.
