How to Estimate Software Development

There is a famous quote used by many in the #NoEstimates community that is sadly misinformed.

Those who know don't predict. Those who predict don't know. ? Lao Tzu

Of course, this was from a Chinese philosopher in the 6th Century BC, 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.

More understanding of basic probability and statistics is needed when applied to human endeavors.

Or possibly intentional ignorance of probability and statistics as they are applied to developing software systems. I can't say if it is a lack of understanding, exposure, or just a simple intent to ignore.?

But for any of those reasons and more, here's a starting point on how to become a member of the modern statistical estimating community once it is decided that it is better than ignoring the basic knowledge needed to be a steward of other people's money.

Here are some starting points in no particular order other than that's how they came off the office bookshelf.

• How Many Licks, or how to estimate damn near anything, Aaron Santos, Running Press, 2009. - this book must be read before any more estimating discussion can occur. It's the basis of all discussions about estimating and forecasting. Without this basic understanding, a conversation is going to be complicated.
• Software Cost Estimating with COCOMO II,?Barry Boehm, Chris Abts, Winsor Brown, Sunita Chulani, Bradford Clark, Ellis Horowitz, Ray Madachy, Donald Reifer, and Bert Steece. Prentice Hall, 2000. - some have suggested this is "old school" without having 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 B.S. in the unsubstantiated statements on Twitter.
• Software Sizing and Estimating, Charles Symons, John Wiley & Sons, 1991. - Software cost estimation is part of all businesses that write software for money.
• They estimate 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. It's a straightforward stats book every high schooler should have read.
• Short-Term Forecasting, Mathematical and Statistical Techniques for Industry, I.C.I. Monograph No. 2, 1964. This started with the Box Jenkins algorithm.
• Probability Methods for Cost Uncertainty Analysis, Paul Garvey, C.R.C. 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 processes. The INVEST notion of agile demands verification that all the work in the backlog is independent of other work and independently and identically distributed statistically. This would be exceedingly rare on any non-trivial 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 an open loop. Closed Loop control is needed to arrive on or near the planned time, on or near the scheduled cost, with or near the required capabilities. To do otherwise is to ignore the back principles of project management.?

These are just a tiny sample of the information readily available at your local bookstore or through the mail. You will find hundreds of more articles, papers, and websites if you Google "software cost estimating" (all in quotes). Tools for estimating software are also used every single day in a variety of domains.?

The?Value at Risk is a starting point as well. Low value is usually defined by those providing the money, not by those doing the work—at least in the domains we work in. This?Value at Risk?sets the tone. Low Value and low Risk—and this is in absolutely no way an assessment of the relative value and risk—usually don't need much estimating.

I have a 6-week, 2-person database update project. Could you do it? I have a 38-month, 400-person?National Asset?Software project. Everything and anything in between needs to ask and answer that?value-at-risk?question before deciding.?

Mr. Tzu was sadly informed when he made his quote. As are those repeating it, in the 21 century

Those who know probability, statistics, and the processes they describe can predict their future behavior. Those without this knowledge, skills, or experience cannot.