d3 not DDD
6 comments Latest by MSM Thu, 10 Aug 2006 00:40:48 GMT
First, a quick update from our sponsors…
Brian and I talked yesterday and agreed to stop referring to Dialogue-Driven Development as DDD. We’ll leave that for the Domain-Driven Design fans. From now one, the short version for Dialogue-Driven Development will be d3.
MSM posted an email in regards to d3 on a Scrum development mailing list. He writes, “While I believe there’s room for plenty of Agile methodologies in the world and wouldn’t want to discourage the development of DDD if it helps them get their software written, I would hate to see Scrum described inaccurately, especially in a well-oiled meme propagation machine like the Rails community.” (link)
Michael D. Ivey responded with, “That being said…as someone who has gotten 100% into Rails development, I find myself using Scrum less. At least, on the surface, official Scrum. Rails makes meW^WWlets me be so productive that we are basically having 1 day sprints.
What’s interesting here is that we have a someone who is working with Ruby on Rails and finds himself using Scrum less because the environment is much different. This is exactly why Brian and I started seeking out something even more lightweight. We’re not aiming to replace other methodologies, but to structure our own that focuses on dialogue. With Rails, we’re finding that the amount of collaboration and dialogue with clients has both increased and improved tremendously.
Ivey also goes on to say, “I believe, having done Scrum well, and having done the ””Rails experience,”” that what Robby and …. the other guy …. are describing with ””Dialogue Driven Development”” is exactly what happens when you start with Scrum or something Scrummy, add a hyper-productive programming language and framework, mixin a very active and interactive customer, and then just start running at a comfortable pace and see when you get somewhere cool.
Perhaps Michael is right… and of course, this is open for discussion. :-)
Brian and I are spending a good deal of time thinking and talking about this stuff. We want to outline a new pattern that changes how requirements are gathered and documented through dialogue. It’s apparent that as we read different peoples comments on our articles that the general consensus is to interpret the Product Backlog pattern described in the books on Scrum in a way that works best for your team. The approach outlined in Agile Software Development with Scrum doesn’t work for us.
What’s your pattern? Share your story…
It was doubly confusing for me, since “DDD” makes me think of the Data Display Debugger first. :)
Are we knocking down strawmen? There are many Agile methodologies out there, and Scrum doesn’t claim to be the most lightweight.
The methodology being described here sounds like a minor mutation of Extreme Programming to fit the Ruby universe. The Java-based XP teams I’ve been on operated almost identically to ‘d3’. The complexity and size of Java code requires iterations measured in weeks, and a more formalized pair-programming arrangement.
But as I’ve applied XP to Ruby teams/projects, the same processes take on a slightly different look:
So unless I’m completely off-track (it does happen, frequently :) ), Dialogue-Driven Development is just Ruby-ized Extreme Programming.
And it has worked extremely well with the Ruby projects I’m involved with.
But brasten, they’ve given it a whole new name and that makes it new, right? :-P
- Dan
Yes. :)
I should add that the fact this really isn’t anything new isn’t a BAD thing. XP works well, and I think we’re now seeing that XP is a better fit with Ruby than it was with previous languages.
I hate to say it, but this really smacks of buzzword generation… does anyone really believe any revolutionary new way to get anything done is being created here? Good developers already know how to communicate with their clients without talking for weeks about how to do it and what web 2.0 name to give it.
This is the type of thing that gets RoR types a reputation for the “add rounded corners, call it something new” approach.
Sorry, but I’ve been in the industry a long time and I’m deeply cynical whenever someone things they’ve created something new as opposed to rehashing old ideas and putting a new name on it.
I still maintain that you have misread Schwaber and the purpose of the product backlog, but I wish you the best of luck. Whatever you call it and whatever you do, may all your tests eventually pass and your clients pay on time.