Wednesday, December 20, 2006

Juggling as Allegory for Software Development

Everybody has their favorite complementary activity which they say will make you a better programmer. For many, it's 'learn Lisp!'. My advice for undergrads (dating back to when I was also an undergrad) has always been, "Get a job in Tech Support so you learn how 'normal' computer users think." But now I have some advice for everybody else:

Learn to juggle.

It's something I tried to learn in college, but never really mastered. This Spring, in an attempt to bring some much-needed balance to my life, I did just that. Six months later, I wasn't good enough to perform in the park, but I was at least the best juggler in my social and professional circles. I'm also a bit wiser for it.

They already call project management a 'juggling act'. I suspect if more people learned to juggle, they'd realize that there's far more to that analogy than meets the eye.

Juggling, better than anything else that I've tried, teaches you about one of my hot-button issues: Panic versus Urgency. Every single project I've been on where things were going badly either started out with the development staff in a blind panic, or quickly got there. In Juggling, Urgency is the rule of law; If I don't place my hand just so within the next second, then the balls hit the floor. It makes no difference if I accomplish this in half a second, or one second. It simply needs to be done when the time comes. The moment of panic comes (or tries to come) when one of those deadlines is in jeopardy, or something is not going according to plan. However, if you let panic set in, then it doesn't matter what you do from then on. It will be a matter of fractions of a second before all of your juggling equipment ends up on the floor, hitting you in the neck (ouch!) or landing on the cat. The cause-effect feedback loop is so tight that even an idiot couldn't miss it.

The proper way to deal with imminent failure in juggling is to identify impending disaster as soon as possible. Once identified, there are certain procedures that can be performed in some cases. If you catch a pin backward for instance, there are throws that are guaranteed to fail, and there are throws that are more likely than not to succeed in restoring balance to your formation. If there are no tricks (or you haven't learned them), then your next best goal is to get all of the flying objects safely in hand, take a deep breath, and then start again once you've regained your composure. Slow and steady is the trick, and juggling can teach it. In fact, now when my juggling is going fairly well, a sense of calm descends on me now. This is a complete 180 from what happened when I was first learning to juggle, and what I see happen to many of my coworkers when a project gets serious.

In most of these bad software projects, I've found myself with the sad distinction of being the sole remaining rational mind. I wasn't the one being the most 'productive', at least in the eyes of my panicked manager, but I was the least frazzled, and the one working the least overtime when the project was way behind schedule. Why? Because I only signed on for attainable goals, no matter how unattainable the overall milestone. I complete my tasks, without sacrificing quality, in time for the official milestone. Then when the project slips (and it will slip, because it was always going to slip), the unofficial milestones are set. In theory, this should reduce the level of panic on the team, but at this point everybody (but me) is already emotionally exhausted. In reality, things are about to go from very bad to much worse.

In addition to being exhausted, the project in already tainted because of all of the compromises that were made in order to try to hit the unreasonable (and ultimately fictitious) deadline. Even if this version of the code manages to ship, everybody is now standing knee-deep in the hole they dug at the end of the last development cycle. Which means that when the next cycle begins, panic is waiting just around the corner. After a few cycles of this, the code is so bad that people never stop being panicked. At some point they settle into a sort of shell-shock (aka burnout) that can only be treated by time and distance from the cause, if in fact it can be treated at all.

So I challenge you all to go out, and learn to juggle, or at least learn to learn to juggle. Even the theory of juggling has copious parallels to your professional life. If you don't see them too, I'll be very surprised.

1 comment:

Martin KlĂ­ma said...

HI Jason,

I have read your comment here: http://startingdotneprogramming.blogspot.cz/2013/04/i-knew-programmer-that-went-completely.html

and also found your blog and the article about juggling thing.

I like your way of thinking, it seems to be similar to what I discover recently.
Do you have any new experience, after almost 12 years which pass by when you wrote this article? I would really appreciate that.

Thanks,
Martin