Fixing Bugs -or- Why 5 minutes Sometimes Means 2 hours

I’ll try to keep this brief, as I’m sure you all probably realized this already. Even so, it’s always a good reminder and will help keep developers and non-developers on speaking terms.

I’ve got a simple analogy for you as to why some (many) things take longer to develop than developers initially estimate and, more importantly, why we perpetually believe it will only be “just 5 more minutes” as we continue to debug.

The leaky sink.

Now, a leaky faucet is presumably simple fix. You will usually have a good idea where the problem is coming from because you can clearly see where the water is leaking, but not always. Most leaks can be fixed with what you already have around the house, but sometimes you have to go out an get new parts. Many times you’ll already know how to fix it, but now and again you’ll need to do a bit of research. Lastly, once in a great while you’ll need to call in an expert, because the problem either wasn’t what you expected OR it becomes too big for you to quickly do by yourself.

Sometimes it’s a simple problem… (5min or less)

The best scenario. This is when you didn’t close the tap all the way, or something has come just a little loose. In programming, this would be a typo or a simple logic error. No big deal, it’s already fixed.

Sometimes it’s a different problem… (5min, x2)

This one is annoying. You thought it was a problem with the faucet, but later found out it was a problem with the tap. You’ve already spent 5min working on the faucet, and now realize you need to spend another 5min on the tap. This happens a LOT in programming.

Sometimes it’s multiple problems… (5min, x2, x2, x2)

Now you’re really frustrated. You looked at the faucet and saw it wasn’t there, then you spent 5min on the tap and the leak still exists. Now as you look more closely you see there’s actually another (two, three, four) problems happening underneath the sink. Or, worse, because you fixed one problem you’ve actually created a problem elsewhere (without the steady leak, now a pressure buildup has busted a pipe. $#!&).

Sometimes there’s a false positive… (5min, x2 …. wait 30min, try again)

The leak has stopped! …temporarily, until you or someone else tries to use the faucet again. You’ve spent your 5 (10, 15) minutes fixing what you thought was the problem, and now the problem is back again. In programming, this is especially troubling because now you’re not sure if it’s just a caching issue or something else entirely.

Sometimes there is no problem… (30min for nothing, FML)

There wasn’t a leak, you (or someone else) just splashed some water up behind the sink. In programming, you’ve spent the last 30 minutes chasing a bug that doesn’t exist. Do not pass go, do not collect $200.

Hang on, just 5 more minutes…

Next time a developer tells you “Just 5 more minutes” and they’re wrong, remind yourself that they’re not lying and they’re not bad at estimating (and no, they don’t hate you), they’ve just encountered a new or different (or additional) problem than they set out to fix 5 minutes ago.

5 thoughts on “Fixing Bugs -or- Why 5 minutes Sometimes Means 2 hours

  1. This makes me remember much of my child hood helping my dad with various chores and projects around the farm. He’d always say “this will just take 5 minutes” . . . 4 hours later we’d still be at it 😀

Leave a Reply

Your email address will not be published.