This talk will be completely non-technical, aimed at anyone interested in how we learn and why we rebel when faced with Yet Another Change Programme.

BDD and DDD at Stockholm Javaforum

As an added bonus – for me at least – I’m going to be talking to the Stockholm Javaforum on Tuesday 8th April at 7pm. When I initially agreed to this I thought it would be a handful of geeks hanging out and talking about Java. It turns out they regularly draw around 200 people. And they’ve sold out. Yikes.

I’ve got an hour to talk about the relationship between Domain-Driven Design and Behaviour-Driven Development. I have no idea how I’ll be able to limit that to one hour but I’m going to try my best. This is timely because I am also working on an article explaining my take on DDD and BDD. Honest.

James was planning to talk about best practices, and it seems we have similar opinions about them. I would encourage you to read his wonderful blog article where he rigourously deconstructs the phrase¹, and then just as eloquently picks apart the arguments of anyone who disagrees. So I thought I would do something around the same topic.

I wrote it up as an article and the kind folks at InfoQ published it, and the Øredev team has put up a video of the talk. (For some reason I can’t get it to work in firefox on ubuntu, but I’m pretty sure the guy on the left is me).

¹ I didn’t realise until long after Øredev that he was the author of that article. It made me very happy when I found out.

A couple of years ago Joe Walnes and I gave a talk at an XP Day entitled “Awesome Acceptance Testing” (blame Joe for the title). We looked at motivations for acceptance testing and discussed various strategies, tools and techniques. But mostly it was an opportunity to get a bunch of people in a room and find out what they thought and what they were up to in the acceptance testing space.

If you didn’t get to see it and it sounds like fun, we’ll be rerunning the session strip poker pc gameinternet spieleholdem poker regelnonline poker anbieteronline poker für anfängerregeln für pokerwww poker net deholdem poker gameonline poker auf deutschholdem poker downloadtexas holdem poker onlinepoker game netpoker regeln raisepoker softwarewww texas holdempc game poker texaskostenlose online spiele pokertexas holdem gratispoker spiel setonline poker depoker gratis vollversionpoker browser gamepoker spielepoker flash gameparadise poker bonusonline seven card studpoker americano gratistexas holdem online gratispoker texas holdem gratisgratis giocare a poker onlinetexas holdem gratis7 card stud online7 card stud gratisvideo poker gratispoker flash on linewww super poker comtorneo pokergiochi omaha poker in lineapoker 5 draw,draw poker,draw poker on linestreep poker gratistexas holdem no limitpoker roomgioca a poker gratispoker in tourtornei di poker onlinepoker on line multiplayergiochi omaha pokergioca pokertexas holdem rulesplay wize poker at SPA 2008 in March. I hope to see you there.

It occurred to me that “bottle opener” is a great example of goal-oriented vocabulary. The device itself is actually a cap remover, and it only works on one particular design of metal cap. The reason I use it, however, is to enable me to get to the beer in the bottle. Hence “bottle opener” rather than “cap remover”.

The task is just detail

There is more to this than just linguistic curiosity. If you use task-oriented vocabulary it can cause you to focus on the means rather than the goal, which in turn can limit your options. My favourite example of this is the term “search engine”. Searching is the activity I have to do because I’ve misplaced my keys and I’m locked outside. What I want is a find engine!

Google realises this. When I type something into Google, it guesses what I’m likely to be trying to find, not what I happen to be typing into the box. If I type in “Stockholm map”, I’m likely to be looking for a map of Stockholm (first three results are actual maps – presented as pictures) or some information about the town itself. If I type “hotels Stockholm” I’m probably planning a trip there and voila! lots of useful results for the traveller. Other “search” engines do just that – they search, and produce lists of results. It’s then down to me to sift out the ones I care about to get me closer to my goal.

“Blur” on a problem

We talk about “focusing on a problem” in order to solve it. This is a task-oriented phrase. An alternative would be to stand far enough back that you see the problem in its proper perspective. If anything you are “blurring” on the problem – deliberately losing focus on the detail to see if any larger-scale structure emerges.

I often describe BDD as outside-in development. You start at the outside with an automated scenario, and work inwards, discovering services and collaborators as you go, until you’re done. With a legacy application it can be difficult to remain outside enough, or to get a good enough frame of reference for “done”. Blurring can help with this.

For the last six months I’ve been involved in restructuring and re-architecting a legacy code base. It’s been quite a major undertaking, and has involved a number of false starts and dead ends. (I’m planning to write it up as an experience report at some point, but given my current throughput of things I plan to write, don’t expect it any time soon.) During this project, I’ve often found myself struggling to choose between alternative strategies, or unsure of where to go next. In these situations I’ve found that stepping back and “blurring” gives me enough perspective for one of the alternatives to become “obvious”. In fact a couple of my teammates have picked up on this and will actually suggest it as an activity when we are pairing. “We’re thrashing here – let’s step back and start from the outside again.”

It could be as simple as asking “whose responsibility is this feature?” or “who is the actual client of this method call?”. You don’t need to know the answers – just verbalising the questions can give you enough “blur” to gain a better perspective.

Blur on time as well as space

Linus Torvalds recently gave a talk where he said the problem with source control isn’t branching, it’s merging. Again, by taking a broader perspective – in this case temporal rather than spatial – his insight is that the goal is a successful merge some time in the future, not the task of branching now.

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

Props to James Lewis for helping me formulate these ideas. And for being really good at perspective.

Apologies especially to the lovely people whose blogs I host and who have been extremely patient with me over the last few days.

Because stable is about a year out of date, it is several versions behind fast-moving projects like WordPress, so I have some more fiddling to do before permalinks or comments will be working again.

If you are running Debian/testing in a Virtuozzo VPS, check your kernel version. It seems Virtuozzo uses a broken RedHat 2.6.9 kernel which simply doesn’t work with current Debian/testing packages. If your VPS provider uses a broken kernel, DO NOT UPGRADE libc6 to the current version (2.7) otherwise your system will simply die on its feet. It’s incredible – /bin/ls stops working, so does SSH (so you can’t log in to fix it!) – in fact it seems a huge weakness in the Debian setup. I would have expected the core admin packages and system binaries to be statically linked to avoid exactly this problem. A statically-linked busybox helped me enormously here while I monkey-patched it enough to get it to boot.

For the record, here’s my experience so far:

Places to back up

• /etc (all the system settings)
• /home (also contains /home/vmail where all the virtual mailboxes live
• /var/lib/mysql (lots of WordPress databases)
• /usr/share/wordpress/wp-content (mostly for themes and plugins)
• /var/www (wikis)

I’m quite pleased things were this well organised. I thought I might be looking for files all over the place.

Things that worked

• openssh with my existing config and keys. Hurrah!
• postfix and dovecot. Although that’s hardly surprising – they are both rock solid and quite stable. I just rsync’ed the mail directories and settings back and they both started working. After a recommendation by Steve Purcell I’ve been using dovecot as my IMAP server and authentication daemon with postfix and they are a joy.
• apache2. Enough said.
• mysql 5. I’m really starting to like mysql.
• moinmoin. Needed some love. Actually I needed to clear out all the caches before it would work, and install packages moinmoin-common and python-moinmoin, and of course libapache2-mod-python.

Things that don’t work

• Apache2 mod-fcgi. I was having problems with this before which went away when I upgraded to Debian/testing, so I’m assuming it just doesn’t work properly in Debian/stable.
• Apache2 mod-svn. It just doesn’t exist in stable, and neither does mod_dav, so I can’t do funky internet filesystem things for my Windows friends.

Things I’m still struggling with

• Links in WordPress. This is bound to be something really obvious that I’ll work out after a good night’s sleep. It seems ok for some blogs and not for others, so it might be to do with the themes. Update: it turns out I needed a /usr/share/wordpress/.htaccess owned by the apache user with the appropriate rewrite rules in it – thanks Ben Coleman for sorting that out.

So far my VPS hosting company, Solar VPS, have been great with any support requests I’ve made. I really hope they come through with an up-to-date kernel so I can dist-upgrade everything back to Debian/testing. Update: Virtuozzo has no plans to upgrade the kernel before its next major release, so I’m stuck with Debian Stable (Etch).