In two hours, under my guidance, a small group of 5th and 6th graders built a drawbridge. We were operating using a plan essentially sketched on the napkin, with the napkin left at home. We had a stack of wood, rope, 2 hammers, a drill, a hacksaw, and a box of nails. I had access to as many kids as we needed as labor. And, again, we built a portable, freestanding, working drawbridge in under 2 hours. And assembled it outside a classroom 'medieval museum' to serve as its entrance for the rest of this week.

Just which skills of a computational astrophysicist made me especially suited for such a task?

1. my knowledge of geometry and trigonometry



2. my background in space-borne CCD camera assembly



3. my patience drawn from long observing nights



4. my skill at parallel programming

And the answer is... item 4. Yes, parallel programming. While the other talents are useful, the primary way to get a small group to complete a large task in a short time is effective labor distribution.

Good parallel programming consists of moving operations that can be run concurrently to multiple processors, while ensuring that the overhead due to items that require everything to wait until they completes (the serial parts) are minimized.

As it happens, this matches good project management. Too many people think that you can just toss more people at a project to make it go faster. Fred Brook's "The Mythical Man Month" is perhaps the most famous rebuttal of this idiocy. The canonical example is "just because 1 woman can create a baby in 9 months doesn't mean 9 women can create 1 baby in 1 month."

For the drawbridge, we could have one person pre-drill holes for nailing, but at best have two people hammering at a time. Similarly, only one person could saw, and worse, I had to supervised the hacksaw since this was a school project. Finally, since we were in part designing as we went, we had several stopping points.

Our design had three parts: a right and left support, and the middle bridge piece. Where could we parallelize? A drill is fast, fast enough that 1 drill can drill more holes than 2 children can fill with nails. The problem was symmetric: the right and left side were identical. Since we were designing on the fly, we had to build them synchronized, but could assign kids to either side.

(image courtesy of castlemagic.com)

So the tasks break down to:

1. decide on next step (serial)



2. measure twice (serial)



3. cut (serial)



4. assemble (parallel)



5. drill (serial but fast)



6. hammer (parallel)



7. repeat steps 1-6 for next step



8. rope up (parallel)

Once we got past the 3rd stage, since the drilling was so fast, the problem was easily parallelized by a factor of 2. Why 2? Well, we had two symmetric pieces, and we were also limited by having only two hammers.

Gustafson's Law tells you how much of a program can be effectively parallelized. It's an extension of Amdahl's Law, and its form is:

S(N) = N - A(N-1)

Where your speedup factor (S) is given in terms of the number of processors (N) and the fraction of the program 'A' that can not be parallelized. If none of the program can be parallelized (A=1.0), then your speedup is 1 no matter what resources you throw at it. If 100% can be parallelized (A=0.0), the speedup is N (e.g. if you have 5 processors, you get a 5x speedup.

Applying Gustafson's Law to this project and estimating that half was parallelizable (A=0.5), we get a speedup of N - 0.5*(N-1). With N=1 person, the speedup is 1 (nothing). With N=2 people, the speedup is 1.5... about 50% faster than with 1 person. Since we couldn't go past 2 hammers, N=2 was our maximum.

However, in the real world, a team requires more than the bare minimum necessary to operate equipment. Each 'team' had to be more than 1 person because a student could be called off by a teacher for another task, or get hot working in the sun and want a break. Most of the tasks required 2 people, for example, one to hold the work, another to hammer.

Finally, I didn't count as part of the work team because my role was solely to advise them as they converged on a workable (but not optimal) solution. The reason we didn't go for optimal was the time constraint and the project requirements: it only has to last through this week, and we had to finish before school ended in three hours.

So balancing all that, I ended up with a team of five. There were two engineering leads (a boy and a girl, for those who track such things), and at any moment at least four of the five participants were available. My only role was to adjudicate and to assign tasks, not to assemble.

Although Brook's group intercommunication formula means a non-hierarchical group of 6 people would have 15 channels of communications (N[N-1]/2), our structure of two teams plus an adjudicator means there were only 3 channels. I'll argue that, had we dropped this to 1 channel with me as Decider and them as unempowered Workers, the project would have taken longer-- because we would have lost workers due to low morale and attrition.

And of course a rigid parent-ruled setup would have produced (maybe) a drawbridge but no actual learning, and where's the fun in that? If all we needed was a drawbridge, we could have ordered one from discountdrawbridges.org. One must keep in sight the primary and secondary goals for any project.

Back to our team. Five children, one adult ended up being the optimal number. In fact, we turned down additional assistance. I had the luxury of being able to resist adding new members because, really, few things are more boring then being part of a team but having nothing to do. We couldn't effectively use them given our parallel constraint of '2 teams maximum', and more workers would have required more time lost in tracking task assignment fairness and in managing kids. And don't get me started on the doom that occurs if you force two technically minded, well intentioned parents to collaborate with preplanning on such a project.

Had we had only one hammer, or added more people, or added another 'adjudicator' at the top, or avoided having teams in favor of equally weighted individual voices, or had fewer people, or let a petty tyrant rule, the project would have missed its deadline.

Did I work out these equations beforehand? Did you miss the part where I said we didn't even have the blueprint with us? Of course not. However, the basic thinking process behind a good parallel programmer and a good project manager are not as different as one might expect.

In common sense terms, I figured out how many teams we had tools to support, then set up team size to maximize 'time on tools' per member while also minimizing downtime due to stochastically losing team members. This kept both productivity and morale high while minimizing risk.

So, a project manager with parallel programming knowledge is a good thing. And a parallel programmer who understands items like morale is just as potent. So our lesson learned is simple. If you want a group of small children to assemble medieval siege gear, call your local computational astrophysicist.

Alex, the daytime astronomer

The Daytime Astronomer, Tues&Fri here, via RSS feed, and twitter @skyday