Meta-Warning: This post is not meant as criticism of any individual or group
I just joined the testdrivendevelopment yahoo group, and saw an announcement for this public workshop by Ron Jeffries and Chet Hendrickson.
Offhand, it sounds really great. Listen to this intro:
Is "Agile" tasting a bit watered down to you these days? Would you like a stiff drink from the bottle under the bar? Then we're the guys to set you up.
Let's go and hang out at the Tech Center Marriott in Denver. You'll join a roomful of people with experience and interest in Agile, where we'll run through a series of exercises that will show you what we mean when we talk about Agile and XP and what software development should really be like. We'll work together so that we can all become more successful and can feel when we are stepping off the path that leads to success.
Super-Cool. Really, this sounds great. I'm excited, and thinking about sending out notes to all around to encourage this, come home and talk about it, and so on.
Then I read on ...
We'd like you to bring a laptop, with Eclipse 3.2, Java 5, JUnit 4, FitNesse, and Subclipse, ready to go. We'll be working in pairs, so if you can't bring a laptop, let us know.
Ah, there's the rub.
There are a bunch of nifty tools in Java (and, to some extent, smalltalk) that all hook together to make a certain brand of agile development work. This includes the magical automated acceptance tests with fixtures.
You come to the workshop, have fun, learn stuff ... then go home to code in PL/SQL or Delphi with none of the tool infrastructure, and you are back to square one.
The over-reliance of tools concerns me a bit. For example, I know of one training company that trains on lean-agile testing that teaches Fitnesse exclusively. I am _CERTAIN_ that a large number of attendees - perhaps a half, or two-thirds, learn about how great things "could be", then go home with no real change in the way they do work.
That's not helping - it's drive-by training. At least Ron and Chet can help ... if you code in Java, and you don't have any significant testing challenges.
This gets me thinking of a workshop day that meets you where you are and helps you build a custom testing framework for your office - to put things in place to do better testing and test automation. A few years ago, Brett Pettichord did a class on "Homebrew Test Automation", but otherwise, I see a gap for this kind of training in the software testing space.
That's not meant as a criticism. It's an opportunity ...
1 comment:
You present an interesting challenge. I think the challenge you present is "How can I as a course attendee assure that I am receiving maximum value from the course?" That may not be the challenge you intended, but that was my first impression on reading your posting.
I just registered our top programmer to attend Ron and Chet's course in Denver, so I've spent some recent time thinking about that course and what I want from it. The programmer will attend the course in June with the intent of learning from the masters, and returning with ideas for improvement.
I manage a team of Java developers that switched to XP in March of 2003. We have made more than our share of mistakes, have learned a lot from our mistakes, and are continuing to learn. We fit Ron and Chet's course almost perfectly.
If Ron and Chet's course had been web centered, using Ruby on Rails, or had been Smalltalk based, or using some other methodology (Crystal, DSMD, Scrum, etc.), I would not have registered that programmer for the course. He would not have had enough context to be successful.
I think our development tools are a proper and natural part of our development ecosystem. I'm confident the student who has experience in Java and in the Java IDE world will get more from Ron and Chet's class than those who do not, and those who cannot use that environment should probably not attend the course.
I would worry more about the thrashing effect of a developer testing course which did not focus on a specific developer tool set. Choosing a specific tool set allows the teacher to remove many variables from the discussion so they can rapidly teach concepts like "red, green, refactor" without spending time deciding if pyunit, nunit, junit, TestNG, or utplsql is the right choice for the user.
Post a Comment