Red Pen, Black Pen

Or: How to succeed at a requirements review meeting.

If you work in software development (and I include management and testing), then it's safe to say that you have a requirements problem. In fact, if my experience holds at all, most of your problems are requirements problems, whether you realize it or not. Any and every trick that helps with requirements is helpful, but the simpler the better. The simplest one I know of involves pen and paper.

If your responsibilities include digesting requirements documents, then I have a piece of advice that's saved me countless hours and more than a couple follow-up meetings: First, get yourself a red pen. Second, any time there's a reading of the spec documents (group, or individual) bring your red pen AND another pen (blue, black, it doesn't matter). Third, color code your comments.

After the reading of the specifications or requirements, you're going to discuss the outcome with others, and adjust other documents (like the schedule, the task list, the test plan) accordingly. As time progresses, your recall of the review will become progressively fuzzy in your brain. Even walking out of a long review meeting, you've probably forgotten at least one critical detail, and even if you've written it down, it's easy in scanning a document to miss black comments on black print. If all of the critical notes are made in a high-contrast color, then the odds are working in your favor.

The process is pretty straightforward. All of the 'bad news' you find in the spec is either written or circled in red. Bad news usually means one thing: schedule slip. This can include things like:

• Clarifications
• Addenda
• Surprises ("hey, why didn't I notice that before?")
• Open questions (surprises we haven't met yet)
• Your own commentary on how a requirement should be executed

Good news, spelling corrections, and simple clarifications can be made in the neutral color.

If you're reading the spec professionally, then you're probably also responsible, in some fashion at least, for time lines and estimates based upon that specification. Every change or discovery in the document that wasn't covered by previous readings represents a three-fold risk to the success of the project. One, surprises represent more work than you previously signed up for. Two, early surprise is much better than late surprise (pain avoidance kills). Three, a high number or degree of surprises indicate a systemic problem with requirements gathering, organization, or hand-off. Identifying that problem should be a high priority for the team, and fixing it should be a high priority for management.

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.