Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Farewell to 'Design Techniques'

JavaWorld columnist closes with a brief history of his column, hints at what's to come

By Bill Venners, JavaWorld.com, 04/01/99

Page 2 of 5

Although a few relevant topics remain that I haven't yet covered in the Design Techniques column, the time has come for me to turn my attention to actually writing the book, Flexible Java. I'll be publishing the text of the book-in-progress on my Web site, artima.com, so you can follow along as I go. I'll also keep the discussion forum open, and I encourage any feedback you may have to offer. If you want to receive periodic updates of my progress, you can join my mailing list. (See Resources for links to all of these things.)

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.