Asking Why to Uncover Assumptions

Posted on June 5, 2020 by Riccardo

Stop.

Consider the task you are doing.

Why are you working on it?

Why is it important?

Why?


Recently, I worked in a project that enabled users to record measurements. While prioritizing bugs, we noticed a ton of issues related to timezones—who would have guessed?!

At first, we tried the brute force approach and started moving tickets from to-do to done. But we realized soon there were just too many, so we stopped and asked why:

Why do we need timezones?
Because we have them in the product.

Why do they really matter?
Because we are recording the local time of each measurement.

Why do users want timezones?
Because they might compare measurements taken across locations.

Why would do they do that?
Because.. Because.. Well, that's a good question!

The developers' favourite key: backspace.Twitter_Logo_Blue

ELI5 worked its magic: we actually didn't need timezones. So we turned to the developers' favorite key, backspace. A few hours later and a couple of thousands of lines of code less we were done!

We made a mistake: we started with a solution (i.e. timezones). Asking why allowed us to ladder up to the problem space. Here, we uncovered an assumption (i.e. users need to compare across timezones), found a cheap way to validate it and discovered the problem was not there in the first place.


You may want to dig deeper into "Challenging requirements". Thanks Gojko for the inspiration!

PinkLetter

It's one of the selected few I follow every week – Mateusz

Tired of RELEARNING webdev stuff?

  • A 100+ page book with the best links I curated over the years
  • An email once a week full of timeless software wisdom
  • Your recommended weekly dose of pink
  • Try before you buy? Check the archives.