Indy Code Camp Notes, Part 2

This is part of a four part series of notes I took at Indy Code Camp on May 16, 2009. This year’s Code Camp consisted of five tracks each with five sessions. Track topics were SharePoint, SilverLight and WPF, Data Access, MIX highlights, and best practices. These notes are from the sessions I attended.

These notes are in no way intended to replace attending one of these talks if you have the chance.

Improving Our Craft: A Discussion on Software Estimation

Presented By: Michael Eaton – Validus Solutions

Michael started his talk by tossing out some statistics about project success rates and defining some terms. He then moved on to discussing why we’re so bad at giving good estimates and wrapped up with some ideas for how to improve the estimates we do give. Unfortunately I wasn’t able to capture the exact stats but they were eye-opening to say the least in that in 2006, only 32% of projects were considered to be successful.

Terms

  • Estimate
    • Tentative evaluation or rough calculation
    • Preliminary calculation of cost
    • Initial judgement
  • Target
    • Statement of desirable objective
  • Commitment
    • A promise to deliver

Understanding Estimates

  • The challenge is to determine whether we are supposed to be estimating or projecting to hit a target. If we’re projecting to hit a target do we produce what was expected?
  • Estimates will by their nature, be wrong. We’re providing estimates not exactimates.
  • A good estimate is one that provides a clear enough view of the project reality to allow the project leadership to make good decisions regarding targets.

Why Are We So Bad?

  • Unknown problem domain
  • Vague, missing, or large requirements
  • We forget stuff
  • Overconfidence
  • Insufficient education or practice making estimates
  • Never given a chance to succeed (set-up for failure)

The Cone of Uncertainty

The Cone of Uncertainty states that the actual duration of a project can take up to four times as long or 1/4 as long as expected.

What Can We Do?

  • Stop giving off-the-cuff estimates
  • Communicate
  • Incorporate Agile practices
    • Iterations
    • Daily Stand-ups
  • Decompose the problem into smaller chunks and estimate the chunks
  • Let developers estimate their own tasks rather than having a manager or lead developer provide estimates for the team
  • Estimate end-to-end tasks
  • Learn from your mistakes
  • Keep a log of estimates and periodically review it
Advertisement