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 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.
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.
So what's the take-away for a successful software project?
Design and architect first, before you build. As a professor of mine once said, "Prior Planning Prevents Piss Poor Performance."
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.
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.
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.
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?
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?