Introducing BDD

I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.

The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.

A Classic Introduction to SOA

During the past few years, service-oriented architecture (SOA) has become a mainstream approach for designing and developing enterprise software. As with most new technologies, the adoption of SOA has been led by software vendors and shaped by their particular tools and sales targets. Naturally it is in the vendors’ interest to emphasize the complexity of SOA and then provide a timely and profitable solution. This leads many systems architects into a technology-centric view of SOA, when, in fact, the most important criteria for a service-oriented architect — before tackling the technology — should be a keen understanding of the business.

The Art of Misdirection

Watch the magician. Watch how he drops a coin into his hand, closes his hand, shows you the closed hand, opens it with a flourish, and the coin is gone! He smiles. You look to his other hand. He turns it over and opens it with the same flourish. Not there either! Then he takes your hand, closes it into a fist, opens it and there is the coin! Now watch again. This time watch the other hand. As he turns the upper hand over and makes a fist you see the coin slip into the lower hand in a much smaller movement. He opens the empty hand and moves the lower hand to the top. Ignore the obvious movement. Notice instead how he guides the coin between his middle fingers. Ignore how he opens the other hand and instead see him discreetly drop the coin into the first hand again. Finally feel how he slides the coin into your palm as he closes your fingers. Magic? Perhaps not. But a classic illusion.

What's in a Story?

Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria.

Better Best Practices

Organisations often introduce Best Practices as part of a change program or quality initiative. These can tauke a number of forms, from “cook books” and cheat sheets to full-blown consultant-led methodologies, complete with the requisite auditing and accreditation. This article introduces the Dreyfus learning model to challenge the strategy of naively applying Best Practices, and shows how they can not only fail to help, but even have a severe negative impact on your top performers.