The Yawning Crevasse of Doom

Martin Fowler and Dan North gave a talk at QCON London 2007 about communication gaps.

They started about by describing the cost of communications gaps between customers, users and developers. This cost is obvious in systems that completely fail, but sometimes the cost is not apparent like when about 70% of features delivered are hardly or never used. In this case there is also a cost of failed opportunity to create something more valuable instead. These are costs that we do not even notice.

They suggest 2 approaches to close the communication gap:

1. Ferry men approach: A group of people act as intermediary. They are ferried between the business folks and the developers and act as translators. The business people never talk to the developers.

2. Bridge approach: Provide structure and mechanism for direct communication between developers and business people.

Dan and Martin prefer to use bridges than to ferry men. Dan gives an example of how different solutions can result out of this direct communication or even entire new requirements can appear. He recalls working on a project were the business folks required some printing functionality. When probed, it was discovered that printing was needed to key in data from the printout into another system. Instead of printing and rekeying, Dan suggested to simply sending the data directly to the other system. This was a simple solution that would not have come out if there wasn’t any direct communication so that the developer could really understand what the problem is.

They give 2 reasons for preferring the bridge or the ferry.

1. Efficiency of communication: Use analyst to enable everyone to share knowledge instead of just being a conveyer of information.

2. Caring and Motivation. Having direct contact, you can actually see who you are making a difference for. That is more motivating then looking at a requirements document.

Next, Dan and Martin discuss what techniques effect communication and help us build the bridge:





1. Programming languages: Need tools to build abstractions that work well within the business context domain. Domain driven design tries to ensure that there is a common language used to talk about the business and the code. OO design allow for abstraction. Focus your language on business unit you are working with. Make model context specific. Better to have multiple models instead of one huge model. Also, when doing demos, try to use real data as examples as it enhances communication

2. Domain specific languages: Build languages that are more readable to the business sides.

3. SOA: If SOA is done right it can help build that bridge.

4. XP – values, communication, usability, stories, story boards, interaction design.

5. Best requirements come after the product gets into production. Put feature into production and offer it for a subset of users and monitor how it is used and then determine the requirements and tweaking needed.

6. Done: TDD and acceptance test driven testing helps define done. Concrete cases help developers come up with design abstraction.

Dan and Martin stress the notion of thinking about feedback. Use it to test if we are talking properly. You have to understand the other person and be able to walk in their shoes. Feedback can come from automated testing, showcases or demos, frequent planning and re-planning. What’s important will change over time. Feedback should be used to drive out assumptions. There are assumptions in what design should be, assumptions in what the problem is and assumptions in what done is.

Always figure out who the stakeholders are. If the stakeholders glaze and do not understand what you are talking about then you might be talking to the wrong stakeholders. You need to find the right one.

Another problem can result from separating people who build software from the people that maintain it. We need to organize around long term engagements instead of doing projects and moving on to the next one. Example, off shoring your help desk makes feedback loop much worse. Off shoring can work if teams are fully autonomous with developers, testers, analyst, business people, etc… And these teams constantly talk to each other.

Productivity matters because you have more time for feedback and you have more times for running experiments.

Dan and Martin wrap up by summarizing that there is a big communication gap between clients and developers. Using a bridge is much better than a ferry. Always look into how a certain technique effects or improves the bridge. Look at techniques that involve feedback loops to help promote frequent communication. The most important thing we can do is to physically put people together.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Fowler-North-Crevasse-of-Doom