NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
Sunday October 05, 2003
Some Modest Success
After a week or so, it seems that the Perl XP Training Project is a modest success. We've gone from an idea and a mostly-blank wiki to well-tested, fairly clean, working code. I hope to have a (simple but) working game in a couple of weeks.
What has helped?
- Strong contributions from others I'm very impressed with the quality and frequency of incoming code.
- Being explicit about my goals.
- Responding quickly to patches (though I'm not perfect about it).
- Giving suggested implementation details on story cards.
- Posting coding guidelines (with the appropriate Perltidy rules).
- Posting my
- Me writing customer tests (when I have time beforehand).
What could be better?
I'm really the bottleneck. We've a couple of really quick contributors who need very little handholding and guidance, but I just need the time to read over the code and apply it. With a little guidance and more planning on my part, I will need to do less and less. (The point of being a good mentor is to work yourself out of a job. I'm all for that.)
What have I learned so far?
- Have more story cards ready. I put up a page for blue sky ideas, partly to get my thoughts in order, partly to get feedback and new ideas, and partly to let people see and revise the vision for what's ahead.
- Have customer tests ready. A couple of the story cards had ambiguous ideas. While it's tricky to write a customer test you're not writing the code at the same time it's immensely valuable. Granted, there's a greater than normal possibility the test will need to be changed, but tests are a great way to communicate your goals.
- Give up more responsibilities to contributors. Once we have a skeleton system, it'll be workable to suggest fewer implementation details. Perhaps I'll put up more story cards and let everyone brainstorm the details or perhaps I'll suggest that the story holder should come up with tasks. That also means someone will have to write customer tests, which is a good skill to impart to other people.
I don't know yet if you could organize a normal open source project in this fashion, but there are several positive signs so far.
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.