Part of a software developers job is helping our team understand how long something will take to build. This article aims to highlight why this is sometimes hard to fathom, using my favourite metaphor - Mexican food.
When estimating for features and functionality in a software application, the person asking us to estimate often has ideas about how long they think the work will take. This person is usually a project manager who has worked on similar projects in the past and so is well positioned to understand the factors that feed in to our estimates. There are, however, often nuances that can drastically affect how long a feature will take to implement. I believe that developers and designers can do a better job in working with project managers to help understand these nuances.
Cooking chilli con carne
Take, for example, the act of cooking a chilli con carne. You've probably done this before and can take a rough guess at how long it took you last time. Let's say the last time you cooked a chilli con carne for two people, you did the following:
- Prepare the onions, peppers, chillis and sour cream - 10 mins
- Fry off the onions - 5 mins
- Fry off the mince - 8 mins
- Add the tomatoes and kidney beans - 5 mins
- Add the spices and leave to simmer, stirring regularly - 25 mins
- Boil the rice - 20 mins
- Plate up - 4 mins
Last time you prepared a chilli, you had two people in the kitchen, one focused on the rice while the other focused on the chilli. This meant that jobs could be done in parallel. Last time it took 45 minutes to cook a chilli for two people, so that's the estimate we'll go with.
Considerations
Ok, so a bunch of assumptions were made above:
- All of the ingredients were already available to hand
- There will be two people in the kitchen when we cook again
- The people cooking the chilli con carne will have cooked one before
- The guests are meat eaters
Because of the considerations above, our estimates for how long it will take to cook again this time could be wildy different. Let's look at each one:
All of the ingredients were already available in the kitchen
Let's say they were not... We can easily add another hour to our estimate to cover driving to the shop, purchasing the ingredients and driving back. That one item alone has more than doubled our original estimate.
There will be two people in the kitchen when we cook again
On the surface, this seems like it would drastically affect our estimate. If there is only one person it will take them twice the time, right? That's as bonkers as saying if we had 45 people in the kitchen it would take them one minute to cook the chilli con carne. In this case, if we only had one person instead of two, it would likely not affect the time at all - the single chef can start boiling the rice once the chilli has started to simmer.
The people cooking the chilli con carne will have cooked one before
Am I, the person estimating, the person who will be cooking the Chilli? If not, I know that there is another chef who is super fast at prep work, and will probably shave off a bunch of time at the preparation stage. Similarly, I know we have a junior chef who has just started and this could be a good introduction to them. We know they're likely to burn the onions first time round, so we should allocate some risk so we can start again if needed.
The guests are meat eaters
Well this could seriously screw up the estimate and the scheduling. Should we contact everybody on the guest list to make sure they're happy eating meat? Should we cook two separate chilli's, one for veggies and one for meat eaters? We only have two hobs on the oven, one for rice one for chilli, so we'd need to cook both meals separately, or consider microwaving something, for example...
The problems tend to arise when we estimate based on a bunch of assumptions similar to those above. As developers, we need to capture the assumptions we make as part of our estimation process, so that we can help our project managers iterate the risks to our clients, and manage schedules if something deviates from our approach. In this case, an example of documenting our assumptions could be:
- We assume that no ingredients will be available to us when we start cooking.
- We assume that only one, experienced chef will be cooking the meal.
- We assume that at least one guest does not eat meat.
This leads to the following estimates, and imposes a scheduling restriction in that none of the cooking tasks can be started until step 1 - shopping for ingredients is complete.
Cooking for two people - 170 mins
- Drive to the shop to fetch ingredients - 60 mins
- Prepare the onions, peppers, chillis and sour cream - 10 mins
- Fry off the onions - 5 mins
- Fry off the mince - 8 mins
- Fry off the vegetarian mince substitute - 8 mins
- Add the tomatoes and kidney beans to both dishes - 5 mins
- Add the spices and leave to simmer, stirring regularly, switching between meat and veg on the hob - 50 mins
- Boil the rice - 20 mins
- Plate up - 4 mins
An interesting point is to consider what would happen if we wanted to cook for ten people instead of two. This actually wouldn't affect our estimates too much at all. We'd need to spend a bit longer picking up five onions instead of one at the shop, and would need to do some more chopping, but really the majority of the overhead comes in the other steps. A chilli con carne needs time to simmer, time to boil rice, and time to fry things.
Cooking for ten people - 189 mins
- Drive to the shop to fetch ingredients - 65 mins
- Prepare the onions, peppers, chillis and sour cream - 20 mins
- Fry off the onions - 5 mins
- Fry off the mince - 8 mins
- Fry off the vegetarian mince substitute - 8 mins
- Add the tomatoes and kidney beans to both dishes - 5 mins
- Add the spices and leave to simmer, stirring regularly, switching between meat and veg on the hob - 50 mins
- Boil the rice - 20 mins
- Plate up - 8 mins
Summary
So how does this relate to creating software?
The assumptions we make during our estimating phase are just that - assumptions. In my opinion, the most valuable thing we can do as part of our estimating sessions is to capture the scope of our estimates and the assumptions we made when declaring them. This will help us and our project managers weigh up risk and scope during estimating and early stages of development. We've talked about cooking a chilli con carne here, but this could just have easily been a software project where we'd need to consider the following:
- Are all third party services and frameworks already available to hand?
- Will there be two people working on the project simultaneously?
- Will the people working on the project be familiar with the coding languages we'll be using?
- Does our client have any unforseen requirements, such as the need to support old platforms or integrate with third party systems?
Our assumptions for this project may be:
- All of the third party services are assumed to be fully end-to-end tested and well documented
- There will be two senior developers working on the project simultaneously
- The developers contributing to the project will have built similar products before
- The client has no requirements on software, style guides or services we can integrate with
By capturing the scope of our estimates and our assumptions at the time we create them, we give our team the ability to understand why we arrived at the estimates we provided and what we considered before settling on our figures.
I'd be interested to know if you and your team have nailed your approach to estimating, and how you've gone about it. Be sure to email me at ryan_"at"_ryantyrrell.com if you'd like to chat!