Monday, February 7, 2011

The curse of rigid deadlines

Suppose that you have to write a client to a server. You have a spec with missing details. The person who you can ask details about the spec is on vacation. You start to code. You make an architectural mistake by misunderstanding a vague part of the spec. You wait to be given a user name and a password for the server. 2 weeks pass. Meanwhile you code. Finally access to the server. You find out from trying the server, about your architectural mistake. Now it takes the same time to redo the arhitecture or to continue with the existing one. You decide to continue with the existing one. The project manager moves to another project. A new one arrives.

Some unplanned problems, unrelated to the architecture, occur, which slow down the project more. No server access for some time, again. Milestones come and go. They're missed, but the end date of the new ones remain the same. You're stressed, that you won't complete the project in time. You are slow because this is your first project in this language. Not all the features are assigned to people, so you cannot plan ahead (do things that will slow down at first, but then speed up afterwards). You cannot work well because of this stress. The project slows down even more. You cannot take a vacation to free from stress, because that will slow down the project even more.

Here is another opinion about deadlines:

Whole project deadlines may not work even if they are 100% accurate. The problem is, that a programmer does not know in how much time can he do a task that he has never done before. Deadlines are helpful only in repetitive tasks. And even then, only when they are very close to the achievability level. A factory worker who makes shirts and knows that he made 38 in the first 4 hours of the day, and he has to cut 80 that day, is motivated to achieve that target, by speeding up for the next hour and making 11 that hour, and having a feedback that he is now closer to the target.

Too aggressive deadlines are bad because of the stress of thinking what will happen to me because I miss the deadline, plus the fact that I try to take shortcuts (making the program less testable) that prove to be wrong (more debugging time, because the bugs are much harder to find).

No comments:

Post a Comment