Debugging – down the rabbit hole (or not!)

We’ve all been there:

Developer A: This feature should only have taken an hour to develop.  Next thing I knew, it was two days later and I’d still not solved this weird bug with method X.

Developer B: Why didn’t you just stop using method X and start using method Y instead?

Developer A is down the rabbit hole:  When you’re digging so deep into a problem that you can’t stop going.  “Just 5 more minutes of investigation could make this whole wasted day worthwhile”, said every developer ever.

So, how do you stop yourself from spending too much time investigating a given approach to a problem?

This was a question that came up in a recent one-to-one with one of my team.  There are various different ways of tackling this one, but I’m going to outline one that works for me:

Know your alternatives.  For example, I needed to do some pre-preprocessing on form data coming in from our third-party admin system.  So I started digging into the admin system to see if there was some way to attach a data-transformer to the form fields it was creating.  Except that I didn’t just start digging.  instead, I had a conversation with myself which went something like this:

Okay, I could try and find a configuration option which will allow me to attach the data transformer.  That would be easiest.  But if there isn’t an option, I could override the form-creation method to support one.  That shouldn’t be too hard.  But what if it is!?  Hmm, maybe I could not use a transformer at all, and instead modify the entity to accept the raw data and transform it there.  That’s not so clean, but it’s pretty easy to code.

You can see that I’d outlined three options:

  1. Find and use a config option
  2. Extend the admin system to support the config option
  3. Abandon pre-processing and do post-processing

Notice that I didn’t need to know whether any of these were possible.  All I needed was a vague idea of how big these tasks might be, and of how “desirable” they were (e.g. option 3 is quick, but not very “clean”).

Once you have thought of at least two options, you can start work on your preferred one.  And as you’re working, keep asking yourself this key question: “Does it now look like the next option would be quicker or more desirable than what I’m currently trying after all?”  it’s important not to forget the “more desirable” part – you may realise that an alternative option would take longer, but be less of a nasty hack that what you’re currently contemplating!

By keeping this question in mind, you’ll never go too far down the rabbit hole.  Instead, you’ll back out and move on to another option.  If you find the discipline of asking the question difficult, combine this approach with “time-boxing”.  Set an alarm for some small amount of time (an hour?) and take that as your prompt to ask the question.

Well, my colleague in the one-to-one liked the idea and suggested I blog about it.  Since he’s particularly smart, he also pointed out that this approach is just like the the A* Search Algorithm for path-finding.  I hope this approach helps you too.  Feel free to share your debugging adventures in the comments!

Post a Comment

Your email address is never published nor shared. Required fields are marked *

Ready to talk?

Whether you want to create a new digital product or make an existing one even better, we'd love to talk it through.

Get in touch