Test Driven Development Example

I recently presented Clarke Ching's TDD in Excel example to upper management at the company I work for. The example follows through the development of an Integer to Roman numeral converter using Excel as the test harness. It took about 35 minutes to get to 15 fully refactored and 10 minutes for questions and discussion. I was nervous as hell but managed to get through the code with out too many problems. I thought I was clunky in places but one of the managers said the presentation was really slick so it must have looked better from the outside. I volunteered to present it again for any team that was interested so I should have some more experience for when I do it at Agile Scotland (http://agilescotland.blogspot.com/) later this month.


All the feedback so far has been really positive. One of the other managers said it was excellent at getting the point of TDD across. We talked about clean, beautiful code and how it motivates programmers. I think it was the first time my boss had heard of that or even considered that producing high quality code could motivate programmers. I don't think he's ever heard off that before but many of the managers listening started chipping in examples of their own. It was really good.


As a demo for managers I think that it really stood up. It got the point across without losing them. I think some of the programming was beyond my boss (he's not a programmer after all) but the frequent switches back to the tests kept him interested and he could see the power when I made a mistake, got instant feedback, fix it and ran the tests again. I think 15 was enough for this demo. When I was doing 1 – 8 there is a slight stall before you refactor at 8 and I think next time I'll try to fill that somehow. Apart from that it went swimmingly


Here is the example if you'd like to try it for yourself



http://www.clarkeching.com/2006/04/test_driven_dev.html

Agile Scotland

Last night I attended an Agile Scotland prescentation by Ben Fuchs and Joseph Pelrine(http://www.metaprog.com/blogs/)on the Social and Psycological Challenges of Agile Development. It was a very interesting talk taking the form of an Agile project. Questions were gained requested from the floor, costed by the speakers and prioritised by the audience with a show of hands. The topic covered everything from "How to deal with problem personalities" to "Agile Communism". The whole talk was good but the two highlights for me were the story of the bees and Joseph berating Agile by the book.

Joseph said that if you're doing Agile by the book then you're not doing Agile at all. Agile is about continuiosly looking at and improving your process. The book is just a starting point. If you're doing 10, 11 or 12 of the practices it doesn't matter, what matters is if you're using these techniques to ship high software faster and better than ever before.

The story of the bees was told by Ben Fuchs. I'm not sure where he got it but it's a story about organisations and their model of sustainability. It goes like this. When a Bee finds pollen it returns to the hive and does a dance to let the other bees know where the pollen is. Most of the bees, about 80%, head off to collenct the pollen from the new source. Most but not all. 20% fly off in random directions scouting for new sources of pollen. If those 20% didn't look for future sources then the hive would starve. If 100% of the bees gathered the pollen there would be no new sources of pollen and the hive would die.

Here is another blog covering the talk that Ben and Joseph are giving throughout the country http://jw.fi/2006/03/17/agile-complexity-and-friends/

Thanks to Clarke and Agile Scotland for arranging this event.

Satggered-Iterative-Waterfall

I found this explination of the Staggered-Iterative-Waterfall (Anti-)Pattern. This is a pattern of development where teams spend iterations on a single stage in the traditional waterfall cycle i.e. Analysis - Design - Implementation - each stage takes an iteration. To make sure that all teams are working you stagger the work. Analysis Team on iteration 3 - Development Team on iteration 2 - Testing team on iteration 1.

I'm interested in this pattern especially because that is exactly the half way house that I am working in at the moment. Kane has some interesting conclusions about how teams end up adopting this methodology, he blames the overloaded use of the word iteration between RUP and Agile.

A very interesting read

Kane Mar Blog Part 1
Kane Mar Blog Part 2

Workspace

Here are a couple or articles on your workspace. workspace is very important and often overlooked in offices. As the article says the close eye can tell who a person wants to be and who they are from there workspace. Interesting stuff.

http://www.stevepavlina.com/blog/2005/12/creating-a-productive-workspace/
http://pronoia.wordpress.com/2006/05/08/set-up-your-workspace/

Iterative development

I just heard one of my fellow developers blaming iterative development for missing pieces of a design, "That's iterative development for you" and it made me think about the balance of up front design to iterative learning. This is always a problem. Design too far in teh future and you may be wasting time. Not far enough and ou may have to change the implementation more often. There is a balance, a sweet spot and every project is different.

Just a thought.