As I needed a break after prepping for and teaching a JUnit TDD class I dove lightly, feet first into Ruby last night. Since Ruby’s already comes with OS X this was even a bit easier than I figured. Just playing with Strings so far, but I really like that the unit testing package is in the core libraries, or at least I think it is, I’m really green at this point.

Anyway I could see some real benefits in having something like JUnit included with the core java libraries to really help encourage unit testing.

I ran through a seminar with 7 of my developers today covering JUnit and TDD. Overall I think it went pretty well. I overestimated the material and labs we could get through, and I ended up dumping two labs out of five. Still they got a real hands on experience and I still managed to run through Bob Martin’s Bowling Game Kata.

I snuck in a good bit of pair programming. We had to run the class on our own laptops with only a few to go around, thus all but one of the developers were paired up. As usual I overheard some good conversations debating the best approaches. The one solo developer shot through the labs faster than any of the pairs, but I’m just going to chalk that up to his skill level.

I think by the end of the Bowling Game Kata that a lot of them really got it. Over the next few months we’ll see how well this strategy worked. Next I get to spread the wealth to the rest of our java developers, and lucky for them I’ve worked out some of the kinks in the class with my first group.

The number one request for a follow-up class focused on approaches for testing databases and GUIs.

I was talking code with a very old friend, junior year of high school counts as pretty old for me. Anyway he mentioned that I wrote some scary Perl code that he had to look over back in 1998. I admitted that yes, I was just cutting my teeth on more complex coding at that point and I was in a bit over my head. I remember back then thinking that my solution felt wrong even though the 3000 lines of procedural code worked. I remember thinking only that I felt better that a good bit of the code was modularized into individual functions that were generally not to big.

I had the same feeling the first time I tried to implement unit tests with JUnit about 3 years ago. I did the traditional test the DAOs approach which was really pretty much testing the database. The tests took a good while to run, they broke all the time because the data got out of sync. And any change to the DDL and more test rewriting. My approach just felt wrong, though I couldn’t pin down why. Tomorrow I’ll pass that story along to my developers when I run them through a JUnit class so they can understand that this stuff isn’t necessarily obvious the first time through.

Always leave a failing test at the end of the day or when you have to run off to a meeting. This tip has saved me a good bit of time on more than one occasion. The advantage is you can jump back into your flow a lot faster. Simply run all your tests and jump to the failing one to remind yourself what you were working on. This is even more helpful if you get sucked away for days at a time before returning to some code. Even a test that fails to compile is OK, same idea.

Credit for this tip goes to a presentation from J.B. Rainsberger if my memory serves right.

Since my company is in the process of ramping up the development group on a host of new technologies and we happen to be blessed with management that agrees to invest in training we’ve setup a number of in-house classes over the past 18 months. The general rule unfortunately is that a number of them have been atrocious:

• Instructor is actually a sales guy and knows nothing about the product he’s training on. He actually calls in a sales engineer and for and hour the class hears the powerpoint slides being explained over a Polycom.
• Instructor shows up the first day and explains that he’s never taught the class before and he just got swapped in last week for the real instructor.
• Instructor explains high level concepts for two days and has zero hands on content because he’s never done training in his whole career.
• None of the machines for a class are setup ahead of time so the entire class has to install the nasty IBM Webshpere/Portal/RAD class before even beginning. This takes multiple hours. Halfway through the circuit breaker pops because all the desktops were plugged into one socket and the process has to start all over.
• Out of the prepared labs/demos the instructor can get perhaps 30% to actually work.
• In the afternoon of the first day the instructor points out this is as far as he got reading the slides on the plane so he proceeds to read them out loud for the class for the rest of the afternoon.

The sad part with these stories is we’re often paying about $300-$500 per developer per day to be in the class. So I’m seriously considering giving up on all instructor led training unless it’s low risk. That means I know I’m getting a good instructor who knows what the hell they’re doing, or I’m sending one or two people to the training so if the training sucks we haven’t made much of an investment.