I came across a post explaining why you should stop demanding pair programming. Alex Pukinskis’s argument is that selling pair programming really doesn’t work.

This is a difficult transition, and so you can’t force people to pair, any more than you can force them to wear a tie to work. Demanding pairing just doesn’t tend to work well.

This dovetails with my present experiences trying to implement TDD with my developers. I just can’t get them to write the tests first, and I can barely get them to write the tests at all. So hopefully his suggested solution will be the answer for me:

• Stop trying to force them to pair
• Stop expecting 100% pairing
• Set up your space to make it easy to pair
• Create a ‘lab’ with pairing workstations that are more desirable than individual workstations

That sounds pretty close to what I’ve tried. I’ve implemented the following:

• Running a TDD day long class.
• Lining up smaller sessions to teach about mock objects, testing databases, JSF, etc.
• Volunteering to pair with any developer having trouble writing tests.
• Implementing code reviews with one of the mandatory requirements being that the reviewed code has unit tests.
• Explained that part of this years evaluation will be on how well they adopt unit testing.
• Requiring an automated build with cruisecontrol that includes a test target and a clover task that reports the unit testing coverage percent.
• When I implement weekly one-on-ones one of the questions each time will be, “So how many tests did you write this week?”

None of these approaches have paid off just yet. I’m hoping it’s just going to be a longer process or maybe after all of our new technology adoption dies down that the TDD adoption will ramp up.

JSF is not at all easy to test, and really wasn’t designed to be, but so far the mock objects library included with Shale appears to be working for us. I paired with one of my developers for 3 hours to get 3 unit tests written that needed a FacesContext to allow for unit testing. For something you’re still pulling down with nightly builds, it appears solid enough for now. The extra examples in the source code helped work out some of the details for us.

It would appear based on my limited experience that presented with lots of new tools, technologies and frameworks to learn versus a new development practice like TDD the new technology wins hands-down. I think I knew instinctively that pushing new technologies and TDD at the same time would be hard, but our marching orders are to implement all new projects on the new enterprise software, the IBM Websphere stack in this case.

Developers are used to being asked to learn new technologies. Almost every project adds at least one new thing to learn even if it’s just a new way to do logging. Technology tends to march on. So picking up a new technology is a learned habit for software developers.

TDD reverses the usual development style where the developer does a little design, codes a solution, checks and unit tests it by hand, and then moves on to the next feature. Asking them to start writing tests firsts even after running them through some training still feels odd. Then you add in the stress of learning multiple new frameworks. On this project the developers are learning:

• JSF
• Portlet Development
• Legacy connectors
• RAD 6.0 IDE
• iBATIS/Hibernate
• Spring
• Maven

In some cases they have some exposure to a few of these, basically Spring and iBATIS/Hibernate, but mostly it’s all been new.

So what I’ve observed is as the stress mounts developers fall back to learning just enough to get the new tools working to solve the current problem. Writing tests in a framework you only partially understand is hard, and then these aren’t exactly unit testing friendly things like JSF or Portlets.

Tomorrow I’ve freed up some time to pair up and write some tests.

Apparently we’ve been running Type A Scrum as defined by Jeff Sutherland in a paper from Agile 2005. He’s divided Scrum into 3 types:

• Type A Scrum – Everything is done in the Sprint, but there is downtime of a week or two between each Sprint.
• Type B Scrum – You start to overlap the product backlog definition for the next Sprint into each Sprint resulting in no real downtime between Sprints.
• Type C Scrum – Jeff Sutherland’s nirvana where you have overlapping Sprints.

Our experience so far is that we have been running Type A Scrum with gaps between each Sprint. I’ve had a lingering question over whether this was supposed to happen which this paper helps answer. Since we’re in early adoption and getting everyone up to speed this is pretty much expected, but it will be nice if we can evolve into a Type B Scrum without the time between Sprints.

Had an interesting discussion with my brother this morning. He happens to be yet another software developer in the family. Out of five brothers four of us ended up in programming. Probably related to our Dad’s early experiments with kit computers like our first Interact in 1979.

Anyway he sees the world a little differently and he’s working on studying up for the IEEE Software Developer Certification. He brought up this idea of preferring 100-200 line methods or functions that can be followed fairly easy. The idea of having a more object oriented approach with lots of small objects and simple responsibilities he referred to as Spaghetti OO’s code. He finds it quite difficult to follow the logic in such code because it’s always jumping around and you end up having to know too much about the design up front.

I can’t say a particularly agree with him on this one, but it does capture a sense I get in digging into some large OO code bases where I have trouble finding my way. You know the kind where if you tried to draw out an end to end slice through the system you’d end up with a sequence diagram that circled around the room. The point being is you can still get really convoluted with any approach. These days I only have one hard and fast rule for any of my code or any of my developer’s code:

• Can I unit test it.

If I need to sacrifice a little OO purity, I’m OK with that. And I’m still far from being some OO god, so I probably pull some procedural hacks without even realizing it. Heck, I still think Struts is a reasonable web framework given the current options, and it has a pretty solid procedural feel to it.