Are We Going To Make It? Software Estimation Secrets of the Stars

by Ed Schwarz

Are We Going To Make It? Once we start delivering a project at Gorilla Logic, this is the metric we focus on — the one that counts. “Make it” means deliver the working system, on-time and on-budget.

Because Shit Happens, the question cannot usually be answered definitively (at least in the affirmative) until late in the delivery. On the other hand, saying “I dunno” and leaving it at that would put real pressure on our marketing team to keep finding new customers. So for most of the lifetime of a delivery, we need to offer an educated opinion.

In order to even ask the question, you need to have at least some idea of what “the working system”, “on-time”, and “on-budget” mean. As hired guns, at Gorilla we’re generally given some idea of what “the working system” means, leaving “on-time” and “on-budget”. These two are generally an alchemic admixture of guessing, wishing, and estimating. Being mercenaries, our dispassion helps us temper our wishful thinking, leaving us with the much-more-reliable guessing and estimation.

While guessing has certainly been the basis for many great breakthroughs over the years, we generally prefer to use it only as a last resort. Admittedly, the track record of “successful” tech deliveries may seem like a slim improvement over flipping a coin, but the “error bars” tend to be a lot bigger when guessing is the major tactic. See above reference to the marketing team/new customers.

Thus, whenever possible, we try to do an estimate of the time and resources needed to deliver a project. In an industry often slighted for a drab, bits-and-bytes, pocket-protected, literal-minded culture, this is one area where a laugh-a-minute ethos is celebrated and scatalogical references to the source of figures is commonplace.

As with the “commedia dell’arte” of the Italian renaissance, certain standard tropes are often recycled to suit the occasion. In estimating, we often refer to these as “top-down” and “bottoms-up”. Believe it or not, these are simple single-entendres.

“Top-down” is where the estimator imagines herself as seeing the overall delivery as if from on-high, where the large-scale structure can be seen free from distracting detail, with the wise, sophisticated, and benevolent gaze of a goddess. This is a typical state of mind for most of our team, so it’s really quite easy. From this vantage point, an overall feel for how-big, how-long, and how-much can be discerned by one with the Right Experience.

“Bottoms-up” is where the estimator works completely through the scope — the description of “the working system” — and tries to decompose it into a list of component parts which are small enough to estimate in quick-and-dirty way. Each component is then estimated and the overall effort is added up to a quicker-and-dirtier total. Since the estimator will of course not think of every single thing, bottoms-up estimates are by definition low. [Attempting to correct for this by padding the bottoms-up estimate is discussed above, look for “guessing”.]

At Gorilla Logic we generally combine the two approaches and try to come up with an estimate that makes sense from both the top and bottom perspectives. If one of them just doesn’t make sense from the other perspective it’s time to think harder.

So, are we going to make it? I dunno. What I can tell you is that no estimate is going to be correct — just closer. No estimator is prescient — just more experienced. And when you’re done, you just have an estimate — the Shit hasn’t even Happened yet.

What does help, unquestionably, is multiple estimates from multiple experienced estimators. We’ve seen over and over that this produces more realistic, more transparent, more robust estimates for projects large and small. At least get a bottoms-up and a top-down from someone who has led successful deliveries. Two is even better. Seem like a lot of work? Just a few minutes of thinking about the impact of getting things right — or wrong — at this stage should make things clearer.