Ask Why But Don’t Expect An Answer

Lately, I’ve been thinking about code, maintenance and some other bigger thoughts. Often, things will occur over the course of working with software that makes us go “But why?”. Asking why something is the way it is a necessary skill for a software tester, but like other skills it should be learned and worked on over time.

A long time ago, JB Rainsberger wrote something about working with legacy code. He was working with a piece of old code that made him go “why would someone write code like this?” or similar. (I’m not able to find the exact post of his.). His advice however was to ask “why”, but not expect any answer. After all, the programmer who wrote the code was no longer there to answer it, and the answer wouldn’t help the refactoring effort anyway.

I’ve been reflecting on this, and it strikes me as great advice for testers, developers and a bunch of other people as well. Asking why something (like code) was done a particular way is a natural question for people to ask. It can help provide context, as well as satisfy a need to understand the problem better. However, sometimes the explanation doesn’t exist or isn’t helpful. “Time pressure” doesn’t exactly euclidate the problem, nor does reaching out to someone long gone from the situation.

Asking why is always something we can do to help us solve a problem, but we shouldn’t always expect an answer, let alone a good one.