Software Project Schedules are Uncomputable
All the heat and noise over the delay of Windows Vista reinforces one thing I have come to believe: software project schedules are uncomputable (more on this technical terminology below). It is foolish to be going around announcing dates years in advance. I have no idea how project managers in Microsoft can ever precisely predict a delay of a few weeks several months in advance. We have taken our lumps when things got delayed [OK, we don’t have complex multi-year schedules, and frankly, I wouldn’t know how to create one!], and what we learnt was to be very careful promising release dates. I posted on this before at Scale Invariant Slips in Software Release Dates.
I believe the problem is fundamental and theoretical. I alluded to this earlier when I used the word “scale invariance”. Basically, the problem is that the job of creating a project schedule from a given set of requirements is an uncomputable function. The everyday meaning of the term “uncomputable” is that there is no step-by-step, determistic algorithmic process that can guide you in effort estimating the project. The human project manager is basically doing a whole lot of guess work. Let me elaborate.
Consider the situation in a well-understood project management activity like building a house. In building a house, it is possible to precisely spell out every step in the process. In effect, the project manager has created a “program” i.e schedule detailing the steps in the process. In a few years, it is possible that this schedule could be fed to an automated robotic construction system which builds the actual house. What is required is to estimate how long it takes to run the schedule, assuming human or robot workers carrying out the various steps of the schedule. We now have to make a crucial assumption: the schedule has no loops, no go tos and no recursions, so estimating how long each step would take should be possible, so the entire building schedule could be estimated. What is the meaning of not having no loops, no gotos and no recursions? Basically the building construction schedule is a linear workflow, where an activitiy sequentially succeeds another. Branches are possible, but no looping is allowed.
It is obvious why we need to no while loops, no recursion, no gotos condition: the effort estimation problem is impossible with these constructs, due to the famous halting problem. If any significant innovation is required in building a particular house, these conditions will likely be violated, and effort estimation again becomes uncomputable. This is where software project scheduling comes in. In order to effort estimate a project, the project manager is in effect constructing a “schedule program” detailing how the software will be built, based on the given requirements. But unlike in the building example, it is rarely reasonable to assume that the schedule program will have no while loops, no recursions or no go tos. In fact, a trivial example of a while loop is the bug-fixing loop: while (bug_exists) {//fix it} and that is unavoidable in any software project.
Any reasonably complex software schedule will have loops. If the high level schedule for a complex software project does not contain loops [the “pointy haired boss schedule”], then it is likely that some box in that schedule itself does. In effect, what the higher level schedule would have done is to specify “Build this module in 3 months”, without specifying the schedule for the module in question, and it may turn out that the module is itself not estimatable.
Given that the schedule program has loops, the time it takes to run the schedule program [i.e the time it takes to build the software according to the requirements] is not predictable in advance. The only way to effort estimate such a schedule is to actually run the project and see how long it takes. Doesn’t it feel like this is what Microsoft is effectively doing - just “run the project and see what happens?” The only part they seem to be doing wrong is to announce their estimates of when the project will end.
Now coming to scale invariance. Scale invariance is basically a recursive process. As soon as you have recursion (or equivalently while loops or gotos) in your program, you cannot algorithmically guarantee runtime behavior. My contention is that software project schedules have a lot of recursion in them.
Isn’t this a cop out? What are project managers paid for, if they cannot estimate and stick to schedules? That is a subversive question - I will take that up another day.