I sat my two tech leads down last week and went over a draft of our new code review process. They were OK with the general approach and idea, but they did have two things to add:

1. You’re going to present this to the team.
2. We probably won’t need to do these after a little while since everyone will be on the same page.

On #1 I did plan on working up a short presentation to the team, but I understood they really wanted to make sure there was management support for it. Code reviews aren’t exactly popular. And #2 I certainly hope that we’ll have a lot fewer mandatory recommendations, but I think we’ll be adopting them as a regular practice. If the team wants to switch to say some light pairing or we run into other issues of course who knows. At the end of the day I think getting the team to adopt TDD is a bigger goal than having regular code reviews. In some ways it’s really just meant to be a supporting practice.

In a podcast on Drunk and Retired, they talked a bit about how their seems to be a bit of hand waving about how agile methodologies really scale:

Well, like you know, in Scrum, just have a Scrum of Scrums, that’ll work out.

–Cote

I actually giggled on my morning walk because it was the same visceral reaction I had reading the first time I came across the concept. I have pretty much the same reaction to how well a lot of Agile techniques will scale. They all depend on communication and collocation so a huge project team seems antithetical. My general rule is to run screaming from really large projects, or to see if they can be done with a smaller elite team.

Luckily this is all pretty much theoretical in my present world since our largest projects have at most 8-10 developers, and most of them are more along the lines of 2-3 developers per project.

In the tradition of code smells here’s some Enterprise Tool Smells:

• Install time is measured in days.
• Installation involves cryptic steps such as after step 17c, delete these files, then restart the installation script.
• The install software doesn’t fit on a single DVD, necessitating baby-sitting it so you can dump the next CD/DVD when it’s ready.
• Tool promises that regular business people can use it and write business rules in a “natural language,” making code monkey’s irrelevant.
• It has an Enterprise version that installs tons of features, servers, plug-ins, that no one ever uses.
• It uses lots of wizards.
• Company recommends hiring consultants to train you in how to use the tool.
• Despite features like “seamless hot deploy”, any change involves rebooting the server.
• Restarting the service or tool is measured in minutes not seconds.
• No one including the sales team can really explain the licensing terms for all the different purchase options.
• Productivity takes a radical nosedive when tool is introduced, and then mysteriously increases sometime later when employees stop using the tool.
• Support involves filing trouble tickets or issues that are never resolved though sometimes promised to be in the next release.
• It’s in the Gartner magic quadrant.

It’s nice to know a big name consultant like Rick Hightower is struggling mightily with Websphere Portal and RAD 6 as well:

The loading process is a 15 page document of push this button, push that button, install this, stand on your head, fill out this dialog, sacrifice a goat, scroll this list, repeat, repeat, walk around your cube backwards seven times while chanting SOA.

The scary part here is we’re wondering about how we automate anything with the horrible wizard based deployment. Hopefully there’s a well documented work around.

Then Rick runs into the same solution we hear from our IBM Websphere Partner certified consultants. “Well we can file a trouble ticket with IBM.” Basically an admission of defeat.

I am told we can put in a ticket wtih IBM, which will take about a month to resolve.

And of course resolving some of these means the IBM helpdesk person just closes it as resolved without ever fixing anything. The joy is you pay a lot of money for all of this.

I sat down with a consultant our company’s hired the other day and asked about the consultant’s special skill sets. The idea was how they could help mentor/coach my team since just giving them some random coding assignment doesn’t build any lasting capacity.

So I asked about the things we need the most help with first, any experience with unit testing, TDD. Would you be able to sit with my developers and show them via some pairing? I got kinda the deer in the headlights look. Didn’t take long to figure out this consultant had very little experience with unit testing, though luckily they didn’t pretend to know more.

Anyway it turns out the consultant does unit testing. Fire up IBM RAD 6.0, drag and drop some JavaServer Faces components on the page, deploy to a local instance and then manually click and type your way through a unit test.

I can’t say I was surprised, but it’s still kinda sad. This is very much the contractor consultant model where a person jumps from contract to contract typically having some depth on a few newer technologies. They might know the technology pretty well, but the larger context of keeping up with software development practices is not a major concern. In this case the consultant may turn out to know their way around JSF pretty well which will be somewhat useful. Still is it too much to ask that a consultant know how to write unit tests?