I realized today I haven’t actually had to put together a project plan in MS project in the longest time. I don’t even really open other peoples project plans anymore. A few years ago working as a professional services consultant I was constantly in MS Project because, darn it, customers want their Gantt charts. I always found it a very frustrating tool for anything more than a very simple projects. Add a few resources, a few dependencies and then make a change between some linked tasks and you are headed down a rabbit hole pretty quickly. And just try taping together a Gantt chart with 500+ tasks.

MS Project and other project management software largely fades away on Scrum project. Since everything is driven from a backlog and you really track velocity on a daily basis there’s no need for the familiar Gantt chart. Even when I attempted to use XPlanner on a Scrum project it turned out to have to high of an overhead. One of the nicest things about Agile is that you work the plan everyday so you always have a good idea of where you are at least for the near future and the longer term planning is just revisited once a month.

I shot through the first hundred pages of Martin Fowler’s classic Refactoring today. I can see why it’s still considered a classic now. Fowler’s style is very readable for a software development book and his code examples are simple steps well explained. He peppers the explanations with lots of real world anecdotes from projects. And probably most importantly he’s not afraid to explain that he didn’t start out as an expert in things like object oriented programming:

“It is hard to see what causes the technique to be less effective, even harmful. Ten years ago it was like that with objects. If someone asked me not to use objects, it was hard to answer. It wasn’t that I didn’t think objects had limitations–I’m to cynical for that. It was just that I didn’t know what those limitations were, although I knew what the benefits were.” –pg. 62

It also reinforces the notion that many of the thought leaders in the agile world are former Smalltalkers. At some point maybe I’ll take a look at Squeak, but Ruby is my current new language to learn.

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.