I’ve been having difficulty recently with a trend I’m seeing on projects. What happens is this: we (an agile development team) engage with a client for a short period—typically 2-4 weeks—to investigate how we might work with them to solve their problem. During this period, we drive out lots of stories, do some technical investigation and estimation, and out of this we generate a high level release plan. All very good, you might think. But then, unfortunately, everything is mysteriously forgotten about except the release plan, which suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Well ok, it’s not quite that dramatic, but it certainly doesn’t feel very agile to me. Hopefully I can explain why.
At the beginning of this year I wrote a feature article for Better Software magazine, which was published as “Behavior Modification” back in March.
The article is now available on my site. It gives an overview of behaviour-driven development, from its origins as a coaching aid for TDD through to its current form as a proven, comprehensive development approach.
Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”. Since then it has grown into a respectable and proven agile methodology (with a small “m” of course).
Dave Astels, the award-winning author, was an early adopter of BDD and has been instrumental in raising its profile. He presented it at Canada on Rails and is taking it to JAOO and SD Best Practices. He has even presented it to Google. His Ruby BDD framework, rspec, has inspired a number of similar projects.
I was lucky enough to attend the Software Architecture Workshop in Cortina recently. It was a three day workshop based around the idea of Open Spaces, which involves handing the asylum keys to the inmates and seeing what happens.
I convened a session called “What’s so hard about Event-Driven Programming?” to explore the experiences of the other delegates in designing, implementing and testing asynchronous, event- or message-driven systems. I took the position that actually it was all very straightforward as long as you followed a few basic principles. Another delegate, Mats Helander, took the opposing view that asynchronous, event-based systems could develop scary emergent behaviour that would lead to a world of hurt.
Charles Simonyi introduced himself at a recent workshop with the words: “I was at Xerox PARC in the 70s, Microsoft in the 80s, and working on intentional software in the 90s”. He wasn’t showing off, he was just there. He pioneered WYSIWYG, created Microsoft Word, Excel and Access (as a data visualization tool), championed OO and invented metaprogramming.
What this tells me is that when Charles Simonyi thinks he is on to something, it’s probably worth listening. (Ok, I’ll forgive him szHungarian notation.) For the last 15 years, Charles has been on to intentional programming.