John D. Mitchell's Blog

Use less milk?

My little girl has this habit of pouring way too much milk into her bowl of cereal. Then, she whines and complains when we tell her to drink up the extra milk after the cereal is gone so it doesn't go to waste. Yesterday, she got quite snippy when I dared to suggest that she try pouring less milk into the bowl.

Gee, she sounds like a lot of managers and developers of software.

Though, to be more precise, in most software situations, it's not that they pour too much milk but, rather the converse: trying to eat way too much cereal for the given amount of milk. Of course, it gets even worse when we're asked to eat random weeds from the edge of the parking lot instead of cereal because the powers–that–be misheard some "guru" talking about the miraculous recuperative abilities of mountain goats who eat nothing but weeds.

In terms of software estimates, why are we, as an industry, so far off? Is it merely incompetence or perhaps fibbing to say what the suits want to hear or are there more subtle things going on, too? I think it's exactly the same problem that my little girl has... She can see the surface of a pile of cereal in her bowl and as she pours the milk, she sees the milk run off the surface and disappear, by the time she sees the milk level come up towards the surface of the cereal, it's too late.

Now, some folks might say to eat more, smaller bowls so you don't run into that milk hiding problem (which is related to the burning your mouth on the hot sauce hiding under the cool layer of cheese on your pizza :-). Others might advocate pouring some amount of milk into the bowl first and then pour the cereal to match. Anal-retentive types might do a myriad of studies (i.e., waste a lot of milk and cereal) to figure out some magical metric by which to precisely predict the proper amount of milk to use for the average cereal according to the preferences of some imaginary average person.

Me, I like an adaptive approach: Pour some cereal, pour some milk, mix it all up, and taste it. If there's too much milk, add a small amount of cereal. If there's too much cereal, pour a wee bit more milk. If it's exactly right, look for the Candid Camera folks (especially if I used up the last of the cereal and milk simultaneously :-). Gee, for some reason, this tastes the same as another process.

Bon apetit!

Comments

• I've seen the same problem time after time again. The devil is in the details. Project managers or analysts don't have enough time to give detailed research into problems is a large part of the problem. Stir in some politics; people have deadlines they nod their heads to when their managers tell them they must meet. Don't forget about pleasing a client on a certain date if you're a contractor...think you'll win the bid if the competition puts a date four months ahead of you? Smash on some ERP consultants promising the world to get their foot in the door and wallets fat from comission and...there's a lot of forces at work here. There are always unforseen circumstances too (what do you mean that offsite location isn't behind our firewall? why are they special?), but those in my opinion are the most innocents of misestimates.

  Posted by: phlogistic on February 17, 2005 at 11:52 AM

• Another argument one can hear often is that software development is still more art and craftsmanship than true engineering and therefore is much harder to plan and estimate.
  There is merit to that claim, but if you look at craftsmen (plumbers, painters, pool builders, gardeners..) , they basically finish the job roughly on time and with no or little overruns. You can probably be off 5-10% in money, time and expectations with your home improvement project but never 60-100% off typical for a software one.
  If you are putting up an addtion to your house and it costs twice as much as estimated and collapses under its own weight, you see the guy in court. But if it is software, consultants just shrug off and you will try to do the same thing in .NET next year ;-)

  Posted by: mgarber on February 18, 2005 at 06:37 AM

• John, once again you've hit it on the nail:

  Pour some cereal, pour some milk, mix it all up, and taste it. If there's too much milk, add a small amount of cereal. If there's too much cereal, pour a wee bit more milk.

  The problem lies with insisting on planning the whole before you fully understand the parts. When I get to be king, I will mandate that no project should last more then three months... 90 days is plenty of time to do something if you really understand it (during WWII entire ships were assembled in 90 days), and if it takes longer then 90 days you will be better off breaking the project into 90 day chunks.

  Posted by: johnreynolds on February 18, 2005 at 06:55 AM

• Usually when you make cereal u have a bowl, spoon, cereal, and milk. In IT you may have a bowl, the spoon is in development and you don't know where the cereal is. Whereas plumbing by its nature does not change radically every year, nearly every IT project I've been on deals with some new technique or technology. That along with some politics creates a very difficult tide to push against.

  When I evaluate other developers, I tend to prefer ones that can see the real milestones. It may have some problems but they are able to deliver real compoenents w/o overpromising. Often the worse ones promise to be on time and what they deliver requires tons of rework.

  Posted by: smartinumcp on February 18, 2005 at 07:23 AM

• This is an age old IT problem. We havent learned our lesson in 20 years. When the subject matter experts come up with a "realistic" estimate (accounting for all the "milk" and "ceral") they think we are out of our minds. But then the estimate is skinnied down and in the end...surprise it takes as much time as the experts said it would (and sometimes a bit more) and the experts end up looking like lousy estimaters. Dont even get me going! Nobody wants to come to grips with the fact that 1) developing quality code takes time, 2) there are very few "slacker" developers, and 3) even the experts dont really understand the Iceberg theory, that 2/3rds of the time is below the surface. Just take the construction time and times it by 3.

  Posted by: daveupdike on February 18, 2005 at 08:37 AM

This work is licensed under a Creative Commons License.