I’ve been running weekly 30 minute one-on-ones with all of my team for about two months now. With these meetings in place I go no longer than one week between giving and getting feedback from each employee.

Doesn’t sound like much. Like most managers I assumed I probably talked to all of my staff every week. What I often didn’t take into account is I didn’t always check in with everyone on a weekly basis. With the more self-directed employees or the slightly more introverted ones I only had brief discussions in the cube or hallways or maybe at the end of a meeting.

Turns out rapid feedback loops, even 30 minutes once a week, allow your employees notify you when things are a bit off course. Maybe they’re underutilized on a project or frustrated with a work situation. Maximum time to find out is one week on something like this. Sure, some employees will bring this your attention sooner, and they probably should, but having a regular discourse guarantees your employees have a chance to inform you.

In the last two weeks this feedback loop helped me become aware and fix two situations that were really demotivating several employees. There’s really nothing better than a re-motivated employee. So so far the one on ones are paying significant dividends.

Crucible, a code review tool from fine folks at Cenqua, is finally closing in on a real beta release. (Disclaimer we’re already use Cenqua’s Clover product.) I talked to Brendan from Cenqua at SD West 2006, and he explained that Crucible was supposed to be Cenqua’s second project after Clover. Turns out Fisheye was a lot more popular than they anticipated. Thus Crucible got pushed back.

It’s still not quite beta ready, maybe early next month, but it looks like it may really fit the bill for our needs with a simple lightweight code review process. It sits on top of Fisheye their CVS/Subversion browsing product.

Some nice features they bravely previewed for us:

• AJAX style commenting while browsing code for the review.
• Very simple workflow with email/RSS notifications.
• Nice defaults for the attributes. If my memory serves right there were only two types of severity to an issue in the code <div class="codecolorer-container text vibrant overflow-off" style="overflow:auto;white-space:nowrap;">

  1

  major

  </div>

  or

  1

  minor

  .</li> </ul>

  The really nice thing is it didn’t try to do anything more. Simple is generally better on features especially when we’re trying to have lightweight code reviews. I’ll probably post again on it after getting a chance to play with a future beta.

Walk before you run. So even in a TDD framework approach like Rails the concept of TDD is only approached and explained on page 169 of Agile Web Development with Rails. And even in a chapter on testing we begin with writing functional database style unit tests, and then functional style tests against the controllers. Finally, on page 169, we’re introduced to test driven development.

I don’t fault the writers of Agile Web Development with Rails for the approach and certainly not Mike Clark who has made important contributions to TDD and is extremely lucid technical writer. I fault the current level of adoption of TDD.

I think the authors made a reasonable assumption that many of their reader base wouldn’t be familiar with TDD. Thus you get through building the example application before you bring up the subject of testing. Since many readers come from backgrounds like PHP it is unlikely they’ve ever touched a unit test framework or tool before.

I still would have enjoyed if they blazed a trail and started out doing TDD. Just gone ahead and explained the approach in chapter one and then used it to build the example application. This would have forced a title change like Test Driven Development with Rails since the only books that cover the TDD approach up front have TDD somewhere in the title like Test Driven Development: A Practical Guide.

Maybe in the next few years we’ll see technical books that aren’t on TDD, that just use TDD in the examples by default.

We held our second code review this Friday. Two months between holding code reviews is a little long, but we’re still working out the process. Some things to remember for next time:

• Prepare for the code review ahead of time. This code review was being held towards the end of the Sprint, so the afternoon before we got it arranged. Some review is better than none, but the code review ended up being more of a code walk-through.
• Adding a static analyzer like Checkstyle really helps with keeping the code clean. Since the developers had spent a good bit of time working down 150+ Checkstyle warnings to 9 there were very few basic defects, like one character variable names, or really long methods.
• Figure out a better way to do followup. After 90 minutes we had a number of items to fix, but since they were handwritten notes by all the participants it will be a bit difficult to check up on. We may get a chance to use a tool like Crucible the next time around.
• Next time don’t even hold the review until all the classes covered have tests. Two of the reviewed classes had zero test coverage.

On the positive side we found quite a few subtle defects in 90 minutes from cut and paste errors to iterating over collections that only had one item. I think the three of us were all in agreement that having new pairs of eyes on the code was really helpful in catching some things.

Richard Monson-Haefel blogs about looking into JSF. Some of his comments include:

“It really seems complicated to me in terms of configuration, debugging, and such things.”

“JSF strikes me as an over-engineered solution that meets the needs of a small percentage of enterprise web sites.”

Appears to be seeing JSF for what it is right now. Interesting technology that isn’t that cleanly implemented. I really wonder how well JSF will succeed out in the world unless they can fix some of the difficulties with logging, debugging, and unit testing. That said we’re still pushing hard to make it work on several projects. One developer even mused recently that using a component with some built-in paging functionality, finally made him feel like there was something positive in JSF.