You can have your cake and eat it, as long as you bake it carefully.
‘We can do this the quick way and pay later, or the thorough way and pay now.’ This seems to be a fundamental dichotomy in software development, between ‘perfectionism’ and ‘pragmatism’, but I do not think it has to be a trade-off at all.
Or how programmers and testers can work together for a happy and fulfilling life.
Why don’t we just automate all the testing? Is test coverage a useful metric? What does it mean to “shift testing left”? When and where should we be testing? How much is enough testing?
Most of my work these days is helping organisations figure out how to be more effective, in terms of how quickly they can identify and respond to the needs of their external and internal customers, and how well their response meets those needs. This tends to be easy enough in the small; the challenges appear as we try to scale these techniques to the hundreds, thousands or tens of thousands of people.
Modern Scrum is a certification-laden minefield of detailed practises and roles. To legitimately describe oneself as a Scrum Master or Product Owner involves an expensive two day certification class taught by someone who in turn took an eye-wateringly expensive Scrum Trainer class, from one of the competing factions of “Professional” or “Certified” (but ironically not both) schools of Scrum training. But it was not always so.
[Adventures With Agile interviewed me recently ahead of teaching a couple of classes with them in June. The original interview is on their blog.]
My first job was playing Star Wars for a living. True story! I had a student internship in 1988 with a games company called Domark. They published the 8-bit versions of movie and board game tie-ins like Star Wars and Trivial Pursuit on home computers like the ZX Spectrum or Commodore 64. If someone called and said they had found a glitch on level 8 of The Empire Strikes Back, I needed to know what they were talking about.
tl;dr: Send us your examples of real world BDD. Read on to find out why.
“What is BDD?”
“How can I tell if I’m ‘doing BDD right’? Or wrong? Is there even such a thing?”
“Where should I start?”
“Is this or that practise considered part of BDD?”
“What are the mandatory ”core“ practises of BDD?”
These and similar questions were the topic of the closing panel at the recent CukeUp conference in London.
A question came up on the BDD list recently, and based on feedback I thought it would be useful to post my answer to a wider audience.
Some software teams get stuck because their business users don’t realise they need to make time to take delivery of features they’ve requested. Over time their User Acceptance Testing backlog increases to the point where the team’s throughput virtually stalls.
I’m having fun in the most unlikely of places. I’m currently working at a Big American Bank. In fact, it’s so big it’s called Bank of America. I recently wrote an article for their internal agile magazine which probably best describes why I think it’s so much fun, and which I’ve reproduced below.
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.
At the end of 2009 I left the world of agile delivery and consulting to join a small team in a trading firm. I was member number three. The team grew to five in the next few weeks. This team was the most insanely effective delivery machine I’ve ever been a part of. A handful of programmers sitting in amongst a handful of traders, producing state-of-the-art trading systems—with all the integration pain (back office, risk management, connecting to electronic exchanges) that involves—in weeks. Not months, weeks. This is, of course, impossible.
I’ve just come back from the excellent NDC 2012 event in Oslo, where they published my article about opportunity cost in The Developer magazine ahead of the conference.
I’ve noticed a number of people recently declaring that BDD really is just TDD, such as Robert Martin on Twitter and Ron Jeffries on the XP list. I can understand where this mindset comes from and I’d like to offer my perspective.
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.