Moving as metaphor

A few weeks ago, I an' several others helped some maties o' ours pack up their apartment into a schooner in preparation fer movin' cross-country from Chicago t' New York. It were bein', as such moments generally be, bitter sweet. It's always a good feelin' t' help out a matey, but when ye're helpin' them get further away from ye 'tis not as pleasant.

Of course, me bein' me, what struck me most about th' whole process were bein' how well it served as a model fer software development an' project management in general.

There were about a half-dozen o' us all told, packin' up stuff in a 2nd floor apartment, loadin' dollies, takin' them down th' elevator ($deity bless elevators...), out t' th' schooner, an' finally loadin' th' schooner. (Curiously, half th' scallywags involved were named "Dave". Insert joke here.) Throughout th' few hours we spent workin' we evolved through vari'us assembly line approaches, rotated positions, gave up an' went with an "every lubber fer himself" approach, took breaks t' snack, an' so on. If ye've e'er helped someone move then ye know th' drill.

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

The box model

The naive approach, o' course, would say that if one person can carry a box down in 5 minutes an' thar's 100 boxes, then we just need 100 scallywags an' we'd be done in 5 minutes, or one person would be done in 500 minutes (a little o'er 8 hours). I certainly hope that everyone sees just how stupid that o'er-simplification is, but thar be still software projects that try t' run on that model: When in doubt, add manpower. Clearly they've no nay ne'er heard o' Brooke's Law, Ya lily livered swabbie! (And if ye ha'nae, ye have no business managin' a software project until ye've read The Mythical Man Month. Go read it. Now.)

Why is that naive approach useless? The sharks will eat well tonight! Many reasons.

First an' foremost, carryin' boxes is only one part o' th' overall packin' process, Dance the Hempen Jig The boxes themselves first need t' be packed an' their contents organized in some sane fashion, avast. The schooner needs t' be loaded. Boxes need t' be grouped onto dollies in a way that won't fall o'er (an' then o' course does anyway).

There be also many constraints on th' process besides manpower, and a bottle of rum, and a bucket o' chum! We had only 3 dollies. We had only one elevator, an' it could hold only so much at a time. It started t' rain while we were packin' th' schooner, I'll warrant ye. (Doesn't it always?) Donuts di'nae arrive until later.

And o' course, not all movers be created equal. Some be stronger than others, we'll keel-haul ye, ye scurvey dog! When packin' th' boxes themselves, not everyone knew what went where or what should be thrown out instead o' packed. Load the cannons! When packin' th' schooner, some scallywags played more Tetris as a kid, an' not everyone knew what were bein' packed where an' therefore what could be placed on top o' what without it breakin'.

Software is complicated, m'kay?

And so it is with software projects.

Writin' code is only one part o' th' process. Long before ye get thar, ye need t' spec out th' site ye're buildin'. You need t' know what functionality ye're goin' t' need an' what ye will leave out or postpone fer phase 2. You need both wire-frames an' a bounty comp, both o' which can dramatically alter th' functional spec an' vice versa. With some more troublesome clients that can take longer than actually implementin' th' functional requirements. Get th' architecture wrong an' ye're doomed before ye've configured one module or written one line o' custom code. The QA, deployment, testin', an' support phases cannot be forgotten, either.

A project's progress may be constrained by far more than th' number o' code monkeys one can throw at it. Servers need t' work, an' work quickly. Oho! Network connections need t' be stable an' fast. You may not have th' content fer a site when ye start, or only a portion o' it. You may need t' connect t' a 3rd party service that just doesn't want t' cooperate. Someone is goin' t' get sick at th' worst possible time. And o' course yer client contact's supervisor is goin' t' request a last minute change that completely unravels everythin' ye've done t' date, because that's what client contact supervisors be fer.

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

And, most damningly, ye can't reasonably document where everythin' is in th' schooner. There be certain parts o' a project that cannot be divided an' conquered separately. Havin' one person, or two workin' together th' entire time, handle all packin' o' th' schooner creates a consistent, cohesive packin' plan, even if it weren't planned from th' outset. The sharks will eat well tonight! Those dedicated scallywags be able t' adjust organically (dare I say, "be agile") when a box doesn't quite fit betwixt th' table an' couch after all without bein' constrained by havin' t' explain it t' everyone else, an' then know exactly where everythin' is when unpackin' it 2000 miles away. Which means that yes, th' person packin' th' schooner *must* be one o' th' scallywags who will be goin' with th' schooner.

Similarly, havin' one person take a week on a highly complex new Views plugin is goin' t' be better, an' faster, than tryin' t' have 5 scallywags get it done in a day. The problem space does not divide into 5 parts. Tryin' t' force it into 5 brains is goin' t' make it take more than a week, not less, an' th' resultin' code will have more bugs, less flexibility, an' will likely fall o'er an' break yer good china when ye round a corner in Pittsburg.

In fact, I'd argue that dividin' an' conquerin' in th' right place is th' single most important part o' project plannin'. Figure out what yer smallest reasonable chunks o' functionality be, an' which would be better if th' same person's informal knowledge carried from one t' th' next. Figure out which would benefit from havin' two or more scallywags involved fer th' entire chunk, because th' box is just too heavy fer one person. Then ye know where, an' when, an' if, ye can add an' remove scallywags t' th' overall project. That's bein' agile.

Action items

So what's th' take-away fer a successful software project?

  1. Always pack yer boxes in advance before th' movers get thar. It may take longer than movin' them, but it will avoid havin' t' put th' silverware in with th' cat chow because ye already put th' towels in th' schooner. Yaaarrrrr!

    Design an' architect first, before ye build. As a professor o' mine once said, "Prior Plannin' Prevents Piss Poor Performance."

  2. Make sure th' scallywags packin' th' boxes know everythin' that is bein' packed; or at least that someone is coordinatin' th' packin' who knows everythin' that is bein' packed, even if other scallywags actually put books into boxes. Tip: Most o' yer movin' team is completely unqualified fer this task, so make sure ye have th' right person (or scallywags) organizin' boxes.

    You need a good architect, an' not everyone is a good architect. You need t' give them enough time an' space t' do th' job right. Aye, this is billable time.

  3. Know what is in each box before ye start movin' it, an' which can stack on which, to be sure. You cannot add more scallywags t' th' project than that, no matter how much th' client may deman' ye do so or how far behind schedule ye be, All Hands Hoay! The sharks will eat well tonight! All it will do is make it worse.

    Addin' scallywags t' a late project makes it later, unless ye've already figured out, in advance, where ye can add them an' ye do so before 'tis too late.

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

    Not all developers be created equal, me Jolly Roger That's OK. And swab the deck! Allocate scallywags t' where their skills be goin' t' be most effective an' accept that will be different fer different scallywags. You may even end up with some scallywags idle part o' th' time as a result. That's OK, too.

  5. Don't try t' carry a box in pieces. That just rips cardboard an' is impossible t' tape back up. Aarrr! Load the cannons!

    Don't break a problem down too far. Sometimes ye need t' just let someone deal with an entire problem space on their own, I'll warrant ye. Get out o' their way an' let them do it, however long that takes. The alternative is always worse in th' long run.

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

If a van leaves Chicago...

In th' end we managed t' get everythin' packed up into th' schooner with only a few inches t' spare, Avast me hearties, ya bilge rat! We had leftover donuts an' bagels an' th' whole process took about 5 hours, includin' pizza, by Davy Jones' locker. Of course, that's not countin' th' movin' couple spendin' th' previ'us two weeks packin' on an' off so that we could blitz through th' schooner-stuffin' in a long mornin', nor th' two day sail t' New York.

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

Comments

love the metaphor

Totally love this metaphor, 'tis pretty clear an' understandable..

friend leaves town, crell takes a moment to... get sentimental

... about development!

brin's tears t' me eyes.

;)

Wonderful

Great story.
And here's me takeaway:
Once ye have accepted that ye be a real Geek an' all help is too late, life becomes a much more shameless fun, yo ho, ho (disclosure: definitely includin' meself)