BDD, FitNesse and the SDLC - The Triggers

My two main areas of interest in my software design career has been user interaction and an integrated SDLC. For now I am going to talk about the latter.

When developing projects alone, the difficulties were minimised. I am good at all the tasks from requirements gathering (one of my favourites) to release. Anything not recorded in writing was still in my mind and would come to light during design or development.

Over the last decade I have been involved in, run or managed larger and larger teams. I have always wanted to connect procedures from requirements gathering all the way to release testing in a way that is suitable to all parties and consistent (read automated). On the way I have...

... Unit tested everything. I originally experimented with my Adept libraries. I found a few problems, but not many for the effort involved. And the upkeep as I refactor or add to the library was unmaintainable. When you are designing you don't want to be distracted with testing. This was prior to TDD (Test Driven Development). I then worked with teams that required full unit testing. As 2IC I was responsible for code reviews. Developers don't have the incentive to write good tests nor the data to write meaningful tests. It is obvious that unit tests only work if they are part of the design, not the implementation. Enter TDD. I insisted on unit testing on the last project I lead in 2006/7. Unit testing is better than no verification prior to release. For my own code I no longer write unit tests. The benefits are few for such a large overhead.

... XP (eXtreme Programming). I have implemented facets of XP over the years. I have also worked with people who have treated it as dogma - and turned off their brains in favour of following XP to the letter. I managed a team using XPlanner a few years ago and liked the results. The morning and iteration end meetings were very valuable and I was able to use the story-card and iteration data to satisfy the progress reporting needs of project managers and clients.

... TDD (Test Driven Development). I could never 'get into' TDD personally. When I was in the throws of software design I did not want to think in terms of tests. Too much wood not enough forest. I did have the opportunity to see it in practice with an XP specialist. This confirmed my view that it was too slow and ineffective.

... BDD (Behaviour Driven Development). So, how does a name change help? Conceptually I like the perspective. I felt no desire to us it while it had to be from a code developer perspective - such as rspec. Cucumber and Concordion both connect specifications from a higher perspective to be implemented. Tempting, but still a bit of a straight-jacket.

... UI Design during discovery phase. For projects with considerable data entry I worked a system where the UI could be instantaneously and easily by the BA so that the customer could get instant feedback. It is part of discovery because the customer understands their requirements better after hands-on interaction with an unbuilt system.

... Used Fitnesse as an integration test tool during a late testing phase of a big project.

... Read up on BDD - specifically this article on BDD in the analysis/design phases - http://blog.dannorth.net/introducing-bdd/.

... Reviewed the latest FitNesse updates to support BDD - plain text tables and scenarios.

At last almost all the frameworks and tools are in place for me to realise my desire to automate connection in discovery, requirements gathering, analysis, architecture, design, built, release, support and update phases.

Over the next period I will be putting together the concepts and tools for BDSDLC (Behaviour Driven Software Development Lifecycle).