Saturday, June 03, 2006

When is overtime something you should do?

Typically I don't like mentioning work on my blog. I like to use this as a space to talk about life outside of work. Plus that way, I also don't have to watch my mouth about giving away trade secrets. Course, I don't talk about my pet projects either. So here I am, on a weekend, debating whether I should work this weekend to try and catch up on my timeline. Working weeks is a two edged sword, that more often than not, will lead to more problems later.

So here are some things that you should weigh when you are thinking about working a bit from home. First off, as I made I list, it really distilled down to one pro and one con. The main pro, is that you are going to stay closer to any deadlines and thereby impress friends and coworkers as well as reduce deadline stress. But the con is equally insidious as you are effectively reducing your work stamina. Sprints just lead to longer rest periods where your brain, no matter how many pep-talks you give it, refuses to be productive. For the most part, I think most of you all recognize this.

The one that I personally worry more about is your velocity. I am borrowing this term from eXtreme Programming (which I am sure found in one of the many volumes of project planning).
So let's say that you have created an estimate of 3 weeks to project completion. You get to the last week and put in a lot of effort to get it across the finish line. In the worst of cases, you have now created an expectation in the eyes of others, that this is how you operate. Even in the best case, you are going to forget that effort in your next planning round, and put out another inaccurate estimate.

Doesn't it seem weird that we never overestimate? I don't really believe this is because we are lazy about our work. I think that we are going to make better products with the time we have. We add in additional tests. We add in better error checks and handling. We add in new buggy features and fancy crap too. It seems to be the nature of the beast. Usually the best cases are the ones that are made from short iterative design steps. And those deadlines are the ones that carry weight. This in theory, reduces the impact of late timelines, but only if you don't plan the next iteration till the current is done. However planning dependencies is a good thing as these drive the completion of the current deadline.

Ok, I am starting to ramble, so that is a sign to stop. Maybe I will compile this into something more guideline, process oriented. Probably not though.

No comments: