Estimation is inseparable from planning
This is another post in the estimation series, following on from How to think about task estimation, and How to pick a number for any purpose.
The reason it’s been over a month since the last post is that I’ve moved home in the interim, and although I’m slowly getting back into a state where I can write, it’s been a lot.
This isn’t an apology, you understand. As I’ve pointed out before, I’m English: We use “sorry” as punctuation, so you can be pretty sure if a sentence doesn’t have “sorry” in it it’s not meant as an apology. I’m just introducing the topic of this post.
You see, one of the things that characterised this move is that there were a lot of things that really could have benefited from estimation, and which I absolutely did not estimate (or did not correctly estimate).
Many of them are illustrative of some general problems of estimation. In particular, a lot of this post is about how the easiest way to get an estimate wrong is to not have realised you needed to estimate it at all - either because you just didn’t think of it, or because something that was completely outside of your awareness (an unknown unknown) turns out to be crucial to your estimates, and you didn’t or couldn’t have a way of surfacing that.
Estimation in the aftermath
One of the big common failures of estimation is assuming that your productivity after some big event is going to be the same as your productivity before hand. If you’ve got some push for a big release, you can probably be quite productive in the run up to that release. Also then you’re all going to be exhausted afterwards and the next couple of weeks are definitely going to be at reduced productivity.
This is almost never included in estimates1, but really should be. I say this partly as someone who utterly failed to include it in an estimate. I was asked when this series would be finished back in July:
That was two months ago, so my prediction was that this series was 95% likely to be finished by the end of this month.
I grant that it is technically still possible that it will be, and that a 95% prediction is not a guarantee, but nevertheless I think if someone had said “David you’re moving in the middle of that” I would have gone “Oh yeah, good point” and revised that estimate considerably.
Task estimation is often treated as something that you can just do to a task - the size is a property of the task, and can be estimated for the task in isolation - but the reality is that estimation at any reasonable scale is utterly inseparable from planning. You can probably estimate whether something is going to take hours or days without taking too much context into account (although, see later in this piece…) but once you’re estimating on the scale of weeks or months you need to start taking a serious look at what’s actually going to be happening in that time period.
How many rolls of tape do we need?
Something I hear a lot from programmers is that there’s no point in estimation, you just break your project down into manageable tasks and then count the tasks. If you need to estimate a task, that’s a sign that it’s too large and should be broken up further.
Setting aside that their argument that you don’t need to estimate is to provide an estimation technique, I now have a very simple counter-argument to this: How do you break a roll of tape down into tasks?
One of the problems that we ran into in the course of moving was that we ran out of tape. I had three rolls of tape - one clear tape left over from other projects, one masking tape I’d bought for boxes, and one fragile I’d bought primarily for marking boxes with fragile items in.
We used all of it, which resulted in the last few boxes not being properly taped. Fortunately I’d hired professional movers and they taped a bunch of things that still needed taping2. This was not a disaster, but it was inconvenient. We made do, and if we'd been unable to make do we probably could have popped to the stores to get more tape (but it was about 9PM at this point and we really didn't want to).
We also ran out of the fragile tape first, specifically (because we'd been using it for taping up individual wrapped items and only realised this was a bad idea later) and had to reserve the last of it to basically just use as a sticker on one or two boxes.
How did this happen? Why didn’t I provision enough tape?
Well, partly it happened because my girlfriend, Lisa, was helping me out and she used a lot more tape for some tasks than I would have. Partly this was philosophical differences, partly this was that she was erring on the side of caution with my fragile stuff (it feels worse to break someone else’s stuff than your own!). I think she used more than probably made sense, but this was not, in and of itself, a problem. Tape is cheap. The problem was that it resulted in a very different amount of tape getting used than I would have expected.
The second problem is that I didn’t actually ever seriously ask the question “Do I have enough tape?”. I just bought some tape and never really thought about whether I’d need more tape than that.
For some things this is fine. This is also the approach I took to buying boxes for books: I ordered some boxes, they turned out not to be enough, so I ordered some more.3 This wasn't a problem, but it wasn't a problem for a fairly straightforward reason: This was over a week before the move, so I could just order said boxes and have them arrive in plenty of time. Tape, we ran out at about 8PM with movers coming the next day. I could have gone out to get more, but at that point we were both exhausted and decided to make do without.
I want to reemphasise, this wasn’t a disaster. It’s notable not because running out of tape is a terrible tragedy, but because it’s illustrative of a general problem: Resource allocation is a form of estimation, and it’s one that’s much harder to adapt to errors in than time estimates tend to be. Further, it’s estimation that you can’t avoid doing, and if you do it without thinking about it it will tend to go badly.
When you run into this at work, it won’t be “How many rolls of tape do we need?” it will be “How many people do we need to assign to this project?” or “How much RAM do we need for this server?”4, and if you don't treat it as or more seriously as you would time estimation, you're going to end up making expensive mistakes. These can also have knock-on effects on time estimation: If you're lucky the estimate is just wrong because you need to spend another day or so debugging memory issues or provisioning more capacity. If you're unlucky you missed a zero off how expensive your plan was and you need to rethink it from scratch and then implement the new mechanism.
In the case of the tape though, tape is cheap. The correct thing to do would have been to ask “Do I have enough tape?” and answer “Hmm maybe. Better buy another roll just to be sure.”
How long will this take?
The strategy I adopted for packing was to get all of the big things done and leave a lot of the things for the last day so that the flat would remain liveable while I was moving out.
Great idea, but it turns out that when you leave things for the last day before a move, that means you’ve got exactly one day to finish them in. Hope you estimated the amount of work remaining correctly.
Spoiler alert: I didn’t.
This was due to a problem with the approach of breaking things down into lots of manageable tasks. I did that. Based on this breakdown I’d done about 80% of the work prior to the last day. The problem was that this left the other 80% of the work for the last day.
The problem is that a huge amount of work in any project is miscellaneous. In software, nobody wrote a ticket for “Fix the release blocker bug you discovered six hours before launch” or “Oh wait the landing page needed not to be incredibly fugly”, but these are part of the implicit work.
Similarly there turned out to just be lots of small things that I didn’t anticipate figuring out - things that I wrote off as “just fill that box” were actually “go through the items and throw out the dead ones, and figure out how to pack the fragile ones, and make sure you wrap the sharp ones…”, there were drawers I literally didn’t remember existed, there was stuff in drawers I didn’t expect there to be.
In terms of actual tasks I was considering, I was probably roughly right about the last day. However the aggregate effect of many small tasks added up to quite a stressful day.
I did have one case of successful estimation in all of this though, which was that at about 11PM I looked at the remaining work and said “Look, there’s no more than an hour’s left of work here, but we are at the staring vacantly stage. It’s time to go to bed and finish this in the morning before the movers arrive”. I was, thankfully, right and that worked out OK.
If I had been wrong, it wouldn’t have been the end of the world. We could have coped with my failure of estimation by continuing to pack while the movers were here (I’m sure it wouldn’t be the first time they saw this) and it would have gone fine - worst case scenario I would have owed them a bit more money.
Estimation and failure
Another failure of estimation on my part was that I failed to estimate how many bookshelves I needed in the new place (partly because I’d failed to estimate how many bookshelves I could fit and as a result came up with a bad plan). I bought two Billy bookshelves from IKEA and one 5x5 Kallax,5 with the intention of putting the books mostly on the Billies. Unfortunately, it turns out I own a lot of books (you may recall this was also something I failed to take into account with boxes...), and by the time I'd filled both Billies I still had approximately half my books left to shelve.
This isn’t the end of the world. They’re on the Kallax temporarily, and I can just buy more Billies. So I made a plan to do that.
I decided that rather than ordering it I would just go to IKEA myself6. So I tried to go on Monday. Lisa pointed out this was a terrible idea, because Monday was a bank holiday and so IKEA would be absolutely awful.
I listened, I really did, and I agreed that it would be awful but decided that it would be worth it. There was a relatively narrow time window where I really wanted these up by this weekend, and relatively few days this week when I could feasibly drive to IKEA. I knew it would be unpleasant, I knew it would probably take an hour or two more than it normally would, but I considered that worth the cost.
It takes me about an hour and 15 minutes to drive to IKEA7. I then arrived to discover that there were significantly more cars currently trying to park (probably 50-100ish) than there were free parking spaces (zero, in a parking lot that I think has somewhere in the region of 800-1200 spaces8). After about 10 minutes of meandering around car parks with everyone else, I gave up and drove straight home.
My visit to IKEA took about two and a half hours. Significantly less than I’d estimated! Unfortunately it didn’t achieve the desired result. And now my timeline for when I’ll have my bookshelves up is all wrong (I need some help, both because I don’t want to assemble bookshelves solo and also because I’m a little nervous about drilling supports in walls, and help is only available on a particular schedule).
If I’d delayed to Tuesday or Wednesday and gone then I would have made it on time, but as it is I’m absolutely unwilling to repeat the visit to IKEA (even though the chances of failure are much lower), so the whole timeline is pushed back.
One way of looking at this is there are three estimation questions involved here:
When will you have the bookshelves up by?
How long will it take to go to IKEA to get bookshelves?
How likely are you to succeed at getting bookshelves from IKEA?
Importantly, although both the first two are time questions, the first question doesn’t actually depend on the second, because there was no way for the trip to IKEA to take long enough to impact the delivery time on the bookshelves - I was never going to assemble them on the same day. The actual determining factor was the probability of failure. I didn’t estimate that.
Honestly, even if I had estimated that, I would have estimated it as much too low. I’m not actually used to the constraints of cars - IKEA being out of stock on Billies was the main risk I was aware of (they weren’t according to their website), but literally not being able to get into the store because of parking issues wasn’t even on my radar. Sometimes you get blindsided by an unknown unknown.
Estimation is inseparable from planning
The truth is all of these estimation failures are planning failures. This is normal. Part of the problem is that I’m pretty reluctant to do too much planning in my personal life, but this is somewhere where I should have.
A lot of failures in business are also like this - planning is hard and unpleasant, and many agile processes are basically designed to minimise this. This works well enough as long as everything is actually relatively continuous, and you don’t have large uncertainties or sharp deadlines.
But this does, still, fundamentally require you to accept that you’re taking on quite a lot of uncertainty, and that uncertainty can be extremely stressful and, often, expensive.
Take my courses!
Do you like learning about this sort of thing? Although ideally how to do it more competently than I did in this particular set of scenarios! Why not learn about it from me directly! I’ve started offering various courses on the sorts of skills you need as a software developer, including one on estimation. You can learn more about them at consulting.drmaciver.com/courses.
I’m also available for a wide variety of other consulting and coaching services for software companies. Have a read through the consulting site and/or drop me an email at david@drmaciver.com if you want to know more.
Subscribe to my newsletter!
If you liked this piece and want to read many more like it, why not subscribe if you’ve not already? Here’s a subscribe button for you to click. Go on, click the button…
Community
If you’d like to hang out with the sort of people who read this sort of piece, you can join us in the Overthinking Everything discord by clicking this invitation link. You can also read more about it in our community guide first if you like.
Cover image
The cover image is this picture of IKEA by Wikimedia user Mestos.
Partly because people think you can estimate in terms of story points, which basically gets you off the hook for ever producing an estimate that gives practically useful guidance.
And also looked judgementally at a variety of things I did tape and redid them.
As it happens we did also end up slightly short on boxes in the end. From my perspective this was fine - I had things in Ikea bags and such - but the movers wanted things in boxes so they used their own. Hidden requirements.
Container, these days, but that just means that you’re estimating ongoing monthly bills instead of up front infrastructure costs.
In fact I bought two Kallaxes. This wasn’t a failure of estimation though, I just apparently clicked the button twice. This is unfortunate as now I need to figure out what to do with a spare Kallax.
This was a somewhat dubious plan even in the best case scenario - I’m currently driving an old beast of a land rover and fuel prices are through the roof, so it was actually barely cheaper to do it myself than get delivery even before you count time spent.
Google maps estimates an hour, but it fails to take into account that I do not drive aforementioned old beast of a land rover at 70mph.
I spent a good 5 minutes counting spaces in the satellite view on Google maps yesterday to get to this estimate.
Your spare kallax: take it back to Ikea when you go back to buy your Billys