Turning an exercise into the real thing with extreme programming
Archive - Originally posted on "The Horse's Mouth" - 2010-09-11 23:08:03 - Graham EllisShould a private course that's being booked run for 2 days or 3? Or on a longer subject for 5 days or 4? I'm often left having to make a recommendation. Budget constraints, and more critically the constraints on the length of time that people can be released from their other tasks, favor a shorter course. The ability to go into things deeper, the ability to have time to go off the immediate topic and fill in associated subjects, the chance to re-explain some of the topics that are hard to grasp in their full glory in one bite, and the ability to release delegates to check email / do other daily tasks also come in to play.
But if a course is "rounded up" rather than "rounded down", it also allows for longer practical sessions - allowing the students to really try out the things we're talking about, and to do so thoroughly. Now you may suggest that's making my life easier as they're working on their own - but actually they're not. I'm then spending time with delegates on a one on one basis, helping them through their own specific questions, issues. For those who finish quickly, it's also a change to talk through there own data, or for me to show them extras and other useful things I can optionally include with the course for the more advanced candidates.
Last week's course was "rounded up". And it made for a much more relaxed course from which the delegates gained a very great deal. It also gave me a chance to conclude the course with something which is a bit of a luxury - the icing on the cake ...
... we concluded the course with a "put it all together" practical.
If you have come across "Extreme programming", you'll have heard all about things like spike solutions and multiple stories. And you'll be familiar with frequent testing and integration and perhaps pair programming. And this end-of-course exercise was an excellent vehicle to apply these, as well as helping my delegates get to grips with the application of Lua.
With eight widely varied delegates, how could I set them all the same practical? How could I manage / tutor all 8? Easy - I turn them into four pairs, and set up four projects not eight:
• The weaker one types, the stronger one advises.
• Two programmers discuss, plan and iron out issues early.
• The specifications and stories are robust.
• Multiple inputs ensure that 'way out' solutions do not prevail.
• One plays Devil's advocate to the others hypotheses
• Test data comes from two minds not one - obvious doesn't get missed.
• I have more time to give per project.
and in real life
• The customer has an author available for backup and support rather than finding that (s)he is on holiday / maternity / off sick / left!
I'm delighted to report it went really well! The room was abuzz with conversations between the various pairs and code was thought out so well ahead of time that it worked crisply and cleanly - very few experimental "spike" solutions were actually needed.
The story(ies) set related to the customer's requirements and so what they were doing was really very much their necessary thing. "We came on a course, and the exercise turned into learning on the real job".
I was really chuffed when the delegates carefully copied their final session's work onto memory sticks - with that session being the spike solution that will be refactored and reworked into their real data extraction task.