I do a lot more dishes these days. Turns out popping on a podcast on say Ruby means a lot more dirty dishes get done. Never would have guessed podcasts would spruce up household chores.

Last week I filled out a purchase order for Clover after some evaluation of various unit testing code coverage tools. I went with Clover because $1500 for the server edition isn’t really that significant a cost even if the experiment doesn’t work out. So starting next week we’ll be running code coverage reports with our ongoing projects. I expect the feedback loop to be pretty helpful. I’ll be really happy at first if we can get 50% coverage at first on average.

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.