It’s November, and it seems I haven’t posted anything here since January. Partly that’s because I have a Proper Job™ these days, which means I spend a lot less time writing and blogging. Partly I’ve rediscovered the joy of actually programming, which means I get to spend most of my time hacking on code.
This is something of a catch-up post, bringing you up-to-date with some of the things I”ve been up to and some of the topics I intend to be blogging and writing about.
Read More
Well, I certainly didn’t expect that kind of interest in my last post. In the past I’ve tended to have a few hundred people reading my infrequent mumblings. In the last few days nearly 20,000 people have popped by according to my site statistics, leaving nearly 150 comments. Crikey!
The overriding message I got was that without providing evidence and concrete examples one way or the other, it was all a lot of noise about terminology. One of my intentions this year is to expand on some of the implications of Deliberate Discovery, which fit the bill nicely in illustrating programming-as-a-trade, so my next article is the start of a series of posts along that vein. I’ll let the evidence speak for itself and you can draw your own conclusions.
I’ve been very grateful for the feedback and comments, and the dialogue on Twitter. I didn’t spend as long as I might have editing and cleaning up the article, largely because I’d been tinkering with it since before Christmas, rewritten it twice, and decided it was better to publish early and respond iteratively to feedback. Typical – go out without your best underwear and you get run over by a bus.
The critical feedback generally fell into the following categories:
It seems this is a sensitive subject area so I’ll be editing more carefully from now on to try to pre-empt some of the more obvious critiques I left myself open to in the previous post.
Software Craftsmanship risks putting the software at the centre rather than the benefit the software is supposed to deliver, mostly because we are romantics with big egos. Programming is about automating work like crunching data, processing and presenting information, or controlling and automating machines.
Non-programmers don’t care about the aesthetics of software in the same way non-plumbers don’t care about the aesthetics of plumbing – they just want their information in the right place or their hot water to work. (Although it’s fair to say they appreciate decent boiler controls.)
Last year I wrote about how we are doing planning all wrong, or rather, how we seem to focus on the wrong things when we do planning. We obsess about stories and story points and estimation, because that’s what we’ve been taught to do. It reminds me of the story about a man who comes across a drunk standing under a street lamp at night time, staring at the floor. The drunk says he’s looking for his lost keys, and the man says: well they are obviously not here under the lamp or we would see them. No, replies the drunk, I dropped them over there, but it’s dark over there so I decided to search over here instead.
Our street lamp is the Planning Game, which involves writing Stories and Estimating, using Planning Poker or other Estimation Techniques (everything in caps appears in the Agile Literature, and so has been deemed Official).
I suggested we are failing to use the planning time effectively, and that we should be devoting the time to finding out as much useful stuff as we can while everyone was in the same room, and I called this Deliberate Discovery. Marc McNeill commented: “Deliberate discovery. As opposed to accidental discovery? Or any other sort of discovery? Why add the extra word ‘deliberate’?”
Once upon a time there was a lady in a taxi. It took such a long time for the lady to get to her destination in the taxi that she went to the town hall and told the man from the council. The man from the council wanted to figure out why the taxi journey was so slow, so he placed cameras at all the traffic lights in the town to measure how many cars went past, and how quickly. The traffic light cameras would click every time a car went past the lights.
He wanted to speed up the rate of cars, so he changed the layout of the town. He figured if he introduced a one-way system the traffic flow would be more efficient. This confused the taxi drivers and they started to get lost. The taxi driver would go past a light, click, discover he couldn’t go the way he wanted, try to find a way through and find himself going back past the same light, click, realise he had been this way before, turned around and drive back through the light, click, and would still not find his way to the lady’s destination. The new one-way system was good at moving cars around – it just wasn’t very easy to navigate. And just as the taxi drivers were learning the new layout, the man from the council would try a new layout just in case.
What a lot of clicking, thought the man from the council, and what a lot of cars must be driving through my town. How efficient this is! I shall invite more cars into this town because it is so efficient at moving cars around.
I currently have a backlog of about 15 blog articles I am failing to finish. The most embarrassingly laggy one dates from around the end of 2007. Now I know I’m a slacker.
However, others have been far more industrious than me.
The industrious Yukei Wachi has followed up his translation of my Introducing BDD article by producing a Japanese version of What’s in a Story.
Inspired by Yukei’s translation, a Korean developer HongJoo Lee has written a Korean translation of Introducing BDD. How cool is that?
Enormous thanks to you both for your hard work.
Update: HongJoo has also translated What’s in a Story? into Korean.
I am delighted to announce the official Japanese translation of Introducing BDD.
It’s easy to forget how big the Internet is and how small the world can be. Last year I gave a BDD talk at QCon in San Francisco that made its way onto InfoQ.
A Japanese programmer called Yukei Wachi watched it and decided he wanted to know more about BDD. He read my Introducing BDD article and felt it was worth translating into Japanese. He then translated several thousand words in what seemed like no time at all.
Yukei asked me for a couple of sentences to introduce the Japanese translation, and then with typical Japanese modesty decided to drop the part where I thank him. So here is the introduction again with the first sentence intact.
I am thankful to Yukei Wachi for translating this article from English for you, and I am grateful to you for your interest in Behaviour-Driven Development. I hope you find this article useful, and that you enjoy your journey into BDD as much as I have.
Thanks Yukei.
I’m delighted to be taking part in a In the brain of… session organised by the folks at SkillsMatter.
When the SkillsMatter folks actually checked inside my brain and heard the rattling noise, they realised I would need some help, so Liz Keogh – BDD pioneer and project lead for JBehave – will be co-presenting with me. (If you hold Liz up to your ear you can hear The Cure.)
SkillsMatter is a fantastic training organisation that believes in creating and nurturing communities. This event kicks off a London BDD community, which is very exciting for me because it means there is a genuine momentum behind BDD as a movement. This is the first of a series of (mostly free) talks around BDD and automated testing taking place throughout the rest of the year.
The event is free to attend and it takes place at SkillsMatter’s London office on Monday 17 August from 6:30 pm. I expect we’ll go for beer afterwards.
Please register online so we know how many chairs to put out, and I look forward to seeing you there.
Business people want estimates. They want to know how much it’s going to cost them to get a solution, and they want to know how likely it is to come in on time and on budget. And of course quality is not negotiable.
Agile teams I encounter are at best nervous about estimates and at worst simply evasive. “You don’t need estimates if you’re doing Agile,” they say. “It will be ready when it’s done. We’re constantly adding value so we don’t need to commit to a date.”
My favourite exchange goes something like:
“We’ve done an inception and broken down the entire project into stories and measured it, and it’s come in at 400 stories, estimated at 865 story points.”
“865 what?”
“865 story points.”
“So how big is a story point?”
“We don’t know yet, we’ll let you know in a few weeks.”
At a governance and funding level the business could care less about story points. They don’t actually care about stories except that we shove them in their faces with our release plans. They care about solving a problem. They came to us and asked us a) how much will it cost to solve the problem, and b) how confident are we about that number?
So how do we approach that? We go through some sort of inception process that looks something like this:
1. Identify some personas
2. Identify some process flows
3. Start breaking the flows down into stories
4. Lots and lots of stories
5. Lots and lots and lots and lots of stories
6. Spike some technical ideas that came out of the stories
7. Estimate the stories
8. Roll up all the estimates and call that our project estimate
The part where we estimate the stories is a real chore (c’mon – we’re estimating 400 stories here), so we cut corners. We do a first pass as t-shirt sizes (small, medium, large) and then take a representative sample (sounds suitably scientific) and do a “detailed” estimate of those. This involves a bunch of people estimating lots of important-sounding metrics: minimum, likely and maximum size, clarity, volatility (eh?) and whatever else, and then multiply it up to provide a WOOOOAAAAAHHHH! hang on a minute! What were we trying to do again?
There’s a one day domain-driven design event happening at SkillsMatter this Friday, 19 June in London. I’m not speaking this time so I get to sit back and enjoy some talented folks talking about really applying DDD rather than just theoretical stuff.
Eric Evans will be kicking things off at 10am then there are five talks throughout the day. Two sessions I’m particularly looking forward to are Gojko Adzic – who spoke on my “Architecture for Architects” track at QCon earlier this year – talking about DDD in a distributed environment, and mild-mannered superhero Phil Wills from The Guardian talking about how domain-driven design helped them rebuild the http://guardian.co.uk site.
In the interests of full disclosure I’ve been given a complimentary ticket, but in any case the event is well worth the cover price and I’m happy to help publicise it. As I write this, places are still available and you can book online.
