March 26, 2006
Tight coupling…of team members
For the last several weeks, I’ve been on a project where we’re all pretty tightly coupled. Any design purist will tell you that tight coupling is a bad, though sometimes useful, thing. Tight coupling means every participant needs to know practically everything about every other participant, and all participants need to be “in the same room” whenever work needs to be done.
(Mental image: passing a co-worker onto your call stack…by value.)
(Oh wait, that’s what meetings are. Too bad small conference rooms don’t throw stack overflow exceptions.)
Practically, what this means is we’re all pretty much working the same hours–including weekends. That’s not exactly news in the software world, but it is a different way of working for me. I can be more productive at 3am than I can at 3pm, but it’s hard to get everybody to agree to work those hours. (Maybe when I’m a manager. Bwaaahahahaha.)
Ordinarily, I resist for an entire project team to work together on a weekend. Partly, this is selfish. In cases where it seems to work (i.e., we meet our deadline), management will perceive that working weekends is the answer to tight schedules. The result? More weekends to work. We lovingly call this the death march, which studies have shown don’t work.
However, sometimes the work is partitioned in a way where not having everybody in a room together, even on a weekend, will cause bottlenecks. On a project with a far-off, or flexible, deadline, there’s time to reconsider partitioning of work after a week under less-than-ideal circumstances. But when you’re on a tight deadline, you suck it up, and hope everybody learns from the experience heading into the next project.
Luckily, rearchitecting how a team works is much easier than rearchitecting how a software system works.
If there’s an upshot to tight coupling, it’s that everybody gets a chance to mesh. We’ve expanded the team recently, which means we have a high proportion of new members. This is the first chance we’ve had to really work together as a coherent unit, and it’s been great. Maybe there’s a lesson here… everytime your team expands, you go through a little ritual hazing, i.e., working several weekends in a row on a project with a firm deadline.