e-Columns

July 2005: The Power of Visual Communications

Few things are more demotivating than receiving, and having to work with, a 300-page document or a long string of spaghetti code. None of us can ever be as neat and clear as we may want, but there are some sound principles of visual communication that are important in development. We often forget how much the visual aspect of a document, let alone code, affects what we remember and how we approach reading it.

Whenever we manage a project, we insist on the following clear, visual communications from our development team.

• An easy-to–read specification. We require clearly written specifications at the right level of detail. The test for this is that it has to be easy to skim. The fact is, most of us naturally skim on a first read, and if the document does not stand up to this, then it is likely to be a challenge to pierce. But an easy-to-read specification helps to make sure that our team is on the same page before we get too far along.
  
• Clean code. Again, we use the skim test. We do not tolerate any code that a senior developer cannot skim-check. It has to be simple and clear for us to be able to maintain it, and because we know that, we know how important it is to be subjecting it to the skim-test as we go.
  
• A shared schedule. Of course, the goal is to avoid any slippage on schedule, but this is often unrealistic. We have to be able to see what everyone is doing with clear, demonstrable milestones. If there’s slip, we can spot it early, so that we are not surprised. By seeing repeatedly how the project is going, whether through dashboards or some other means, the accountability factor is clear.

In our 35 years of experience developing products, we find that it is often not the technical skills or product ideas, but a commitment to clear communication that makes or breaks the project. And far too often, communications are the first thing to go when a project is late or in trouble. But by creating good habits with visual communications, skim checking and shared scheduling, we can all do our best to avoid this trap.