I’ve dealt with lots of PMs in current and past lives, and often filled in as the PM though I rarely had the official PM title. Over time I’ve found a really good sign the PM is on the ball is that they occasionally get on my nerves.

I remember after working on a difficult project where the PM was pretty much out to lunch. OK, literally out to lunch. The PM took at least one unannounced 2 week vacation to Europe at one point. Since this was 2000, the infamous dotcom era, no one lost their jobs. Anyway not long after my team got handed another project and I noticed after the first 3 days the PM had called me from San Francisco at least once per day. So on the 4th day I congratulated the PM who seemed a bit surprised. I explained it was nice to get pinged everyday about open issues, since on the last project I couldn’t even get ahold of the PM.

Since then I always think to myself as I get slightly annoyed with a ‘red for urgent’ email from a PM, that at least they’re paying attention and trying to move the project forward. There’s of course a fine line where the PM becomes distracting because they’re going around asking for status every few hours or wanting yet another estimate of how long it will take to fix a defect. Anyway whenever one of my developers complains to me about a PM I tend to take it with a grain of salt unless that PM already has a proven track record of mindless pestering.

I recently had a short conversation with one of my developers who’s worked at the company a good deal longer then myself.

The conversation would just be amusing as techie’s can get caught up in jargon really easily, but unfortunately these names are embedded in the methods, variables, and class names. Just love those CVSN002 classes. I believe the impenetrable names come from physical file locations on the mainframe, but as I’ve never been a mainframe developer I really don’t have a clue.

I’ve liked the ideas of war rooms for dedicated project teams for a long time. Especially on critical projects I think they produce some great communication benefits that outweigh any inconveniences of shared space. I realize this tends to be a bit split in the developer community.

Brian Button in a post argues that much of the problem is that managers who are in charge of making the decision generally love having their private office:

From their own personal experience, they wanted their personal space, and they want to do good for their people. So they want to get them those private offices or cubes.

I’m probably a bit of an odd duck for your stereotypical development manager:

• Wanted to step into people management despite being pretty technical. I’ve turned down an architect position or two that would have paid better than my current management position.
• Enjoy understanding office politics (even an MS in Political Science)
• Love doing business requirements even when this means day long meetings going into the finer details of highway lane closures or the tracking of parolees between precincts.

So I actually feel a bit odd having an office currently. I’ve started to put up whiteboards and cork boards everywhere and it’s regularly used for standup meetings. I actually prefer to be out on the floor despite the distractions. And the reality is I get interrupted about every 15 minutes anyway even with an office because I rarely close the door.

Anyway I had a really hard time on a large project getting the idea of a war room across. I was asked again and again how to get it back on track. I said putting the team in a war room would refocus everyone, vastly improve broken communication, and actually show that upper management thought the project was important enough to take over a precious conference room. In the end it never happened though I moved my developers over to cubicles across from the QA team on the project which had a significant impact though it wasn’t really as good as a true war room.

Over and over again I was told by fellow managers that we couldn’t move people because they liked their cubes. I also heard that they needed to sit next to their manager and couldn’t be moved to sit with a project team. Still things are finally starting to change. A small pilot agile project is kicking off soon with an actual war room being setup in an old HR training area.

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.