The #NoEstimates movement appears to be based on a 27 year old report† that provides examples of FORTRAN and PASCAL programs as the basis on which estimates is done.
A lot has happend since 1987. For a short crtiique on the Software Crisis report - which is referenced in the #NoEstimates argument, see "There is No Software Engineering Crisis."
- Parametric modeling tools - the structure of software projects are constrained by the external structures of their components. These can be parameterized for estimating purposes.
- COCOMO - is an example of a parametic estimating tool. There are several others.
- Reference Class Forecasting models, have been developed as the result of overruns and disasters in many areas, including SWDev. But now we know and we know better not to succumb to all the biases discovered in the past.
- Monte Carlo Simulation, using Reference Class Forecasting, there as simple and cheap tools, http://www.riskamp.com/ for example. For $125.00 all the handwaving around forecasting cost, schedule, and other project variables can be modeled with ease.
- Object Oriented Programming - old news but no more debugging of FORTRAN "Unnamed COMMON" overwriting floating point numbers!!
- Component Based Software, where we can buy parts and assemble them.
- SOA and CORBA (TIBCO) where ETL and Enterprise Bus are the part of the Enterprise Architecture. Stop writing application code and start writing scripts to integrate. BTW the example of having developers write database apps for what is essentially a warehousing app, has missed the COTS, component based solutions bus.
- FPA, while a bit long in the tooth, but idea is still valid.
- Databases of Reference Classes
- The Web and Web components, same as above.
- CORBA, same as above.
- All the web based languages
- All the runtime interpretative languages with built in debuggers, rather compiled code with stop dead runtime debugging.
- ERP and COTS products and components, with out of the box functions that remove the need to write any code. Configure the system, sure. Write some scripting code ABAP e.g., but no coding in the developer sense.
- Software as a Service, where you can buy the solution. That was unheard of in 1986 and 1987.
- DevOps, another unheard idea back then.
- Open Source and Reuse
1000's of research and practicum books and papers on how to estimate software projects have be published. Maybe it's time to catch up with the 21st Century approach of estimating the time, cost, and capabilities needed to deliver value for those paying for our work. These approaches answer the mail in the 1987 report, along with the much referenced NATO Software Crisis report published in 1986.
While estimates have always been needed to make decisions in the paradigm of Microeconomics of software development, the techniques, tools, and data have improved dramatically in the last 27 years. Let's acknowledge that and start taking advantage of the efforts to improve our lot in life of being good stewards of other people's money. And when we hear #Noestimates can be used to forecast completion times and costs at the end, test that idea with activities in the Baloney Claims checklist.
————————————
† #NoEstimates is an approach to software development that arose from the observation that large amounts of time were spent over the years in estimating and improving those estimates, but we see no value from that investment. Indeed, according to scholars Conte, Dunmore and Shens [1] a good estimate is one that is within 25% of the actual cost, 75% of the time. in http://www.mystes.fi/agile2014/
As a small aside, that's not what the statement actually says in the context of statistical estimating. It says there is a 75% confidence that there will be on overage of 25% which needs to be covered with management reserve for 25% to protect the budget. Since all project work is probabilistic, uncertainty is both naturally occurring and event based. Event based uncertainty can be reduced by spending money. This is a core concept of Agile development. Do small things to discover what will and won't work. Naturally occurring uncertainty, can only be handled with margin. In this statement - remember it's 27 years old - there is a likelihood that a 25% management reserve will be needed 25% of the time there is a project estimate produced. If you know that ahead of time, it's won't be a disappointment when it occurs 25% of the time.
This is standard best management practice in mature organizations. In some domains, it's mandatory to have Management Reserve built from Monte Carlo Simulations using Reference Classes of past performance.
