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).

The Wiki Mindset

Note: This was written in 2007 and left in my drafts. Forgive me if it is not complete. Everyone who has read a popular book on the Internet knows that it was invented by researchers at university as a means to communicate and share information. It was only when the popularity of the medium caused it to leak out into the wider world that we can to accept it as a read-only system. After a decade of education we are ready for all to contribute. First with Forums, later with blogs and now with the Wiki. Each fills a different need - and here we talk about the wiki. What is a Wiki? Put simply, a Wiki is a web site where the reader can contribute, change or correct the content. Readers are no longer passive observers. They have a responsibility in improving the quality of the result. The most famous Wiki is Wikipedia (http://www.wikipedia.org/). I would like to say that a wiki works best for a small team if like-minded technical people, but Wikipedia proves that wrong. Anyone can change a Wikipedia page and the change will be displayed immediately. It is reviewed, can be removed and occasionally starts a war of words - but in general if you add value it sticks. What a Wiki is not

• A wiki is not a multi-media web-site. To allow for maximum interaction it is primarily text with basic formatting.
• A wiki is not for static information. No company wants their brochure changed - even if it could do with clarification.
• A wiki is not for the users in this life. They thrive on sharing and contribution.
• A wiki is not for private or sensitive data - all can read and change.

Who will use a Wiki Wikipedia notwithstanding, a wiki more suites technical staff. I have had more success getting developers (a notorious anti-documentation group) to use a wiki than I have had with business analysts and project managers. I don't think it is the geek factor - or not entirely. I think it is about free communication. Developers have learnt from the open source culture. Everyone gains from cooperation. Unit testing has taught them that more effort now saves time later. All that, and the passion to correct wrongs has overcome some of the dislike for documentation and made the wiki a success. Who will not use a Wiki What can I do with a Wiki Procedures Records and Notes Research Collaboration