The Five Whys

In The Pragmatic Programmer, David Thomas and Andrew Hunt write “a favorite consulting trick: ask ‘why?’ at least five times. Ask a question, and get an answer. Dig deeper by asking ‘why?’. They say “Repeat as if you were a petulant four-year old (but polite one). You might be able to get closer to a root cause this way”.

Well, I was happy to read this because it reminded me of a manager that I had very early in my career, in which a colleague and I rewrote a big, old and long-forgotten service, only to cause a major incident for the biggest customer right on the very first days.

The both of us were young, so you can imagine that we became nervous about the incident. This manager in question came to help and asked the first “why”: “why is the customer seeing this behaviour?”. We were hopeless, because everything looked clean on our code.

So another “why” was asked: “why did this never happen when the legacy service was running?”. Perfect, now we had something to compare against, we had a baseline, and indeed we found the culprit. It was a tiny and yet very important missing if statement in the middle of thousands of lines of code.

This conditional clause contained a business rule, which was supposed to live on an external application, and which we took for granted that would run this validation for us. It didn’t. It could, but it didn’t, and the if statement was there as a safeguard.

We fixed the issue, deployed a new version and the functionality was restored. One could stop here and call it a day, but another “why” came by, and this one was not about fixing anything. Rather, it was about prevention: “why did we miss this?”. And on we went, with a few more “whys” until we could learn about this and set a new standard for the team.

We ended up creating a thorough service migration checklist, on which the engineering and the product teams could have a common language to speak and align on requirements (reminds me of Domain Driven Design, but I did not know DDD at the time).

The manager told us that “We must ask ‘why’ five times. We may find the root cause on the second or the third, but have in mind to ask five consecutive ‘whys’ when you want to investigate something”.

I looked up to this manager, who helped us and was wise enough to keep asking “why”. I started doing the same and haven’t stopped since. Whether he learnt this behaviour from the book, from someone else or from his own experience, I do not know. What I do know is that I am thankful for his guidance and glad to see knowledge out in the world in all sorts of formats, available to anyone.