by Arlene Minkiewicz
| September 26, 2014
Here’s a conundrum. You are a software estimator responsible for helping the decision makers in your company determine what business to pursue and what business to steer clear of. You know, that to win profitable business, your company first needs to decide which opportunities are golden and which should be avoided. You also know, that at the point at which this decision needs to be made, there is very little information available to support a quality estimate. Add to this the fact that software estimation is hard at almost any stage. What’s an estimator to do?
I I think back to the takeaways from Fred Brooks’ tremendous book The Mythical Man Month. As software development professionals and software estimators we should all occasionally revisit this book because Brooks ‘observations, for the most part, still hold true. Our languages and development environments have become much more sophisticated; we develop software for mobile devices instead of mainframes; we’ve replaced rigidly sequenced software development phases with agile practices and paradigms. Despite the great strides we have made in addressing the accidental complexities of software development, we still get tripped up dealing with the essential complexity of crafting software solutions to increasingly challenging problems. This is what makes software estimation particularly difficult. Basically, Brooks’ point was that advances in software development technology only really improve productivity for parts of the development process. The pieces of software development that rely on invention and innovation continue to be challenges.
So back to the original question “what's an estimator to do?” The good news is that there are things you, the estimator, can do even in the early stages when rough order of magnitude(ROM) estimates are required to support bid/no-bid type decisions. First of all, as an experienced estimator you should be familiar not only with the accidental complexities associated with software development in your organization. You should also, through experience and data collection, have a good feel for the essential complexities associated with the types of software being developed.
Software estimation to support good decision-making should certainly not be done in a vacuum. It should be based on mature estimation practices that should be informed by data representative of software developed within your organization. Estimation models, whether commercial or home grown, are great tools to help guide the estimation process. But a fool with the tool is still a fool. A good software estimates should be final informed with data driven knowledge and a good understanding of both the accidental and essential complexities of the software project being considered.