Theoretical vs Empirical Estimation of Software Development Effort

Lean thinking tells us that any expenditure of resources that does not create value for the customer is waste. If you could accurately tell your partners when your project would be complete, that would probably be incredibly valuable to them. So why, then, do some people consider it wasteful to have developers estimate?

Theoretical Estimation

Most software estimation activities that I’ve seen in my career are what I’d consider to be theoretical estimation. This includes poker planning, t-shirt sizing, Fibonnaci sizing, etc. A few concerns I have with these approaches are:

  • You don’t know what you don’t know. You really can’t estimate what you don’t know.
  • Each card estimate is basically pulled out of thin air.
  • Studies have shown that even when we are 90% sure about the amount of effort that something will require, we’re wrong about it 60-70% of the time.

Card estimation doesn’t provide value because it’s inaccurate, plain and simple. In all of these techniques, you’re literally making up numbers.  Wrong numbers.

The activity of estimating itself is waste, but even more than that you’re going to break trust with your partners when reality doesn’t match your estimates. When that happens, and it probably will, all you can say is “Sorry, I’ll try to guess better next time.”

I don’t know about you, but I don’t want to work this way anymore.

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
— Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid

Empirical Estimation

How can we get away from making up numbers, then?  You have options, but I’m going to briefly describe a pretty light weight approach that I’ve seen work well for a few different teams I’ve coached.

Small Story Cards

You need to be working in small slices.  You should be doing this for a host of other reasons, but, it’s particularly important if you’re going to move away from having developers estimating.

If all of your cards are “Small”, then you can just count the number of things that were completed.  What you’ll find is that you’ll get  about the same number of things done per week regardless of their size.  In other words, you’ll get 5 cards done per week.  It doesn’t matter if you estimate the size of the cards or not, you’ll still get the same 5 cards done.  It averages out.  This also puts a positive pressure on slicing small, which is a Good Thing.

Of course all the other rules of story card slicing still apply.  Don’t overslice your cards down into technical tasks.  All of your cards should still show demonstrable progress.  Always ask yourself, “How will I demo this card to the business?”

Metrics

A couple of metrics that you’ll want to keep track of are your card cycle time time and the growth rate of cards for your project.

Your card cycle time is the entire time that it’s actively being worked on.  This begins when you do your story card meeting with your product owner.  In a perfect world it would end after the feature is deployed to production.  In practice, however, sometimes it makes more sense to consider the card done when the card is accepted by your partners/stakeholders.

Card growth is another important metric to track as it affects your projections.  Based on the rate at which cards are being discovered (growth) and the rate at which cards are being completed we can project when we will complete some subset of work.

So, where does this leave you?

  • Team spends close to 0 time estimating.
  • Project managers have a much more active role in estimation.
  • Team is focused on finding the smallest slices that will deliver demonstrable value
    • Small slices mean more options for the business (ability to pivot and defer less valuable work).
    • Small slices increase team morale (sense of completion).
    • Small slices lead to higher quality code (narrower focus by the team).
  • Estimates are based on facts rather than the opinions of team members.
  • Increased transparency with your partners/customers.

This certainly isn’t the only way to run a team, but, I think it’s underused in comparison to a lot of the more opinion based estimation techniques I see in use.  I’d be curious to hear if anyone else has any experience with other techniques that base estimation on empirical data.

Hacking a HexBug Robot

I found one of these little HEXBUG Hexbug Spider (colors may vary) on Amazon and thought it might be fun to try and hook an Arduino up to it.  It’s about the size of a fist and is controlled by an infrared remote control.

The robot’s movement is controlled by two small servos .  The first servo causes the top of the robot to rotate 360 degrees without moving the feet.  The second servo causes the legs to move.  The legs are mechanically linked to the top of the robot in such a way that the robot will always walk in the direction that the top of the robot is facing.

Here’s a video of my hacked HexBug in action:

After opening up the robot I was able to use a multimeter to probe the leads running up to the motors and determine that they’re operating at about 3.3v.  Since the Arduino Nano’s digital IO pins are 3.3v when high it made this a really simple project.

Parts List:

Wiring Schematic:

SpiderBotSchematic

Note that the RXD line on the Bluetooth Shield is connect to TXD on the arduino, and TX goes to RX. I wasn’t able to pair with the device for quite some time, and eventually the person I was pairing with figured out I wired that up backwards.

The code I wrote to control everything is available on GitHub.

Traffic Light Build Indicator

Continuous integration is great, but it’s only as effective as the visibility of the build status.  You can use things like email notifications or Hudson Tray Tracker to help increase the visibility, but I wanted something physical that could radiate the current build status.  Something everyone could see; even while you’re grabbing a cup of coffee.  So, I decided to try and make a traffic light build indicator.

Traffic Light

Continue reading

Comments are not the Goal

I used to think that writing more comments increased the readability of my code, but I’ve come to realize that comments frequently hurt readability. That might sound a little trollish, but here’s why I think it’s true:

  • Comments allow you to stop refactoring prematurely.
  • Comments aren’t kept up to date.  It’s really easy for this to happen because the association between a comment and the related code is very weak.
  • Comments that explain what code is doing are a DRY violation.  Your code should do that.
  • Frivolous commenting devalues your meaningful comments.  Your reader’s attention is a scarce resource – don’t waste it!

So, in my mind, the question really becomes “What is the best way to make this code easier to understand?” Continue reading

FireIFrame – Extending Firebug to Simplify Working with Frames

The Trouble with IFrames and Firebug

I’m a huge fan of Firebug.  I tend to write most of my UI-centric Javascript right in the Firebug console so that I can run it and immediately see the results.  After I’m satisfied with the code I’ve written I’ll cut it out of Firebug’s console and paste it into its permanent home.  This probably isn’t the most efficient workflow, but it works well for me because it provides really fast feedback. Continue reading

Baby’s First Foods

I’ve been playing around with Windows Phone development quite a bit lately.  I’m currently getting ready to submit my first application to the marketplace – “Baby’s First Foods”.

Babies under 1 year old can only eat certain foods depending on their age.  Each month new foods become available to the child.  It’s hard to keep track of what foods your child is ready for and what foods should be avoided. That’s the problem my app is trying to address.
Continue reading