The Journey For The Right Question

The importance of one step at a time (in the right direction)

Listen to the audio version!

There are techniques and ideas born in different areas that can eventually find their way into programming.

For example, Lean Software Development came from the Lean Manufacturing which is said to have been derived from the Toyota Production System. It's the base for the whole movement of creating only the minimum amount of functionality when building software in order to avoid waste and (by consequence) unnecessary complexity.

Programming makes you think. Makes you reason logically about how to create a working product and makes you build empathy in order to write a code that can be understood by other programmers. It's very easy to build something small but it's very difficult to build something big.

Asking the right questions, to yourself and to other people, is a fundamental skill to be able to build something big and seamlessly. Those questions can come in the form of "why" in order to clarify requirements and prevent Over-Engineering or they can help to investigate the root cause of a problem. In the end, there's probably more value in having the right question than knowing the right answer.

There's more value in having the right question than knowing the right answer, for that the right answer can be the answer to the wrong question. And that's useless.

There's no universal way to come up with the right question because each circumstance is unique. It’s a type of Tacit Knowledge, which means that it cannot be easily taught (as in a book).

It’s possible to argue that the "right question" can be subjective and two people can come up with different definitions of what a right question is. It’s even possible that two highly skilled individuals can come up with two different right questions that are worth pursuing.

I believe the example below can show the fundamentals of this principle. It's a hypothetical (but pretty common) scenario, where a team wants to find ways to make the project better:

• Question: What can we do to make this web application faster?
• Answer: If we remove a few bytes from the gzipped code that is downloaded by the users in their browsers, it will reduce the amount of network traffic to all of our user's requests, and that will reduce the cost of bandwidth from our servers.
• Question: How much money removing those few bytes would save to the company in the period of one year?
• Answer: The cost of removing 1 byte from gzipped code for all of our user's requests, according to the data of our average monthly traffic, is about 10 dollars in a year. Removing a few bytes would save us a few tens of dollars in a year.
• Question: Is the cost of effort required to reduce those few gzipped bytes worth the benefits of saving a few dozen dollars in a year?

The last question poses something interesting. If the goal of the company is to make money, and the price paid for the engineers to reduce the amount of gzipped bytes is bigger than the price paid for serving a few dozens of bytes to all user requests, then it might as well be a wasteful thing to optimize for.

Of course, there are other right questions that can come up which could change the decision or at least raise some interesting discussions:

• Is there any data showing that some users are leaving the main page because of the network delay those few bytes are causing for devices with poor network connectivity?
• How many of our users use those type of devices?
• Is it still worth the investment?

The investment could be worth it. But again, as long as the cost outweigh the benefits.

Sometimes, like in the optimization example, coming with the right question doesn’t require a lot of effort. It requires effort to look for data that can answer those right questions and allow to move forward into new questions. Despite the speed or size of the step, having the right question can, at least, point the development to the right direction.

We should always move forward, one step at a time. What matters is not the speed, but the direction.

In the "The Hitchhiker’s Guide to the Galaxy" fiction series, there’s a huge supercomputer called Deep Thought. It was built for the purpose of providing the “Answer to the Ultimate Question of Life, the Universe, and Everything”.

When the answer was calculated, it was the number "42".

However, nobody understands what "42" means. The reason why the answer is meaningless is that the beings who instructed Deep Thought didn't know what was the right question in the first place. The number 42 comically shows that having an answer is not enough to have something useful.

Maybe investing additional effort into the journey for the right question can be worth it.

That means:

• Do a spike aimed to understand better the complexity of what needs to be done before start doing it
• Clarify requirements in order to avoid doing something different than what should have been done
• Exercise an investigation to understand what are the most important parts of the business that can deliver most value (technically and non-technically)

Even if it turns out to be a waste of time, at least you have wasted that time in the question before starting to build the answer.

Without the right question and jumping straight into the answer, you might as well be wasting a lot more of your time.

Let's not do that.

Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.