def euler(x); cos(x) + i*sin(x); end

Martin Fowler is a paradox. That is, if you accept one of the common connotations of "enterprise software": evil. "I concentrate on designing enterprise software – looking at what makes a good design and what practices are needed to come up with good design.", says Martin. Yet, he is one of the giants of agile software development. Recently, at the second annual foscon, I won a raffle for a book. The one I selected from those available was Martin's Patterns of Enterprise Application Architecture. If you have not yet listened to his RailsConf 2006 Keynote, I strongly urge you to do so.

A couple days ago, Robby posted about Dialogue Driven Development. We'll leave it to the art historians to decide if the following artifact proves that while sitting together at Martin's talk during RailsConf 2006, I first wrote the words, or jotted them down after Robby summarized one of Martin's points. Robby often encourages "blog early, blog often". So I can hardly complain if he pre-empted me on publishing DDD since RailsConf was over six weeks ago.

The important thing is that DDD is not just another marketing term. Although, it could be useful as one, so we want to distinguish between dialog, those artifacts from desktop applications that we on the web infrequently encounter, and dialogue, n. a discussion between two or more people or groups, esp. one directed toward exploration of a particular subject or resolution of a problem (from my dashboard dictionary).

For me, the -ue is all about user experience. And that is the meat and potatoes of application development that we should be targeting. Don't believe me? Think it's more about business logic, fancy technology, web 2.0, <insert favorite CS concept here>? I don't think so. But, don't take my word for it. You too can pre-empt me on a coming post by heading over and reading, if you have not, Alan Cooper, About Face: The Essentials of User Interface Design.

So, DDD. What we're trying to do is label a concept that is sorely in need of development. To flesh it out a bit from my perspective, here are a few points from Martin's keynote that I found particularly interesting.

martin_keynote.points.each do |point|

• The interesting thing about Rails is that it tries to do things differently than other software over the last few years. It doesn't try to be the one-size-fits-all solution.
• What we are seeing is a drive toward simplicity. Conventional wisdom once was "quick necessarily means dirty". Ruby challenges that. As did Smalltalk, which showed that you could be quick and clean.
• What's important about technology is the way it affects the whole conversation between customer and developers. It affects how we go about building software. The essence of XP from Kent Beck is this change in relationship so it is not a one way stream of "this is what I want": want -> tell -> build -> all is well. People may know what they want, but not what they need. We can build exactly what they want and still fail because it is not what they need.

end

It was after jotting down that last note that I wrote "dialog-based develepment" and then "dialog driven development" in my notes (I know, I misspelled it, too). The DDD term was prompted by the recent conversations Jeremy and I had with Steven Baker and David Goodlad on the train to Chicago about Behavior Driven Development as they worked a bunch on a next-generation RSpec.

My pie in the sky is a Ruby DSL something like RSpec that could be used with clients to talk about the software. It would allow a spectrum from less specific-more tolerant to more-specific-less tolerant. At the left end is client dialogue about behavior of the software. Something like, "app should require login". A "failure" at this high level could be something like, not implemented. The spectrum continues down to the level of BDD with something like RSpec, where the focus is on behavior of the code.

Also on the train, Josh Knowles was strongly advocating for much better acceptance testing. Of course, using iterative development, acceptance testing is not something done at the end, months or years into the project, but should be done frequently. The left end of the spectrum could support this expectation based software behavior dialogue.

Of course, these are very rough ideas. What I want to do is build out the understanding behind the word "collaboration" in the Agile Manifesto and identify how "individuals and interactions" work to create excellent software. Join the fun!