In a demo today another example of why we really need more unit testing instilled cropped up. One of our senior developers was giving a demo after the first Sprint on a project on an overhead projector. Someone piped up that he should try adding a document to multiple categories. So he agrees OK, selects two categories and then presto it just adds it to the first one. (He did do a good job of preparing running through the expected scenarios, but not including adding a document to more than one category.) Apparently this worked only a few hours before the demo, but after making a fix for a Hibernate issue this functionality broke. I pointed out that if there was a unit test for this, preferably written before the implementing code he would have known a lot more quickly about the bug. He essentially agreed, but he’s still not sold all that much on unit testing.

I’ve been cruising through the first few chapters of Fit for Developing Software by Rick Mugridge and Ward Cunningham. It’s a pretty good read as I finally feel like I have a good handle on how to wire Fitnesse to Fixtures and Fixtures to my code. I’m actually really kicking myself a bit because we just wrote a custom regression testing tool for one of our projects that Fitnesse would have handled a lot more cleanly.

The Fitnesse docs are good, but somehow I really missed the link between how to wire up the Fixture classes. Sometimes its just better to wait for the book. They did decide to split the book into for general business users and developers. I’m not sure many business users could be convinced to read it though. Sort of like the idea that business experts will write business rules in some pseudo English rules language.

Today I stopped bothering to update XPlanner. Part of the Agile method is to “do the simplest thing that works.” XPlanner wasn’t really a simple install, but once I adjusted to the user interface it made at least logical sense. The problem is:

• I already track my Scrum projects on white boards with sticky notes.
• I already use 3×5 cards for user stories and tasks.
• I do the time tracking, because time tracking really demotivates developers.
• My developers are all collocated so they can see the white boards at the daily standups.
• Tracking time takes way too many clicks. (I can see why they’re considering a nice friendly Ruby on Rails version with AJAX support)
• The graphs only update once a day and really didn’t work that well for me.
• Excel isn’t so bad.
• It was just slowing me down and duplicating work I was already doing.

So I’ll toss a note to myself to check in on it maybe a year from now or look at a commercial option like Rally if I feel the need again, but for now I’m back to 3×5 cards, white boards and Excel.

Apparently my assumption that there will eventually be a podcast for every niche is starting to happen. Cocoa Radio is an entertaining podcast devoted to independent Mac software developers developing in Cocoa. So far there’s only a few out there, but the focus is on interviews with independent Mac developers like Brent Simmons of NetNewsWire fame. Not sure it’s enough to inspire me to pick up a book on Objective C, but heh, you never know.

I regularly ‘google’ potential hires to see if I can find out any useful information before even getting to a technical screening phone interview. Sometimes you can’t find much of anything on a candidate even a candidate with an unusual name. I don’t read a lot into this but I often wonder about it. If you’ve never posted a comment on something like TSS or some other searchable forum, don’t have an old blog, or a bug report on sourceforge are you just trying to hide something? Since I’m almost always hiring for web development seeing a candidate’s content out there on the internet is a big plus.

I love coming across candidates who have web sites or who have made a lot of posts to newsgroups. You can really get a good idea about someone from even how they ask for help with some configuration issue. Unfortunately I think a lot of technical people realize anything they put out on the public internet could possibly be used against them later, so they generally avoid it. I think the advantages outweigh the risks, but that’s pretty obvious.

The one time this did impact me in an interview process I got attacked for posting something on a Mac forum I had forgotten about. After three interviews I was on yet another interview with the head of networking for a company. He apparently was a Microsoft bigot and believed that the world should be Windows NT. The company already was starting to annoy me because they couldn’t make a decision after three separate interviews. This was in 1999 at pretty much the height of the dotcom bubble so I have no idea how they thought someone wouldn’t find a better job in the month long interview process they engaged in.

Anyway this the interview devolved into some weird attack interview which took me quite by surprise. I really didn’t see why it mattered that I used Macs as well as Unix and Windows machines. Anyway that was the final straw that convinced me not to even consider their offer. And I sent an email to the actual hiring manager explaining that being personally attacked because I dared to use Macs in an interview by a network admin wasn’t my idea of a good work environment. He replied back about a month later after he had left the company and apologized for the process. But by then I had found a great dotcom to work for. OK, it was a great experience. The company is of course out of business.

Anyway you can still find old Usenet posts of mine out there on rec.sport.paintball when I spent a lot of my freetime playing amateur paintball.