clog

Several months ago an exceptional former manager of mine planted a seed in my mind about how to determine project timelines. We were discussing the timeline of a particularly complex calendaring project and he suggested that it may be impossible to determine such a timeline. At the time, the idea of my manager telling me something like this is impossible struck me as odd. It flew in the face of everything I had learned in my software engineering classes. I had already discarded most of the things I learned in those classes as not being compatible with the real world, but the concept of mapping out timelines remained. I felt that an experienced manager should be able to determine an approximate completion date.

The more I’ve thought about this, the more I believe that my former manager was right in more ways than he realized. The only way to be able to determine an accurate timeline is to draw on previous experience so you can predict the future. The problem with software development is that there is almost never any previous experience to draw from. If you’re repeating an old project or something very close to it - than the work is really already done and you don’t need to bother with much development. Otherwise, you’re treading into the unknown. How long does it take to build the unknown? It’s a shot in the dark at best.

I still believe it’s a good idea to have target dates. They provide something to work toward and keep productivity high. Be prepared to meet those targets with reduced feature sets though as certain pieces of the technology don’t work out and/or prove to be more complicated than originally expected (which is often the case). Don’t get rid of good workers because they couldn’t predict the impossible. Definitely don’t make the mistake of promoting a hard launch before you have a product that works! It doesn’t take much research to realize that this approach fails more often than not.