I’ve noticed a strange property of good blog posts: their ideas are obvious to the author, but not to most other people. Not obvious ideas in the sense that anyone would notice — that breaks the other half of the rule — but obvious in the sense that you don’t really think about the idea any more and just consider a fact of life.

So here’s my first obvious idea: software schedules are impossible. If you have a plan that says you’ll build a product with such-and-such features in 4 months, it is wrong. Almost certainly, you do not have enough data to determine the full scope of the work, and even if you did, you would not have enough data to determine the velocity of your development team.

“But wait,” you say, “everyone knows waterfall planning doesn’t work. That’s why we have this fancy agile methodology with daily scrums and lots of iterations where we constantly manage our plans so we’re not committed to some bogus plan hatched a year ago by some suits.”

Ah, good point. There are some good methodologies for tracking your progress and making sure your team performs at top speed. If you’re team isn’t using some form of one of these you’re probably screwed.

BUT you don’t have a schedule. A schedule is something that says “X, Y, and Z will be done within 20 days”. If you’re changing the the work or the deadline it’s not a schedule. And in software, it’s possible you won’t have to change the work or the deadline, but more likely you’ll need to change both. Imagine if your mechanic were that unreliable.

Of course, you could spec the whole thing in great detail first. If you were able to write down a spec that was sufficiently precise, to the point of breaking down to steps that, when assigned to a team member, make them think “oh, I just did something like this yesterday and it won’t take more than 2 hours to do it but with the blob on the left” — if you can do that you might be able to have a schedule.

I think the agile methodologies, and the army of highly-paid consultants who promulgate them, have done something pretty smart here. They’ve realized that people don’t write specs that detailed because at that point you might as well write the software. They’ve simply adopted the spec-writing into the coding. Which is exactly as it should be. As our programming languages become more powerful, our code gets more readable and — guess what — it starts to look like a spec. Oh yeah — they call it the executable spec.

But the basic promise of agile methodologies is schedule management, not a schedule. You don’t generate a schedule, you converge on it. By writing the code. When you’re done writing the code you know the schedule. This is the state of the art: you know when you’ll be done when you’re done.

So let’s just admit it: we’re too uninformed, incompetent, and/or ambitious to write an accurate schedule for software development. Just assume that the software development isn’t going to follow a schedule and tailor the rest of the business to react to that.

Unacceptable? Well, I could give you a schedule, but I’d have to lie to you.