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

I recently wrote about the assert_cookie custom test assertion plugin I put together. When I started writing the assertion, it was just a helper method to wrap up the funky logic for testing stuff about a cookie. I wasn’t thinking about tests. And my first tries were definitely not test-driven.

When I was wrapping it up as a plugin, this started bugging me a lot. Especially because my first tries at the assertion method weren’t very good. (Ugh! svn diff -r59:72 http://svn.planetargon.org/rails/plugins/assert_cookie/lib/assert_cookie.rb) But the idea of testing it was confounding. How do you think about testing the tester?

The first thing I had to get straight was what I expected. It basically reduced to expecting the assertion to pass or fail. When an assertion fails, it raises the AssertionFailedError exception. Excellent, now I was making progress.

I started writing tests like:

  
1
2
3
4
5
6
7
8

  
def test_assertion_cookie_is_secure_should_pass_when_cookie_is_secure
  assert_nothing_raised { assert_cookie :secret, :secure => true }
end

def test_assertion_cookie_is_secure_should_fail_when_cookie_is_not_secure
  assert_raise(AssertionFailedError) { assert_cookie :open_secret, 
      :secure => true }
end

and notices a lot of repetition of assert_raise(AssertionFailedError) and assert_nothing_raised. It was ugly to read. I decided to write a couple helper assertions:

  
1
2
3
4
5
6
7
8
9
10

  
def assert_pass
  assert_block("assert_pass must be called with a block.") { block_given? }
  yield
end

def assert_fail
  assert_block("assert_fail must be called with a block.") { block_given? }
  yield
rescue AssertionFailedError
end

The hard part again was figuring out what I was expecting. My first try was to use assert_raise and assert_nothing_raised as before. But those failed miserable because they call yield. I lamented to Andrew that I wished yield would work like raise. After thinking a bit more, I realized I only cared whether an AssertionFailedError exception was raised or not. The previous tests now look like this:

  
1
2
3
4
5
6
7

  
def test_assertion_cookie_is_secure_should_pass_when_cookie_is_secure
  assert_pass { assert_cookie :secret, :secure => true }
end

def test_assertion_cookie_is_secure_should_fail_when_cookie_is_not_secure
  assert_fail { assert_cookie :open_secret, :secure => true }
end

There is one last thing that bugs me. I wanted the tests to run outside of Rails but function correctly in Rails. Rails adds a method to Test::Unit::Assertions called clean_backtrace. I couldn’t figure out how to get that required correctly, so I created a stub in test_helper.rb. Can anyone help me fix this?

Install the plugin with script/plugin install http://svn.planetargon.org/rails/plugins/assert_cookie. Navigate to the vendor/plugins/assert_cookie directory, type rake and watch the tests run. :)

Recently, Robby dropped off his copy of The New Utopians by Robert Boguslaw at my desk with a section marked: “For Whom and For What”. Here are a couple interesting quotes on page 45:

This, then, is one of the fundamental problems of application: on the one hand, the temptation is almost overpowering to establish the techniques and practices of practitioners as handbook truths available in situations of the sort we have termed established. It is the temptation to speak with the same degree of assurance under all professional circumstances as does the familiar stereotype of the TV repairman or journeyman carpenter.

On the other hand, there may be found equally strong temptation to revert to unbridled intuitionism–on the part of those who somehow sense the inadequacy of established situation science applied to emergent situation reality.

This reminded me of the recent blog exchange between Peat and Alex regarding the role of common sense and intuition in application development.

It is an attractive and beguiling illusion that attempts to persuade us to think that if we just apply enough analysis from correct principles, we’ll produce something “correct.” And we should do the analysis first. That pretty siren sings so sweetly over the shipwreck mess of many development projects. The allure is so powerful, of course, because sometimes it is correct. The problem is when to do this and at what scale.

Sometimes it is much better to analyze things first. Some people will say, “First make it correct, then optimize it.” But when speaking with Stefan Kaes at RailsConf 2006 after his talk, I thanked him for pointing out that some consideration for performance must be made up front. To paraphrase his reply, “Absolutely”. Here, the scale is large. Broad decisions are made, not detailed ones. And it is necessary to do it earlier rather than later because this broad decision will dictate the confines under which many small decisions are made that create a structure of significant weight that will resist change.

I was a bit disturbed to read this comparison of Tracer Bullet Development versus eXtreme Programming where it was asserted that TBD uses up-front design while XP does not. Obviously, using XP, you don’t just start randomly writing code. Somewhere, somehow a bunch of decisions were made that create the context in which you start writing tests. Disregarding appropriate situations at which to make preliminary decisions is as dangerous as deciding too much.

Even if we know extremely well the technical details of the small bits of test-driven code we are writing, it’s probably guaranteed that we have but a faint understanding of how those pieces will make a complete application. As Robert points out summarizing Kurt Lewin in “Field Theory and Learning”

In short, it is not … that the whole is more than the sum of its parts; it is different from the some of its parts

There’s more than one way to shoot down a moving target. Dave Thomas and Andy Hunt have used the metaphor of tracer bullets to describe an approach to software development. Martin, Badgerism, Peter, Lights Out Production, and Jeff, in no particular order¹ and among many others, have weighed in with their thoughts.

But how does firing at a moving target with tracer bullets work? It’s a gross over-simplification to say you just fire-aim-fire-aim. In fact, the key to the process is how aiming itself provides immediate feedback to refine aiming. As Dave himself says,

Basically, it all comes down to feedback. The more quickly you can get feedback, the less change you need to get back on target.

So, the process actually goes something like this:

1. you have already acquired a target
2. you have initially aimed the gun
3. you fire and watch where the tracers go
4. you re-aim based on where the target is now in relation to the tracers

That’s a single person aiming, firing, watching, aiming, … That’s a process that is happening over short instants of time. Where you aimed a fraction of a second ago is still visible in the stream of tracer bullets when you adjust your aim.

Now translate that to a team developing software. No longer is it one person. No longer is the feedback loop on the order of fractions of a second. Time stretches to weeks or months between the initial target acquisition and aiming until the feedback comes in. How does that feedback inform the original rationale for the design decisions or even for the target acquisition?

In the process we are refining at PLANET ARGON, we insist that we document the rationale for our design decisions. This includes documenting our discussions with the client and domain experts to identify the goals of the software and its users. This is a very lightweight process, usually about a small paragraph per major design decision. We typically use a wiki to record the documentation and aggregate in the same place useful references, project documentation, interviews, etc.

To some folks, documentation may be a dirty word, something to shun or dread. Not for us. Documentation is simply our way of providing a record of the decisions we make so that feedback can be evaluated in context. From my dashboard dictionary:

documentation, n.

Material that provides official information or evidence or that serves as a record

I’m at a loss to understand how else you would do it. Tracer bullets don’t help you a bit if you are just firing randomly. And I think that’s what people miss about the process. You really do aim first. And if you can’t remember why you aimed where you did, or if the person who did the aiming has left by the time feedback is coming in, that feedback may be interesting, but it certainly isn’t going to enable you to refine your decisions.

¹ Thanks to Robby for providing links to some of these articles

I hate cookies. Or maybe I’m just feeling schizo today. Actually, I do love cookies, just not testing them with Rails.

I’ve added assert_no_cookie method to the assert_cookie plugin. That’s because in your functional tests, cookies['chocolate'] may be something, nil, or an empty array depending on what you’ve just done. For example, in this code I had tried assert_nil cookies['pass'] but that failed because cookies['pass'] was [] after calling cookies.delete :pass in the controller:

  
1
2
3
4
5
6
7
8
9
10
11
12

  
def test_destroy_should_remove_persistent_login_cookie
  post :create, :username => 'brian.ford', :password => 'secret', 
      :remember_me => '1'
  pass = cookies['pass']
  
  @request.cookies['pass'] = cookies['pass']
  post :destroy, :_method => 'delete'
  
  assert_no_cookie :pass
  user = User.find_by_username 'brian.ford'
  assert_nil user.persistent_logins.find_by_pass(pass)
end

Anyway, as before, you can get this by script/plugin http://svn.planetargon.org/rails/plugins/assert_cookie.

And thanks yet again to Pluit Solutions for helping me keep my head straight about how to work with cookies in functional tests. Next stop, a patch for Rails (would a generous soul please donate some time to this so I don’t have to).

I love cookies. There are, of course, tons of varieties and I’m no connoisseur but I love the soft chocolate chip right out of the oven, hot and gooey. But, if you’re like me, you don’t want your Rails code to be gooey.

Last Friday, after spending a good frustrating hour trying to figure out why my tests were failing with a nil when a cookie was expected, I finally tried a google search for “assert cookies”. (A lot of more detailed searches pulled up nothing but Java stuff, a not-so-subtle reminder that Ruby is not yet the dominant language out there.) Seems that Pluit Solutions ran into the same problem. This got me thinking that a nice custom assertion might be in order. Actually, I just wrote a quick helper because that was faster than trying to figure out why Rails wasn’t performing as advertised. But it kept bugging me, so I wrapped it up as a plugin. It’s still rough and tests are coming. Perhaps I’m putting too much into a single assertion. Install it with script/plugin install http://svn.planetargon.org/rails/plugins/assert_cookie. And please send feedback.

The idea is to allow various assertions about cookies using a hash of arguments. In particular, you can do such things as:

  
1
2
3
4
5
6

  
assert_cookie :pass, 
    :value => lambda { |value| UUID.parse(value).valid? }
assert_cookie :yellow, :value => ['sunny', 'days']
assert_cookie :delight, :value => 'yum'
assert_cookie :secret, :path => lambda { |path| path =~ /secret/ }, 
    :secure => true

Several weeks ago when Robby and I started discussing how to better interact with clients, one of our goals was a simpler, more effective process. From my experiences as a math student, I knew that a few carefully chosen symbols along with adherence to a fairly simple structure enabled folks from the world over, with different native languages and different cultures, to discuss mathematics, learn from each other, and understand the topics.

The news press is another profession that makes excellent, effective use of a simple structure to interview people and elicit facts to reconstruct an event at which the reporter was not present. We have a rather high degree of confidence (depending on the media outlet) in the accuracy of the method.

These, among other things, encouraged us to focus on the dialogue we have with our clients. We want to examine the dialogue without any special props or artifacts from a particular methodology. What can we accomplish as knowledgeable people, potentially having different vocabularies and areas of expertise, sitting around a table perhaps with paper and pencil? So far, we’ve mostly posted about these ideas. But our aim is to extend these ideas into identifying patterns of dialogue.

Here’s one: You probably noticed that my posts tend to be pretty long. That’s because, just like the three paragraphs above, I usually try to take time to lay some groundwork, get on the same page. And this is often what I do when talking with someone as well. Perhaps a good name would be the Misunderstanding Prevention Focused Long Intro dialogue pattern. The problem is, unless you’re pretty dedicated about paying attention, I might lose you before I get done painting the whole picture. A different pattern could focus on one small bit of the relevant topic, frequently check understanding, and build out the background to enhance understanding when necessary. To me, that pattern is much more like BDD and follows the principle of not solving a problem you haven’t yet encountered.

Another thing we frequently observe is that any little feature of the software we’re building acts just like a spark in tinder, setting a client off on a runaway course of, “Wouldn’t it be cool if…”. Attempting to blow out that flame before it derails the discussion, we often use totally irrelevant data that has less provocative affect. For example, in a recent prototype showing tagging features, we used names of food as tags, which have absolutely nothing to do with the application. The intent was to prevent the client from starting to think about the “right tags” and focus instead on the features of the tagging process.

We are attempting that sort of process on a bigger scale with clients who seem naturally to obsess on features. We try to structure the dialogue about the user’s goals without referring to the software at all. At first glance, that may seem to increase the likelihood that we will misunderstand what the client wants. But, we find the reverse is true. Feature focus is more likely to contribute to misunderstanding what the client needs. And it prevents the client from learning as well.

What patterns do you observe in your dialogue? When are they appropriate? What are you trying to change about your client interaction?

Growing up in the United States in the late 70’s, early 80’s, futbol was something I knew very little about. Let’s see, we played once in a great while in gym class, my most memorable experience there was taking a hard-kicked ball right in the face. Later in high school, the soccer team was a mere blip on the screen in the shadow of football and baseball. Much later I started playing soccer and, having so much fun, lament that I didn’t play as a kid. The interesting thing to me about soccer (and many games, but you’ll especially appreciate this if you listen to a soccer game on a hispanic radio station) is that the myriad plays and activities that make up the game are all directed toward scoring a goal (and preventing the opposing team from doing so). In other words, the goal of the game is simple and clear, though not easily achieved.

Alex Bunardzic is a champion of what he terms “ethical software”. The idea goes by many names. My favorite is software that doesn’t suck. I highly value Alex’s ideas, so when I read his recent post, Should-Driven Development, I couldn’t easily dismiss his criticisms of Behavior Driven Development. At the same time, I don’t agree that BDD itself is flawed as an approach to creating better software. BDD is a developer’s tool. It’s about coding. Of course, BDD cannot specify the goals of the software. So, if it is expected to, it will fail to produce software that doesn’t suck.

One of the things about Scrum that I think is tremendously valuable, and yet one of those things that makes you say, “Duh!”, is the emphasis on empirical process control. There are three components to that: 1) observability, 2) inspection, and 3) adaptation.

What both Scrum and BDD need to be effective is a clear and accurate statement of the goals. With a goal-directed process you have these components:

1. somewhere you are trying to get to (using a geographic metaphor)
2. some process that accurately compares where you are at with where you want to go
3. a plan to move you incrementally closer to where you want to go
4. a process to evaluate whether your plan got you any closer

Or more briefly: goal, assessment, plan, implementation, feedback and around again and again.

The practice of BDD captures this well. Write the test to capture the expected behavior of the system relative to the goal. The test fails. Write the minimum code necessary to make the test pass. Refactor. And around. The process alternates between writing new tests to describe expected behavior and the code to make the test pass and then refactoring to make the code better without changing its behavior. The process is powerful.

But as I said earlier, it is a developer’s tool. Developers should never be specifying the goals for the software, just as the client and user should never be specifying the implementation. I’m rarely dogmatic, but about that I will be.

The problem that we face is how we can more accurately capture the goals for the software in our dialogue with the clients and users. Our exploration of that is what we are calling d3. One significant part of that is education. Our experience is that everyone from clients to developers begins thinking and talking in terms of the software implementation way, way too early. It’s like talking to an architect about what finishes to use and what the windows look like long before you have established a vague idea of where the walls will be or if there will even be walls. The process is too often backwards. Talking about the minutiea of text field this and that before we have even established why in the world the user would be doing that in the first place. One approach that we are trying is dialoguing with the client about goals without talking at all about the web site. In other words, for that exploration, the web site doesn’t even exist. Talk about thinking outside the tubes.

Another part of this is fostering a general respect for that fact that software that doesn’t suck is constructed according to certain principles. Just because anyone can create an HTML form doesn’t mean they should. As long as we collectively persist in thinking that anything’s possible and therefore it all boils down to a matter of opinion about software design, we will continue to create software that sucks.

So rather than putting down BDD for failing, we need to recognize that right now in the state of our craft there is a huge chasm between client interaction to establish goals for the software and the much lower level development that can excel through application of BDD.

What we need to develop is how to dialogue to create common understanding. What I am noticing as I try hard to be more aware of how we are communicating with clients is that “process” and “process artifacts” can often be counter-productive and obscure issues. If we are just trying to “fill in” the boxes in our process, are we stopping to really listen? It’s like assertiveness training where you are taught to reframe your expressions using “I” statements. Rather than, “you are really pissing me off” someone might as an initial stab try “I feel like you are really pissing me off”. Yeah, not very effective. Try that with your girlfriend if you don’t believe me. More effective is, “I feel hurt when you say you don’t want to play with my new Mephisto blog.” One approach attempts to conform to the structure of assertiveness, one effectively conforms to the principles. What are the principles of effective dialogue?

I think it’s obvious to everyone that Scrum and the product backlog are not the same thing. Sometimes stating the obvious is useful. Scrum is a structured process of which the product backlog is a part. Mechanism Alley has posted an excellent, thoughtful article about Scrum with some references to some of what we’ve been saying about d3. It’s worth a careful read. In fact, I want to personally thank MSM for not perceiving our comments as an invitation to start flaming about this or that pet methodology.

I certainly don’t want our conversations about Scrum to be alienating to any of the excellent folks working hard under the agile umbrella. Further, I don’t want Scrum only to be the focus of these conversations. Finally, I’m not particularly interested in pumping another meme through the well-oiled Rails machine. Are we restating things said by others? Hell yes! We are standing on the shoulders of giants.

What I find a bit disturbing is that while I said a number of things about Scrum, only what Robby and I have said about the product backlog is getting attention. Further, the responses seem to fall generally into three categories:

1. the literature we read misrepresented the Scrum process
2. we have misunderstood the literature
3. the way the commenter uses the product backlog involves a lot of conversation, not a lot of dictation

Firstly, the book I referred to, Agile Project Management with Scrum by Ken Schwaber seems to be a good source. It seems consistent with everything knowledgeable people have posted about Scrum. And it clearly advocates agile methods. Consider this quote:

You can get through almost anything if you don’t try to impose rigid solutions before problems even arise, instead devising solutions as necessary when problems crop up. (pg 131)

That’s from chapter 9, Scaling Projects Using Scrum, which described application of Scrum to a difficult project and discussed solutions implemented in the spirit of Scrum but rather far outside of a “typical” Scrum process (if such could be argued to exist).

Secondly, we are not claiming to be Scrum experts, but that said, I don’t think I’m misunderstanding the literature. What we are aiming at are things that we think could be better understood and articulated. Just like the agile manifesto doesn’t prescribe a “right” way, it’s clear there are many implementations of agile processes. At the same time, the agile manifesto is certainly opinionated about certain processes being preferred for (and I would go as far as saying essential to) effectively creating software.

Thirdly, commenters that relate, in their experience, how much conversation is required around and facilitated by the product backlog are contributing to our confidence that there is a lot to say and understand about the dialogues we are having. Further, we are really interested in dialogues we are having with clients. We are finding this to be very challenging at best.

As Robby recently pointed out in a conversation with me, development processes often seem geared toward making the developers look good based on all the items they’ve checked off the list of the client’s wants. “See, we’ve delivered everything you’ve asked for, and on time even!” Yet through these processes, we (collectively) continue to successfully create software that sucks! We think that’s because it’s extraordinarily challenging to get processes to be goal directed based on requirements versus solutions. The way we get to this is through a lot of dialogue. We want to better understand the process and patterns of this dialogue.

And, ultimately, whether you are using Scrum or some other process under the agile umbrella, knowledge of how to conduct and facilitate this dialogue will be extremely valuable to you. So, please help us understand how you dialogue. If the product backlog is an artifact in this, please help us understand how?

If you don’t get a chance to hang out on our irc channel much (#planetargon on irc.freenode.net), you may have missed some of the innovations on the horizon for Rails: We’ll let you know when the nuclear-powered Rails beta is up for testing.

Anyway, Happy Birthday Rails!

Firstly, a disclaimer in the words of the inimitable Ken Kesey:

Take what you can use and let the rest go by.

Interestingly, when I googled this quote to ensure I was recalling it correctly, I found some other excellent quotes. Another that seems apropos:

You don’t plow under the corn because the seed was planted with a neighbor’s shovel.

If Dialog Driven Development is merely rounded corners to you, please continue to enjoy your square ones. This exploration is not aimed at gathering the true believers. I’m not the evangelist type. So, if you’re worried I’ll show up on your doorstep thumping my bible, rest assured I won’t. I’m an atheist.

That said, I think there is value in creating distinctions to better understand the terrain. Agile is a big umbrella. If the processes were formulaic, all we would need to worry about is a good algorithm.

Recently on a flight to DC to meet with a new client, I delved into a book Robby brought along: Agile Project Management with Scrum by Ken Schwaber, one of the co-founders of the Scrum method. Below are a few notes I jotted down on my index cards while reading the first 4 chapters and browsing the appendices. Since then I’ve browsed some of the other chapters but I haven’t finished the book.

advantages of Scrum

• emphasis on empirical process control
• iterations
• daily team meetings where each member presents what she did in the past 24 hours, what she’ll do in the next 24 hours, and any blockers
• frequent feedback loop
• clear separation of responsibility using the pigs and chickens metaphor to facilitate more effective decision making and reduce interference by chickens, which can bog down the process
• The three legs that hold up the implementation of empirical process control: 1) visibility - aspects that affect the outcome must be visible to those controlling the process; 2) inspection - these aspects must be inspected frequently enough to change course if necessary before too much has elapsed; and 3) adaptation - changing course when new information suggests it is necessary
• emphasis on having a vision, it must be a vision that is fairly resistant to change in order to guide the project, but able to change when required

”You can get through almost anything if you don’t try to impose rigid solutions before problems even arise, instead devising solutions as necessary when problems crop up.” (page 131)

drawbacks to Scrum

• specifying the product backlog - this suggests too much dictation and not enough collaboration. According to the book, the product owner specifies the backlog and prioritizes the items in it. The team meets to decide which items it can deliver in the next sprint. That process is two monologues not a dialogue.
• 30-day sprint is too long. I don’t think the feedback cycle is nearly as effective at this scale because we need feedback long before functionality is “deliverable”. More frequent testing is needed to refine features. Imagine getting a haircut where you tell the stylist what you want. She then takes you to a room with no mirrors and starts chopping away. When she’s done she takes you to another room to demo your new haircut. Fortunately, the difference between a bad haircut and a good one is about 2 weeks. The same is hardly true of software.

The process of software development requires a lot of educating of the people involved. The product backlog does not encourage thinking in this way. I dislike the sequential list where the only explicit organizing idea is priority. Where is the context and relation between what is being specified? And how does the process ensure that the product owner doesn’t fall back to specifying things like, “Dialog X needs a dropdown field to display Y”, or “Build a screen to display user stats”? If you haven’t had to deal with this, then I desperately want to come visit your universe. If you don’t know why this is the biggest ingredient in a recipe for disaster, just continue building software this way.

The way to challenge this is with true, effective dialogue. What that looks like varies a lot. But it’s not about particular artifacts. If you read Manley’s criticism of our rounded corners, he relates the necessity of educating product owners. If dialogue is at the center of your process, the product backlog could function as a passable way to document the evolving mutual understanding.

My favorite idiocy in software development is the crystal ball method. Everyone has a crystal ball on their desks from which they can conjure a precise, detailed, perfectly focused picture of any event at any point in the future. Of course, this is an absolute absurdity. But that doesn’t stop people from believing such feats are possible. The product backlog easily falls prey to this delusion.

A much more useful metaphor is based on the simple fact of vision that any sighted person can appreciate. From where I stand, there are a number of things in crisp focus. Beyond that, things are mostly distinguishable by shape and relationship. I’m seeing the forest. Beyond that, only the vaguest, broadest features are distinguishable. I see that mountain, but the dark areas juxtaposing the snow may be forest or exposed rock. I can’t tell.

Attempting to draw on this fact of vision to inform and structure dialogue about a recent project, we set up a wiki with a page to capture descriptions of the software’s behavior in terms of goals. We have three sections: 1) near term goals, 2) medium range goals, and 3) long range goals. These follow the rough divisions of visual clarity described above.

The process of transforming those goals into software features and determining their priority based on architectural constraints is not something a client can dictate. You don’t tell your architect how to construct your house, you describe what you want in it. The reason for that is simple: physics dictates what is a viable structure. In software, we have no appreciation for physics. Clients believe they can do anything. All the rusting hulks of failed software littering the desert notwithstanding.

The essential way to bring the analogue of physics to software development is mutual education mediated by effective dialogue. What that actually looks like needs a great deal of definition. If this is just rounded corners on existing work, please point us in the right direction.

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!

We all love the spluge (spam deluge), don’t we? Usually spam is so abnoxiously and obviously stupid it is easy to ignore. And, gmail does a wonderful job of ensuring I deal with very little of it. However, once in a while something comes through. A trend I’ve noticed recently are emails that begin with “This is an advertisement…” I’ve never read one careful but it’s possible, but unlikely, that I somehow asked to receive it.

Today, I got an odd email. I first thought to dismiss it, but upon reading it I decided it was either the best crafted bit of spam, or an honest mistake. Then I was faced with a decision: round-file it, or be a good Samaritan and let the guy know. Here’s the email:

Subject: travel to Missoula

Thanks for getting the reservation at Downtown Motel. The fellow I talked to said “no available rooms the entire weekend”. I’ll put >it on my credit card when I get there.

I’ve encountered another problem with scheduling. I ordered my airline tickets through Priceline.Com and now they tell me there is no record of my order. The airlines now want about $400 more because of the short notice. Consequently, I’m going to drive and will pick up Quincy and your mother. We will arrive sometime late Friday and stay through Sunday. See you then.

                                    Love,  Uncle John

Ultimately, I decided to reply:

Hi John,

I’m sorry, but you’ve reached the wrong email box.

Forgive my suspicion, but if you do happen to be a spammer and are using this as a ploy to get a response from this email address, rest assured a real person lives here and I’ll haunt your sleep forever if you continue to spam me. However, also note that, if you are a spammer, all your future spam will flutter totally un-noticed by me into my big circular bit bucket to live out eternity in utter unacknowledgement.

Hope the trip goes well.

Cheers.

What do you think–was it spam? Would you have replied? The analogy is walking down the city street, only talking to our friends, eyeing with suspicion and from a distance any stranger we happen across. Do we need to recreate this dynamic on the tubes (pipes? I forget) as well, or can we allow for greater friendliness?