Behaviour Driven Development

Craig Dunn sent me some reading material today introducing BDD or Behaviour Driven Development.

Basically it explains what I always thought TDD should be, and suggests that BDD is merely TDD 'done right' and with a name change to make us start thinking in terms of behaviour specification rather than code verification. Very worthwhile read...

Philosophy of development?

We're having a bit of a group think about our project management methodology here at pblMedia. A colleague, Peter Kearney, sent the following interesting email which I quote (almost) in full.

Most people don't realise this - but the methodologies we use for ... project management ... are quite remarkably influenced by philosophy:

From the late 1800's to about the 1980's and 90's a philosophical paradigm known as Positivism dominated almost every aspect of thinking and shaped many of the ideas we have about how things should be done today. Positivism is grounded in empiricism and the idea that reality is an objective thing. In a project management context this would lead to thinking as tasks and user requirements as things that can be defined absolutely. You can see that the waterfall method would be a natural response to this paradigm of thought.

Interpretivism started in about the 1920's but really only managed to get serious recognition in the last couple of decades. This philosophy is based on the idea that reality is not absolute - its in our minds. This paradigm recognises that our perception of reality changes depending on the circumstances we are in. In our world - this means that users perception of reality IS reality and that reality therefore changes as users circumstances change. You can see that agile is much more aligned to this way of thinking.

The trick though is to find the middle ground between positivism and interpretivism. Both are right: realities such as budgets are absolute, but realities such as user expectations are not. The ultimate trick in all of this is not to force rigid adherence to a primary scope of work, but rather to help users and stakeholders to shape their expectations to fit the budget and the reality that is evolving in their minds as the system is being developed.

Well I found it interesting anyway. This also reminds me of the Wind and Sun Aesop's fable

The North Wind and the Sun were disputing which was the stronger, when a traveler came along wrapped in a warm cloak.
They agreed that the one who first succeeded in making the traveler take his cloak off should be considered stronger than the other.
Then the North Wind blew as hard as he could, but the more he blew the more closely did the traveler fold his cloak around him;
and at last the North Wind gave up the attempt. Then the Sun shined out warmly, and immediately the traveler took off his cloak.
And so the North Wind was obliged to confess that the Sun was the stronger of the two.

The moral was stated at the end of the fable as: Persuasion is better than force. The history of project management has focused on imposing more and more process and up-front planning and forcing the project to comply with the initial plan. Newer agile techniques have focused on persuading the project to a conclusion, through constant adjustment to changing requirements, collaboration of project team members, and ensuring developed (rather than planned) functionality meets business expectations.

Dividing application work horizontally rather than vertically

My colleague and I took a trip to the Microsoft SDC in Sydney the other week as part of an 'open day', where MS staff and partners described their development and project management methodology - basically a flavour of Scrum. Although a lot of what they are doing is very similar to our own process (which is a good sign I guess) there were a few things I thought worth considering. One of these was horizontal allocation of tasks amongst developers

Basically they advocated splitting the development of functions / user stories into tasks to be divided amongst several developers according to the tiers in the architecture. Whereas we (and many others) normally assign a single function/story to a single developer to code the entire stack (DA, BO, UI) they would assign this work to three developers. The argument they put forward for this was skill specialisation - a data access developer has a different set of expertise than a user interface developer.

Whilst I agree with this to some extent, no developer I know would be happy to be stuck working in a single tier of the app for the entire project.

However thinking about this more, if we did enforce the standard that the tiers of a single story must be developed by different developers what would be the outcome:
1. Developers would have to talk more about the design before coding
2. No single developer would come up with the design
3. Separation of responsibilities of each tier in the app would be easier to enforce (you'd need at least two developers to collude to change the design). Coupling between tiers would hopefully be minimised.
4. Each developer would know about more parts of the application.
5. More stories would be completed within an iteration (rather than having multiple stories still being worked on by individual developers at the end of the iteration, we'd have one or two being worked on at the end)
6. If developers worked on different 'tiers' for different stories there would also be more consistency in terms of coding style - patterns, naming, layout, etc
7. Higher chance of code re-use since developers would know about more areas of the application.
All of these are positive effects, completely inline with the tenets of agile - collective code ownership, collaborative design, pair programming (sort of). I can't really see any downside to this except a co-ordination issue (we need _something_ for project managers to do!), though the proof will be in the doing..

Now I'm off to find a suitable project and some developer guinea pigs...