Communication from SD Best Practices 2008

By Andy Oram
October 29, 2008

Slightly fluffier and frothier than its sister SD West conference, Boston's SD Best Practices conference this year was still a nice mix of updates about the software engineering field and tutorials on potential uses of test frameworks, scripting languages, and other tools to build modern software systems. But the biggest theme I kept running into was the centrality of communicating with users and team members.

Communication took top billing in a recent survey conducted by Scott Ambler and Dr Dobbs Journal. Ambler (Practice Leader of Agile Development at IBM) presented the results at a keynote along with Terry Quatrani (UML Evangelist at IBM), and I had a chance to talk about it later with Ambler.

When asked what tools software developers find most helpful, the survey respondents gave low ratings to modeling packages and other expensive, specialized, hard-to-learn software. The highest ratings went to simple sketches--yes, like scribbling on a napkin in a restaurant. The "tool" might be a digital photo you take of the napkin and send to team members.

Simple word processing software came up high as well.

When I had a chance to talk to Ambler, he said that he routinely polls software engineering experts about the same subject during his talks. They all admit using crude sketches on whiteboards and paper to describe projects and collaborate on developing designs. But not one has put a sketch into a book or article on software engineering. They refuse to recognize what they themselves do on real-life projects--and what the rest of us do too. "That's why nobody listens to you," Ambler tells these experts.

Simplicity and open-ended usability (there's little that could be more open-ended than a blank whiteboard or sheet of paper) doesn't guarantee that a tool is useful. For instance, wikis rated just as low as modeling software on the Dr Dobbs survey. Even professional programmers don't use wikis much during project development.

But the purposes listed by survey respondents for most of the tools they used were consistent: communication, communication, and communication. (It was the most common purpose on traditional, waterfall projects and almost the only purpose listed by agile teams.)

I draw a few conclusions of my own from these bits of data:

  • People like to have as open-ended an environment as possible at design stages of a project. Anything that channels their creativity into some predetermined process or forces them to fill out a form will cramp them, and they will rebel. This does not diminish, in my opinion, the value of contracts, constraints, and other formal interactions during later stages of a project where it's less important to think up a new idea and more important to deliver on the idea that was thought up earlier.
  • Maybe the tool you use is less important than the act of getting people together. "We're not going to leave this room until we've come up with a design" is an effective mechanism for engaging participation, and the tool used to create the design is secondary at best. This would explain why wikis are disdained as development tools; they embody a "Come and help out whenever you feel like it" culture rather than a "We're not going to leave this room" culture.
  • Natural language is great (hey, it's what I've built my whole career on) but it's inadequate for many of the great communication tasks in life. Designing a software system needs a lot of natural language, but other support as well. We probably haven't yet found truly effective forms of support.

I found it interesting that Ambler and Quatrani devote the first twenty minutes of their keynote to a mock face-off between traditional waterfall methodology and agile development. The face-off was at a very basic level, attacking such hoary concepts as piling up specs and documents to drive a project, treating programmers as uncreative implementors barely above the level of clerical workers, and postponing testing till the end of the project.

But when I asked Quatrani point-blank whether she thought conference attendees needed that lesson, she answered firmly in the affirmative. She has found that many people are still navigating the waterfall. Luckily, both her tutorial and many other presentations at the conference covered "best practices" at a modern and sophisticated level.

You might also be interested in:

News Topics

Recommended for You

Got a Question?