Sometimes you just have to have a little fun. Nerf arms race, anyone?

A few days ago my developers explained that they were being randomly shot with nerf darts in their collocated cubicles by the QA tester. Next day, one of the mainframe developers picks up a nerf gun. The web developers were a little grumpy about being shot at. Manger must fix problem.

That involved stopping by Target on a lunch break and picking up three nice nerf guns including a Bazooka which shoots 60 feet in the air. I then snuck the munitions to the web developers and left them to their own devices. One of the three declared that he was only going to set his up in his cube as a deterrent. For the other two I think they had some fun sending a few darts and bazooka rounds over the cubes.

Even in corporate IT development shops it helps to relive a little dotcom fun. I still miss the foosball tables myself.

Tomorrow at the standup for this project I’ll have a simple explanation:

**“Yesterday, I fueled an arms race and provided nerf munitions to three web developers.”

“Today, I’ll be participating in a code review.”

“My impediment is I don’t feel comfortable submitting a nerf expense report to Finance.”
**

We’ve had an issue with one of our project builds that cruisecontrol can’t successfully checkout from CVS using maven 2. We went ahead and just manually logged into the build box and just ran a

before each build. It works, but it’s clunky.

I tried luntbuild about a month or so ago, but I couldn’t get it to build. Then yesterday I pulled down Hudson, after seeing a short link to it on Cote’s blog. Web based, helpful documentation, and a pretty nice looking interface. After a few hours of troubleshooting I got our problematic build running successfully. The only disadvantages that I haven’t resolved yet seem to be:

• The emails it sends out don’t include a lot of information, you have to link back to the web site to see the details.
• Merging in checkstyle reports doesn’t seem to be an option.
• Linking in artifacts like clover reports isn’t done on a simple link from the front of the build page, you have to navigate through the directory structure.

Not sure if we’ll just move to Hudson for our default continuos integration server, but I think cruisecontrol is getting outpaced by numerous other options.

Peter Moore from Cenqua Software stopped by for a customer visit late last week. Turns out he’s in the Bay area for a few months and Sacramento is just a short jaunt down the road.

We’ve been beta testing Crucible, their code review tool, since June. We’re pretty happy with it as it fits the lightweight toolset quite nicely. It also comes bundled with Fisheye, which at first glance seemed like a simple browsesable CVS repository. Fisheye has turned out to a useful addition alerting people to the direction of our entire corporate codebase is going. Everything from noticing direct JDBC calls in some old code to people deciding to check a PHP project into:

/source/java/php

Anyway Pete asked for our overall impression of Crucible, features that we thought might be missing, things that bugged us about the product. We have had a few things:

• Currently Crucible sends an email after every comment, this ends up being a lot of email for coders used to only getting 5-10 emails per day.
• When setting up a review it defaults to the latest diff of a file instead of the whole file. Since we’re not nearly that rigorous it makes more sense to review the entire file when we do a code review. You can switch it to the whole file, but you have to remember a few extra clicks.
• The whole thing has a nice AJAX flavor, simply click anywhere in the code and add a comment right away, but some of the button labels and layouts still confuse a few of our developers. So a little more usability polishing might be in order.

None of these issues are really big deals for us and given the functionality available even in June we would have gladly purchased it at that point. So if you’re looking for a really lightweight web based code review tool, Crucible is worth checking out.

Sounds like it will come out of early beta in the near future so more people can take a look at it for themselves. Without necessarily meaning to they’ve carved out a small niche with a lightweight review process versus many of the heavier process tools. And it’s really nice as I’ve said before to deal with a small shop of pure developers who build tools for other developers.

Macs have been gaining a strong foothold among your leading edge developers especially in the Java world for a while, but a few nights back at the local java users group I glanced around and noticed:

• 3 Macbook Pros
• 2 Macbooks
• 1 iBook
• 2 Windows laptops

Maybe Macs are crossing the chasm from innovators and early adopters to an early majority.

A recruiter from Tek Systems attends our local Sacramento Java Users Group (SacJUG) told a humorous and depressing story. It went a little like this:

HR Rep: Well, it doesn’t say here they developed any J2EE systems.

External Recruiter: It says designed and implemented two large J2EE ecommerce systems.

HR Rep: But that doesn’t mean they developed it.

External Recruiter: Implementing it means they developed it.

HR Rep: No, they might have only designed it and then deployed the final program, other people could have developed it.

External Recruiter: So if it said “designed, developed, and implemented” you’d be willing to interview them?

HR Rep: Yes.

The recruiter then explained that despite this frustrating conversation, developers would still be happy there because it’s just an HR hurdle and the development managers know what they’re doing. His advice was just to tailor the resume to mention all possible technologies and add words like developed. This way you don’t add extra hassle for the manager to get your resume out of HR.

For me this seriously flips the bozo bit. Even if I worked at a large Fortune 500 company I wouldn’t let HR own my hiring process. The minute you’re letting HR do screening for all but the most basic requirements you’re in danger of losing some of your best candidates. A rock star developer who has to deal with ridiculous HR flak will very often simply walk away from even a high paying opportunity.

To avoid this you write your own job descriptions for postings and don’t get to hung up on must haves especially around technology. You’re looking for the best developers even if they don’t have 2 years experience with JSF or SOA experience. You explain to HR that you want to see all the resumes. I can rip through a lot of bad resumes in a few minutes and I have to live with the eventual hire for years so there’s plenty of self-interest at work. Getting the best candidates is partially a sales job on your working environment, you as a manager, and their potential fellow developers.

Letting HR do a lot of pre-screening is just a bad idea for high end technical hires.