QCon 2007 Notes: Yawning Crevasse of Doom

Martin Fowler and Dan North, The Yawning Crevasse of Doom. Or, the cost of the communications gap.

The thrust of the argument is not new to Intelliware, where we practice in-room customer presence as often as we can get away with it, but there are still many points worth noting.

  • Say, to start of the metaphor, that to cross a crevasse you could use a bridge or a ferry.
    • Ferry: professional intermediaries who act as interpreters, low bandwidth, and entrenches the gap
    • Bridge: higher bandwidth, and involves actual people from both sides rubbing together
  • The business people can get so used to technical limitations of processes that they consider them (wrongly) part of the business process: always question this. (North told how some business people who were adamant that something needed to be printed eventually admitted that it was just being printed so it could be carried across a room and re-entered someone else. When the techies pointed out that data transfer could be done over the wire, the business people were delighted.)
  • Direct contact between techies and business people can also be motivating: you end up caring more about the project when you see the people you’re building the system for.
  • MF and DN prefer bridges over ferries. Particularly, to explode the metaphor, since a ferry wouldn’t be much good with a crevasse…
  • What about programming languages as bridges? They help us build abstractions. Let’s make them communicative abstractions (following Eric Evans’ ubiquitous language)
  • MF notes that enterprise-wide models (e.g. the NHS) may be too damned hard, but there’s nothing wrong with having several models in different contexts across a single enterprise.
  • Even when you’re using dummy data, make it a subset of the real data, so the business people will see more clearly what the app “does” than they would with “data” that is meaningless to them
  • Make DSLs at least readable by business folk. They don’t need to be able to write in them, though sometimes they do, but they definitely should be able to read them.
  • DN: “At the end of the day, most of our software is used by people, who are squishy and irrational”
  • The most useful feedback on a product is after you’ve shipped a limited release and you’re watching how it’s used in the wild.
  • There are big communication problems around two words: enough and done
    • Acceptance-test-driven planning gives the business people and the techies a shared definition of done. This is important. Also check out Behaviour-Driven Development.
  • How do we work on bridge-building?
    • Seek feedback on how you communicate
    • Have automated tests
    • Have frequent show and tells
  • Feedback smokes out wrong assumptions
    • Are the specs wrong?
    • Are we solving the real problem?
    • Who are the real stake-holders?
      • If your listeners glaze over, you’re talking to the wrong person: find the right person instead
  • The handover to maintenance can be the worst moment on a project:
    • It breaks the feedback loop so you never learn whether you made the right decisions
    • Off-shoring the helpdesk is even worse: the helpdesk people are the people who find out about problems first. Don’t break that loop.
  • DN notes that off-shoring can work, but like Fowler’s first law of distributed systems (don’t), you have to offshore a whole team, not have the business in one place and the tech in another. It takes much more overhead, but it may be the only way to make it work.
  • Productivity is important because it lowers the threshold for trying experiments.
    • Say you try six things, five die, but the sixth is brilliant, and makes up for all the rest
  • There isa crevasse: and that’s the biggest problem. We need bridges, and better bridges:
    • Feedback loops are very important
    • Put the business people and the techies in one room
      • This leads to emergent behaviour changes

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply