| |
11:28:03 AM |
 |
The Red-Hat Green-Hat Gameä (nothing to do with Linux)
I think the modern equivalent of 40,000 page specifications is lots of test cases that demonstrate what the software should do; document requirements through test code. There's an interesting part in the article where the software team is divided into two teams
- coders who write the code
- testers who try and break the code
And there's a healthy competition between the two. If the test cases are written in software this could amount to one team of people writing test cases to try break the code and another team trying to write bullet proof code to get past the test cases.
I think both teams could learn alot from each other. In particular the testers should really be developers who know how to develop unit and integration testing software. Far too often in the software world testing teams are viewed as people who 'push buttons' rather than people who develop test cases to automatically test software.
I wonder if it'd help if software teams took turns being in both camps? Say 2 weeks a month they spend purely writing test cases to try break a part of the system, the next 2 weeks they spend writing code on another part of the system to try get past the test cases put in place by the other team. This could lead to some healhy competition.
[James Strachan's Radio Weblog]
This IS a really effective way of writing development systems which I frequently put in place in teams on a much smaller level using pair-programming. However I use it for writing finer grained unit-tests rather than acceptance tests.
RULES: Get two developers in front of the same machine and give one of them a red hat to wear and another a green hat. Mr Red's role is to write a small unit-test that fails. In doing so, he clearly expresses the proposed interface and intention of the new code. As soon as he's happy with his failing test, he slides the keyboard over to Mrs Green. Mrs Green's intention is to do just enough work to make the test pass at which point the keyboard is passed back over to Mr Red. Repeat cycle.
This red/green cycle typically takes anywhere between one and ten minutes before they keyboard is passed back to Mr Red. Every so often (a few times a day) the developers switch hats.
The competition is fierce. Mr Red defines the best possible API as possible and the most evil tests. Mrs Green solves the problem set by Mr Red in the most elegant way she can.
Benefits:
- If one developer has a better understanding of what needs to be done or is more familiar with the system than the other, they can express this easily in tests. The other then has a concrete specification to work to and can explore/experiment until they achieve the goal. This is particularly effective for bringing new members of a team up to speed on a system very quickly or bridging a skills gap.
- Both developers are at maximum concentration all the time. It makes it hard for one developer to go off on a tangent whilst the other one stops paying attention, because they need to tackle the problem as a team to achieve the goal. This filters out lone-ranger coders - and the slackers!
- Competition is fierce but friendly between the two. The harder they compete, the better the result.
- The roles are very distinct and clear.
- At the end of the task, both developers walk away with the same knowledge about what the system is supposed to do and how it does it.
- The tester and implementor are working together - there's no chance of misinterpretation.
- Testing and implementing must happen in very small blocks and immediate feedback must be available. The best way to achieve this is through pair programming.
The great thing about this is that it's so easy to get started with. Oh, and you don't actually need hats.
| 
