Schedules and Perfectionism

Schedules suck.

Each time we make a software development schedule, we do so despite two glaring problems:

1. It’s really tough to estimate or forecast any substantial development project. (That’s the long version of “schedules are useless”.) Looking at any large successful software project in hindsight your estimates and schedules appear naive if not ridiculous

2. We also can’t deny that schedules themselves (or is it deadlines?) are a huge cause of stress. Assuming the wrong time scale causes a ton of stress, but so does simply having a deadline at all–even if it’s easily within reach. I was talking to Tanner about this the other day– having given a customer a delivery date for a two hour mod, and how that suddenly put a pin in the otherwise smooth fabric of his day.

Yet, we also all seem to have a sense that schedules are necessary at some point: that they can help us accomplish what we want to get out there in the world. I just can’t articulate why nearly as forcefully as I can talk about how they suck. But there is something  worthwhile to a schedule, even if we only occasionally glimpse it.

– The cautionary tale Dreaming in Code rings true to many of us: without much pressure to ship, they never do.

– Our big, sprawling project for Blueprint, despite its wandering scope, has been timeboxed into two week, and now thee week, sprints. That works: agile works. Code gets shipped, customer problems get solved, though it’s definitely stressful.

– There also just seems to be something behind the saying that “without deadlines, nothing gets done”.

So, given that we don’t have a great model for what a software schedule should look like, how can we decide if we have enough of a schedule to make progress without wrapping ourselves in futility and stress?

A good schedule answers two questions.

I’d like to suggest two things a well made schedule can accomplish, two questions it can answer:

1. Am I working on the right thing?

This may be the roadmap / checklist part of the schedule instead of the “deadlines” part, but we can spend a lot of time on the aspects of a project that frighten / intrigue us only to emerge from them to be surprised by the vast amount of work remaining. (And in some sense a schedule is just about avoiding surprises.)

2. Should I stop polishing / researching and move on?

Given that we can endlessly perfect and refine these things we’re making–AND given that this may be what drew us to making things in the first place–we need something to help us stop. A schedule can let us know when we’re ahead, when we’re behind, and how much time we have for research, polishing, and play.

A good schedule would let me know on any given day if it’s time to move on, to deliver (monetize?) the insights I’ve gathered so far, or if I can keep feeling around for something better.  “Moving on” can mean shipping a feature, or adding hooks so it can be modded later, or even pulling things so that a customer can “finish” a feature their own way.

The real benefit of schedules.

While I think we definitely need a mechanism for answering the two questions above, the real benefit of schedules may lie in this: they are a refute to perfectionism.

Perfectionism is tough because its side effects are usually positive; perfectionists tend to check their spelling. Yet we know it can cause all sorts of hard-to-spot but truly destructive practices: premature optimization, polish-paralysis, not-startingness. The worst problem with perfectionism, however, is that it’s about protecting ourselves.

“Perfectionism is not about achievement and growth. Perfectionism is the belief that if we live perfectly, look perfectly and act perfectly, we can avoid the pain of blame, judgment and shame.” – Brene Brown

Thus, perfectionism is inherently inward looking: and that is real poison for software development.

Schedules–good ones–force us to look outward. At the customer who’s going to use and mod what we’re making–at the customer who can’t wait to get it and is asking us about it on our support forums: a good schedule makes us focus on building the software for them, not for us.

Cautions.

A couple obvious things I need to keep reminding myself when actually making a schedule.

– Human beings overestimate the amount of time they have available.

– And software developers underestimate the amount of time it takes to code anything, let alone to package and complete it.

– Some of the most important work SeedCode has done has come from screwing around on stuff that wasn’t originally in the plan. So while I often fantasize about keeping the roadmap part of the schedule, and chucking the deadlines, it may be the roadmap that’s the truly dangerous part.

– How to plan for wandering around the roadmap seems like a good challenge.

Part 1 of this article can be found here.