Moving as metaphor

A few weeks ago, I and several others helped some friends of ours pack up their apartment into a truck in preparation for moving cross-country from Chicago to New York. It was, as such moments generally are, bitter sweet. It's always a good feeling to help out a friend, but when you're helping them get further away from you it's not as pleasant.

Of course, me being me, what struck me most about the whole process was how well it served as a model for software development and project management in general.

There were about a half-dozen of us all told, packing up stuff in a 2nd floor apartment, loading dollies, taking them down the elevator ($deity bless elevators...), out to the truck, and finally loading the truck. (Curiously, half the people involved were named "Dave". Insert joke here.) Throughout the few hours we spent working we evolved through various assembly line approaches, rotated positions, gave up and went with an "every man for himself" approach, took breaks to snack, and so on. If you've ever helped someone move then you know the drill.

Let's look at the whole process from a project management perspective, however.

The box model

The naive approach, of course, would say that if one person can carry a box down in 5 minutes and there's 100 boxes, then we just need 100 people and we'd be done in 5 minutes, or one person would be done in 500 minutes (a little over 8 hours). I certainly hope that everyone sees just how stupid that over-simplification is, but there are still software projects that try to run on that model: When in doubt, add manpower. Clearly they've never heard of Brooke's Law. (And if you haven't, you have no business managing a software project until you've read The Mythical Man Month. Go read it. Now.)

Why is that naive approach useless? Many reasons.

First and foremost, carrying boxes is only one part of the overall packing process. The boxes themselves first need to be packed and their contents organized in some sane fashion. The truck needs to be loaded. Boxes need to be grouped onto dollies in a way that won't fall over (and then of course does anyway).

There are also many constraints on the process besides manpower. We had only 3 dollies. We had only one elevator, and it could hold only so much at a time. It started to rain while we were packing the truck. (Doesn't it always?) Donuts didn't arrive until later.

And of course, not all movers are created equal. Some are stronger than others. When packing the boxes themselves, not everyone knew what went where or what should be thrown out instead of packed. When packing the truck, some people played more Tetris as a kid, and not everyone knew what was packed where and therefore what could be placed on top of what without it breaking.

Software is complicated, m'kay?

And so it is with software projects.

Writing code is only one part of the process. Long before you get there, you need to spec out the site you're building. You need to know what functionality you're going to need and what you will leave out or postpone for phase 2. You need both wire-frames and a design comp, both of which can dramatically alter the functional spec and vice versa. With some more troublesome clients that can take longer than actually implementing the functional requirements. Get the architecture wrong and you're doomed before you've configured one module or written one line of custom code. The QA, deployment, testing, and support phases cannot be forgotten, either.

A project's progress may be constrained by far more than the number of code monkeys one can throw at it. Servers need to work, and work quickly. Network connections need to be stable and fast. You may not have the content for a site when you start, or only a portion of it. You may need to connect to a 3rd party service that just doesn't want to cooperate. Someone is going to get sick at the worst possible time. And of course your client contact's supervisor is going to request a last minute change that completely unravels everything you've done to date, because that's what client contact supervisors are for.

While it totally screws up the spreadsheet, we also cannot escape the fact that not all developers are created equal, either. Some are just flat out better at what they do than others. Some write great PHP but have no visual eye to do CSS or vice versa. Some may have the necessary skills with some system (Views or CCK or Panels in Drupal-land, or some 3rd party API) that would take another days or weeks to acquire if they are even up to the task at all.

And, most damningly, you can't reasonably document where everything is in the truck. There are certain parts of a project that cannot be divided and conquered separately. Having one person, or two working together the entire time, handle all packing of the truck creates a consistent, cohesive packing plan, even if it wasn't planned from the outset. Those dedicated people are able to adjust organically (dare I say, "be agile") when a box doesn't quite fit between the table and couch after all without being constrained by having to explain it to everyone else, and then know exactly where everything is when unpacking it 2000 miles away. Which means that yes, the person packing the truck *must* be one of the people who will be going with the truck.

Similarly, having one person take a week on a highly complex new Views plugin is going to be better, and faster, than trying to have 5 people get it done in a day. The problem space does not divide into 5 parts. Trying to force it into 5 brains is going to make it take more than a week, not less, and the resulting code will have more bugs, less flexibility, and will probably fall over and break your good china when you round a corner in Pittsburg.

In fact, I'd argue that dividing and conquering in the right place is the single most important part of project planning. Figure out what your smallest reasonable chunks of functionality are, and which would be better if the same person's informal knowledge carried from one to the next. Figure out which would benefit from having two or more people involved for the entire chunk, because the box is just too heavy for one person. Then you know where, and when, and if, you can add and remove people to the overall project. That's being agile.

Action items

So what's the take-away for a successful software project?

1. Always pack your boxes in advance before the movers get there. It may take longer than moving them, but it will avoid having to put the silverware in with the cat food because you already put the towels in the truck.

   Design and architect first, before you build. As a professor of mine once said, "Prior Planning Prevents Piss Poor Performance."

2. Make sure the people packing the boxes know everything that is being packed; or at least that someone is coordinating the packing who knows everything that is being packed, even if other people actually put books into boxes. Tip: Most of your moving team is completely unqualified for this task, so make sure you have the right person (or people) organizing boxes.

   You need a good architect, and not everyone is a good architect. You need to give them enough time and space to do the job right. Yes, this is billable time.

3. Know what is in each box before you start moving it, and which can stack on which. You cannot add more people to the project than that, no matter how much the client may demand you do so or how far behind schedule you are. All it will do is make it worse.

   Adding people to a late project makes it later, unless you've already figured out, in advance, where you can add them and you do so before it's too late.

4. Make sure the strong people with a gentle touch carry the glass figurines. That's not everyone.

   Not all developers are created equal. That's OK. Allocate people to where their skills are going to be most effective and accept that will be different for different people. You may even end up with some people idle part of the time as a result. That's OK, too.

5. Don't try to carry a box in pieces. That just rips cardboard and is impossible to tape back up.

   Don't break a problem down too far. Sometimes you need to just let someone deal with an entire problem space on their own. Get out of their way and let them do it, however long that takes. The alternative is always worse in the long run.

Quite a lot to learn from a moving van, isn't it?

If a van leaves Chicago...

In the end we managed to get everything packed up into the truck with only a few inches to spare. We had leftover donuts and bagels and the whole process took about 5 hours, including pizza. Of course, that's not counting the moving couple spending the previous two weeks packing on and off so that we could blitz through the truck-stuffing in a long morning, nor the two day drive to New York.

Of course, that doesn't answer the biggest question: Why would anyone want to move from Chicago to New York?