This is a story about amazing customer service being undermined by poor software, in the form of simplistic business rules and fragile systems. I am telling it because I made a promise to someone who features prominently in the story, and whose manager should be aware just how fantastic their staff are, and just how much their poorly designed computer systems and cost-cutting are letting their company down.
My friend Gojko Adzic has been running a series of BDD quizzes illustrating different ways to approach some interesting BDD situations. I noticed on Twitter that Seb Rose, another BDDer (Cucumberer?), had gently taken issue with one of Gokjo’s solutions so I thought I’d take a look at them both. Before reading on I recommend reading Gojko’s solution and Seb’s response for context.
Experienced delivery folks can have surprisingly good instincts for macro-level estimation, as long as we are careful to manage blind spots and cognitive biases. This can be an important tool in early project investment discussions, and can remove roadblocks where people are uncomfortable or unwilling to provide estimates.
The goal of software delivery is to minimise the lead time to business impact. Everything else is detail.
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!
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.
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.
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.
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.
It’s finally happening - I’m writing a book! Well ok, the remarkable David Chelimsky is writing a book. It’s called Behaviour Driven Development with RSpec, Cucumber and Friends and myself and a few other folks are contributing in varying degrees.