I was attending a feature set review the other day. As usual there were two camps each with a strong attachment to their solution. Not having a strong opinion on either side asked I, “How would someone succeed or fail with each of the options?” To my surprise, the push back I got was “Let’s just build one and see. In Agile, you build first and ask questions later. It is just impossible to think this stuff through, which is why you build.”
Now Einstein came up with the whole relativity thing using Thought Experiments. Surely our problem is not as complex as that, I argued. Besides, have we tried to figure out? Do we know what is well understood and what is not? This line of reasoning was not being bought by the group. They wanted to build as a way of figuring things out.
What is wrong with “just building it”?
Cost! It is costly in time and money and while it feels like progress, it is not. But just because something is being built does not mean there is progress. Progress implies forward movement towards a goal. Without well thought out steps, the effort may not be progress but just movement. As discussed below, “just build it” is one of the tools in the arsenal and is to be used after the thinking has been done.
What is a thought experiment?
It a fancy way of saying: “think through the various cases and scenarios of how things are going to work”. Thought experiments postulate different cases that are expected and works through the outcome. These “dry runs” are the cheapest fastest ways of making progress for a broad set of problems. Usability Walk-through’s are an example of this. Design walk-through is another example. User story mapping, is another such example. The process does not have to be formal, although it does need to provide good coverage.
One should always use Thought Experiments.
There is never an adequate excuse for not using the brains in our heads to think things through. Here are some benefits of doing thought experiments:
It saves time and money
It allows you to bring other people into the solution because you understand it better which will lead to you being more convincing.
It causes you to understand the problem better. Working out the details in your head and on paper really does allow you to simulate doing it for real.
It may solve the problem and give you a solution.
It brings clarity to what the real issues are. If you do thought experiments you will figure out what is easy and what is hard. You probably will discover what actually does need to be built and tested empirically.
It allows you to assess risk in the project and allow others to see how hard the hard parts are.
There are times to “just build it”
There are certainly a number of problems that can be solved best by experiment. It is after the thought experiment has been worked out that one can consider actually coding up the solution. The default should not be “just build it” but rather “here is what we should build and why”. Good reasons to build it:
There are some key complex pieces that need to be built to understand the feasibility of accomplishing the task at hand. Complex algorithms dealing with real data are a great example of this.
New usability ideas. There are so many examples of good and human interfaces that not learning from these seems wasteful. Know what you are doing that is new.
What you want to build is simple and much easier to do than to do a thought experiment on. This case really exists but is far too often used as an excuse for not thinking in the first place.
The people who need to be convinced will only be convinced with a working prototype. This is an unfortunate, but necessary, political answer to a real problem. “Seeing is believing” is sometimes the only way to understand or to move forward.
When you are just prototyping to get some understanding of a new paradigm. When you really do not understand the dynamics of how something would be used, it is time to build. Even there, thought experiments can help focus what should be built and what should not.
To play around with an idea that you partially understand and the requires some experimentation to get clarity of thought.
The Product Owner needs to drive this process and guide everyone away from just building. Engineers have a strong desire to get moving and start building. If the Product Owner has done a lot of the thought experiments early, the arguments of what should and should not be “just built” will be much easier. The challenge is to have the strength of character to force more Thought Experiments.
© 2011-18 Westerly Consulting LLC, all rights reserved