Misunderstandings caused by wrong assumptions or supposedly self-evident knowledge are, in my opinion, among the biggest obstacles to great software. Developers and business people can have a great time talking to each other, agree on everything and still understand two completely different things. Problems like that will not cause a project to get cancelled, the stuff that gets delivered may work, but its going to fall short of doing the right thing. Instead of being great, the result is just going to be mediocre and it will need rework so that the clients can really use it. One of the worst examples of how people can agree on everything and still make a major mistake does not come from software at all — it can be heard on a river boat trip.
The best way to quickly see lots of landmarks in London is to take the boat ride from Westminster to Greenwich. The boat operators do not hire professional tourist guides, but someone from the staff typically introduces important buildings with a mix of history, popular culture and humour. Not too far from the place where suspected pirates were chained to the river bead and left to the tide to decide whether they were guilty or not, on most of those boats you will hear the story how the London Bridge got shipped to United States. The original London Bridge was bought by some folks from US as a marketing stunt in 1968 for a few million dollars. It was taken down, every stone was numbered, packaged and transported to Arizona, then re-assembled there and it now stands on top of Lake Havasu. A new bridge, also called the London Bridge, was put in its place over Thames river, where this story typically gets told. Although this seems like a huge undertaking, it would not be important for this story if it weren’t for the wrong assumptions.
If the story is to be believed, the buyers assumed that they were buying the “London bridge” — you know, the one from all the postcards with two big medieval towers and moving platforms. In fact, they got the London Bridge. Although famous around the world because of the nursery rhyme, the original London Bridge is a very dull and ordinary construction. It does not stand out at all from any of the many anonymous bridges you cross every year without giving them a second thought. When you think about it, the nursery rhyme is actually about the bridge falling down, not about it being great or historically significant. No surprise the Brits were more than happy to sell it.
The new London bridge is equally uninspiring. In fact, most people are quite disappointed when they see the (new) bridge for the first time — somehow its fame leads us to believe that it is in some way special.
The landmark bridge of London, which the tourists flock to, is just half a mile down the river from the London Bridge, and it is called the Tower Bridge. But even at first sight, they are very, very different.
Somehow this story is a bit comforting for programmers, because it suggests that the software industry is not the only one plagued by the terrible effects of wrong assumptions. Although, I must admit, even if this story is true to the last word, problems caused by wrong or misunderstood assumptions are much more commonplace in software then in the world of second-hand bridge trade.
Ask "why", not "what"
I had a unique privilege of chatting to Eric Evans last week about the danger of (wrong) assumptions. He suggested asking “why” instead of “what” to flush out the assumptions and minimise the dangers of misunderstood requirements in software projects. This reminded me of the Commanders Intent story, where the conclusion was to focus on “why” and “watch out for” much more than on “what” and “how”.
Understanding why something is required, instead of just blindly following the tasks, is definitely one of the key practices to improve the chances of success in a software project. In my article The magic of goals, I suggested that whenever a client comes with a list of tasks, we should instead ask them for the problems that they are trying to solve and their business goals. In the same way that understanding underlying business goals helps us improve the whole project, understanding the business reasons behind a task can help us make sure that we are on the same page. It may not give us a framework to make business decisions, but it will give us a foundation to spot when something is fishy. If the person negotiating the purchase of the London Bridge understood that the goal was to get something magnificent to attract the tourists, he or she would have spotted the flaw in the plan straight away after seeing the real bridge. I’m sure that the old London Bridge, dull as it is, attracts tourists to Lake Havasu in Arisona, but I am equally sure that the Tower Bridge would have done a much better job. It is unlikely that the Tower Bridge was for sale as well, but for the money that these people invested in the whole project, they could have probably built something much much more interesting.
Likewise, a few misunderstood requirements and wrong assumptions are not going to doom a software project, but spending time to understand why something is needed and how that fits into the big picture will make the difference between a mediocre delivery and great results.
Image credits: wallyg, John McCall, Lim CK.
