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.

I’m in the usual crunch mode before doing a presentation or in this case a class on Monday for six of my developers. I’m not sure how much material I really have and whether it’s possibly too much or not quite enough for a whole day.

The class is on unit testing and I’ll have some of the developers pairing up on laptops because our corporate technical training lab is booked for some HR thing for the next few weeks. I’m covering JUnit and plenty of examples including Bob Martin’s semi-famous Bowling Game Kata. It’ll be a mix of presentation, labs, and problems we work though as a group. I’m not the world’s greatest instructor, but I’m hoping my enthusiasm and pointing out all the benefits of TDD will help. I plan on leaving a few logical bugs in the code for the labs just to trip them up and force them to think about how the unit tests help them track down annoying little bugs in the code quickly. And I’m going to hit them over the head running tests every few minutes until hopefully it dawns on them that the intense feedback is a very nice side effect.

Anyway I’ll blog about how the class went when I get through it. It’s really a beta with some of my best developers before I roll it out to the larger development organization. If a few of them really get the TDD bug then I think I’m much more likely to get unit testing really adopted at our shop. “Keep the bar green to keep the code clean.”

Had a talk today with a group of our senior developers and the topic of discussion turned to our first official pilot Scrum project which just celebrated it’s first Sprint. One of the developers pointed out that it was a small project and now the users wanted to add all these extra features so it was going to stretch the project out a few months. So what benefit was it really?

As one who has drunk the Kool-Aid I pointed out that the point was even though the coding wasn’t that difficult except for the fact that the two developers had to learn JSF and IBM Websphere Portal in a single month to deploy it it wasn’t really the impressive part. The impressive part was that the software was deployable today and it had more features than the existing application it was replacing.

Under our normal process it would have taken at least 3 months to get the application to the same state. The customer would have to create a charter, then the PM would have to do some planning and determine the team. Then the business analyst would spend weeks writing up the requirements in “The System Shall …” style. That would have to be signed off before the technical analysis could start. Then weeks later the design document would be signed off on after a few rounds of reviews. Then coding would take place and it would be delivered to QA. Then QA would write test plans and start testing. Finally, UA testing would happen and then the app could get scheduled for production. Now on the pilot they delivered all of this in a single month.

At that point I think a lot of the developers in the room really saw the difference an Agile process can make.

It’s annual review time around my organization again, so I’ve just sent out my review meeting notices and copies of my employee’s reviews. I prefer to send them out in advance so they’ve actually had a chance to read them before the meeting. Otherwise they spend the first few minutes scanning the review as fast as possible.

Sometimes though you have a review or two that isn’t likely to be that much fun to give and in that case I picked up this tip from Dick Grote:

“If the person you’re appraising is a marginal performer with a bad rating, wait until the beginning of the meeting to hand over the appraisal. This increases your control of the situation.”

— pg. 117 of Performance Appraisal Question and Answer Book</p>