Putting Round Pegs into Square Holes: Software Project Estimation

Bean counters and programmers

No, it's not a new song by Stone Temple Pilots.  It's a dilemna that puts two diametrically opposed brain chunks in direct contact with one-another, and it rarely turns out well.  Rarely.  I won't say "never", but it's as close to "never" as calculating the Limit as X approaches zero (remember that crap from high school Calculus?).

Why is it such a problem?

Here's why:

Bean Counters work with metrics.  Things that can be defined, bounded, measured and compared.  Units take X amount of time to complete, so Y quantity of X will require Z amount of time to complete.  Easy.  Relatively speaking.  Metric assessments and metric-based forecasting are square holes.

Programmers with in the ethereal.  Solving problems incrementally.  First is the BIG problem (the project or over-arching task).  Then comes the next layer down, which is choosing a platform, language, medium, etc.  Then comes the next layer down, which is choosing the resources and identifying availability. Then comes the (gulp!) architecture and design phase, which, let's face it: is bordering on the "artistic" side more than the technical side.  Then comes the execution phase: writing code, and alpha testing it.  Then comes the beta testing or dog-fooding phase.  Then comes the public or customer test phase.  Reading back through this paragraph, it might become clear that few of these are "well defined" or "bounded" units of anything.  Even worse: they tend to degrade into less-defined entities with barely any bounds at all, as you approach the point of completion.

Skittles-eating, Mountain Dew swilling, Hot Pockets chomping, video game cranking programmers are the round pegs.  Even worse: they're not even round, not even elliptical, but more of a blob.

Sure, there are books and articles and whitepapers galore, which attempt to apply mathematical concepts to herd this whild team of blind three-legged cats into a lock-step battallion of uniform-wearing solders of productivity.  Clever, huh?  I have my moments (usually after a strong cup of coffee or beer).  It's bullshit.  Pure bullshit.  I've studied a wide-ranging smattering of CMMI and SDLC and ITIL framework subject matter, but almost all of it takes the same view of programming as bean counters take.  The point of failure in all of these is HUMANS.  HUMANS are not well-defined units of anything.  You can measure biometrics and physical aspects of humans, but measureing potential output is damn near impossible.  However….

What works best?  Humans.

The best tool for assessing potential human output is another human.  But that other human must possess two crucial characteristics in order for this to work at all:

1. Experience with the task environment
2. Familiarity with the Human being assessed

Experience is a must.  You have to really understand a significant depth of the project, the tasks, the platforms, the languages, the technologies in which the project will operate and the user environment (you know: the folks that will do their absolute best to break your final product).

Familiarity is the catalyst.  The human who assesses the potential of programmers has to know those programmers very well.  Beyond their ability to answer on-the-spot interview questions like "what would you do if…" or "what's wrong with this piece of program code?", you have to know their personal habits.  Do they shoot the shit all day?  Do they make a lot of mistakes and how do they recover from them?  Do they attempt to recover or blame something else?  Are they a team player?  Do they disrupt others?  Are they a poison pill to the team?  Do they foster cohesion and mentor others?  Are they leaned upon to mentor others (taking away time they have to do their own work)?

Familiarity is damn near impossible to spin-up on demand.  It's not a surge-capacity reactive capability.  You can't just grab a MBA with PMP and CMMI certs and plug them into an existing team and expect them to shit out accurate estimates.  It's not going to happen.  It takes time.

All of the literature I've read from the various process certification groups barely touches on this.  It mentions it, but then moves on to the next metric assessment, like missing a few blades of grass when mowing the lawn.

If you're involved in a software-based start-up, you should insist that the project management team includes at least one person who is familiar with at least a majority of the key developers on the project.  If they really want the project to succeed they will only be too happy to oblige.  If they scoff at this then they're not really looking at long-term success, but simply short-term gain.

Humans.  Experience.  Familiarity.