Don't Make Squirrel Burgers

Your manager comes to you and says “Hey, Joe.  Let’s talk.  I need to get a new system developed to keep track of our help desk calls.  It needs to have a slick user-interface that is easy to navigate, it needs to be fast, and also we need integration with SAP.”  You ponder what the system architecture might be like.  He continues.  “So how long do you think this will take?”

Of course, your first instinct is to tell your manager that you’ll get back to him later with a rough estimate, but he is in a hurry and persistent.  You cave in and tell him, “I think it would take 6 weeks.”

“Hrm, 6 weeks?  I really need it in 5 weeks, no later.”

Your manager is already negotiating your rough estimate.  Be afraid.  You start to figure out how you can accomplish all of this in 5 weeks and you are realizing that you really needed eight weeks, not six.  Let me put this story on pause while I tell you another story…

Bob is the new night manager at FatBurger.  One night a man walks in and requests a double Fat-burger with cheese, a large order of Fat Fries, and a chocolate shake.  He pulls out the change in his pocket and Bob finds out that he only has $1.20.  The entire meal costs $7.50.

What would you do in this situation?  Turn away your only customer in the 11:00pm hour?  Offer something that he can afford?  Give it to him for $1.20 this time only?

Bob, being a proud night manager, wants to satisfy his customer.  He cannot give away the food cheaply because then the guy will return again, expecting another discount.  So Bob decides to get creative.  He goes around back and finds a dead squirrel on the pavement.  He scrapes it up with a shovel and brings it inside, grills it up and gives it to the man.

In this story, Bob sacrified quality to give the gentleman what he wanted for only $1.20.

Stop me if this scenario sounds familiar.

Back at your desk, you are realizing that you are about to deliver to your manager a squirrel-burger.  He wants X features, but you can’t deliver them on time.  The first thing you are going to throw out are automated tests.  Then you’ll stop refactoring.  Pretty soon you are just heads-down coding like you did in high school and you are making a huge mess.

Two things are likely to happen.  The system will buckle under its own weight because the code reaks of dead squirrels.  The other thing that is likely to happen is that your system becomes useful, and now management has another request.

“Hey Joe.  The new system rocks!  I just got off the phone with marketing and they want to start selling this to our larger clients.”

Now you’re in a pickle.  You have a spaghetti-mess of a system and now you need to extend it and polish it for redistribution. 

This sad state of affairs is all too common.  Your manager might want a double Fat burger with cheese in 5–weeks, but what he’s getting is a squirrel burger.  Don’t deliver squirrel burgers.  Be careful with off-the-cuff estimates that end up turning into negotiations.  Joe should have negotiated features instead of quality to meet his 5–week deadline.  Estimates should include time for automated tests and refactoring because it is part of your daily coding activity and it helps maintain quality.

I first heard the term “squirrel burgers” and the above story from Mark Pushinsky.

#1 nichols.mike.s AT gmail.com (Mike Nichols) avatar
nichols.mike.s AT gmail.com (Mike Nichols)
10.01.2007
9:36 AM

Software estimation is tough for me..especially since I work alone and am doing everything all at once. What is a typical cycle you go through to give as accurate an estimate as you can? Do you have a recent success story you can share to show how you did it?


#2 Ben Scheirman avatar
Ben Scheirman
10.01.2007
1:01 PM

Actually I would say I'm pretty amateurish on estimation, but I've been reading Steve McConnell's book Software Estimation:Demystifying the Black Art and so far it's really great.My biggest push right now is to get people (read: management/sales) to stop treating estimates as delivery dates.We're asked to put together estimates for proposals that end up becoming contracts and I think that is a very dangerous game to play.Bottom line:Don't give off the cuff estimates.Always take your time.McConnell says:always calculate and compute, leave judgement out of it if possible.(The last application we averaged 32 story points per iteration, so let's assume that will continue for this project).This is obviously pretty erroneous in the beginning, but as you progress and gather real data from your current project, your estimates become much more accurate.


#3 Tyler Phillips avatar
Tyler Phillips
10.01.2007
3:22 PM

Sounds like you guys aren't taking adavantage of the Ballmer Peak:http://imgs.xkcd.com/comics/ballmer_peak.pnghehe


#4 Ben avatar
Ben
10.01.2007
5:10 PM

Funny, I just recently subscribed to that comic feed.It's definitely hit and miss, but that one was a hit :)


#5 Sean Chambers avatar
Sean Chambers
10.01.2007
10:36 PM

Great story! I myself have served up many squirrel burgers in shame. Fortunately it wasn't in the recent past. I find that once you deliver one or two excellent products, management will back off and give you a little more room. They learn to have faith in you and not pressure you to get it down exactly on schedule. This coupled with agile practices definately shows them a different way of doing things and they seem to like it when it works well. I may be a little isolated though because I am a sole developer working with a few departments so I may just be doing everything @ss backwards =)I loved that comic this morning, sent it to all my co-workers. A couple of them claimed they must have used it with vista as well.You are right on the hit or misses though.good post!


#6 Scott Bateman avatar
Scott Bateman
10.02.2007
12:18 AM

A few tidbits of advice for Joe the next time he is put on the spot:1) Don't cave - take the time to write it outTell your manager that you don't want to make an ass out of both of you.If he wants to have any chance at delivering this project to his boss, you need a day to think about it.If he continues to insist say it will take 3 years.Then he may go pick on someone else and that doomed project is no longer your problem :)2) Clearly define the goalNo matter what you estimate, if your vision is different than your manager's you won't get it right.Write out 5-6 sentences that define what you heard he wanted, and what the end result will look like.Base your estimate on that goal and nothing else.3) Think in smaller chunksThrowing out six weeks is dangerous because you're probably thinking about 6 things that may take about a week.That is how the brain works at the highest level. If you forgot about 2 things your suddenly at 8 weeks like in the example!Break those "things" down to try and get discrete tasks that are 1-2 days of effort each.Create domain model: 1 day, Define tests and create testing project .5, Create ORM mappings 2 days, etc.Sum up all of the things and make sure that you've accounted for the design, development, and testing of all of the necessary parts.4) Add contingencyAll estimates should have some contingency for hardware problems, requirement delays, atrition, etc.Most respnsible managers will not challenge the need for some contingency time, but the % to use will vary on the type of project.5) Put it down... for a whileFinish the estimate then walk away.Come back the next day and review with a clear head to see what you may have missed.Now it is ready to deliver and get started on your new project!


#7 Ben Scheirman avatar
Ben Scheirman
10.02.2007
9:36 AM

That's awesome advice Scott!Thanks.