The Artima Developer Community
Sponsored Link

Farewell to 'Design Techniques'
by Bill Venners
First Published in JavaWorld, March 1999

<<  Page 2 of 5  >>

Advertisement

Software development as 'conversation'
I was recently a guest at an object-oriented design seminar taught by Bruce Eckel and Larry O'Brien. At one point in their seminar, Bruce and Larry gave the attendees a two-page "statement of work" for a software project. The attendees separated into groups of four or five, and each group began discussing how it would design software to meet the requirements set out in the statement of work. I roamed from group to group, listening and participating in the discussions. While each group had its own personality, the groups had much in common. In particular, I saw in all the groups the same basic process in action, a process I'd seen over and over in real software projects on which I'd worked. I like to call this process "the conversation."

I see the software development process as a conversation because throughout the entire process people must communicate with one another, and the effectiveness of that communication is critical to the success of the project. In the beginning of a project, for example, some person or group must decide on and communicate the requirements of the project. These requirements may come in many forms, from an offhand verbal comment in the hallway to a series of meetings that results in a formal written document. Regardless, a target must be defined and in some way presented to the programmers who will be drawing the bow and firing the arrow. This is the first aspect of the conversation.

Once (the initial version of) the requirements has been defined and communicated, developers must get together at some point and discuss how to build a system that meets those requirements. It is this part of the conversation that I was observing at Bruce and Larry's workshop: a group of developers sitting around a table, brainstorming, naming things, drawing diagrams, debating, laughing, arguing, insisting, compromising, deciding. This fleshing out of a design given the requirements is yet another aspect of the conversation. Not only must the group decide on a design via group interaction, it must also in some way communicate the design to others who will help write the code.

Somewhere along the way, of course, code must get written, and even this activity is part of the conversation. The code is part of the conversation because developers on the same team must often, by looking at the code, understand what the other developers have done. Any changes made must then be understood by developers who come to the code later. So when you write code you aren't just communicating with the computer (telling it what to do), you are also communicating with any other programmers who may ever look at your code.

There are many other aspects of the conversation. The people who test the software must understand what it is they are testing. Managers must communicate with developers, developers with managers, developers with other developers, managers with other managers, and so on. Throughout the lifetime of the project, small and large corrections in direction must be communicated. Priorities shift. Requirements change. Unforeseen problems are uncovered along the way. All these things must be effectively communicated as the process continues.

<<  Page 2 of 5  >>


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us