A couple of years ago I had an interesting experience that I think I’m finally ready to talk about.

It all started when I was sitting down with some of the project management folks trying to plan our upcoming work. We were engaged that very non-agile but still common task of planning what to put into a release based on a date. Not great, but sometimes a guy’s gotta do what a guy’s gotta do. Anyway, we had disposed of the major tasks — A handful of features here, an incremental improvement to the UX there, some systems stuff to help with reliability. Then the subject of bugs came up. What bugs are we fixing in this release?

It started well: We began with the major bugs: Yes we need to fix this one and oh yes that other one. That’s why they call them major: It means you should fix them soon, certainly by the next release. But then we came to the less than major bugs. Some of those were easy too: Sure that one’s just an annoyance, but it annoys me, so let’s fix that one. And this one. That one sounds simple but would require a major redesign, so no let’s not fix that one.

At this point my colleagues and I had a difference of opinion. I thought we were done, but they wanted to talk about the minor bugs, the ones that annoy a few people a little or a lot of people a tiny bit. Which of those were we going to fix? Keep in mind, this was not the customer complaining that there were too many bugs or that the bugs we had identified as minor were in fact huge horrors. This was an engineer and some project management folks trying to work out our plan. I tried to explain: Minor bugs are bugs that you fix as time allows. If I had my way, I'd fix them all, right now. But given the constraints of reality, you take them on a case by case basis: If Fred has time, by all means have Fred work on the minor bugs. If Sally finishes early, put her to work on them too. If I ever get out of this meeting, maybe I could fix a few. So I suggested that we could either say in the plan that we were going to allocate a block of time to fix the minor bugs or that we are going to knock off the minor bugs as time allows and let it go at that.

Alas no. My project managing compatriots were adamant: We needed to know now, right now, which of these very minor bugs we were going to fix in the next six or eight months. The question that I kept asking over and over, a question which seemed to embarrass everyone, was Why we needed to know this? Possibly, things will go really well in the next few months and we will squish every known bug in the system. Possibly things will go badly and we won't have time for more than a few. Why make a decision now that we know will not survive the next phone call with the customer, let alone the next crisis? And the answer was always the same: We are building a plan and the plan must be complete. I'm afraid that things got rather heated.

Now don't get me wrong: Plans are great: If you don't know where you are going you are unlikely to get there. Unfortunately I think there is a tendency to think that since planning is good then more planning must be better. And it just ain't so: The only thing that you really are in control of is what you do today, right now. No plan in the world can change the past, nor can any plan absolutely determine what will happen in the future. For that you need to wait for the future to become today and then do the right thing. A plan that sets you on the path today so that you can do the right thing in the future is a good plan. A plan that pretends to be able to reach into the future and eliminate all uncertainty isn't really a plan, it's a fantasy.

Still I did make a plan that day: Sometime, I thought, sometime in the future when I have calmed down a bit, I'm going to blog about this.

Mission accomplished.

– Russ