As a professional software developer, I'm often stymied when asked for an estimate on how long a given program or feature will take to design and implement. The problem with making such estimates is that I'm rarely doing the same thing twice. Software doesn't wear out, so if it needs to be written, it hasn't been written yet.
In the past I've used my father's profession (machinist) to provide contrast. Machines wear out due to friction. Over time, parts of the machine will require replacement. After the first time you machine a part, remove the old part, replace it with the new part, you will have a good idea of how long it should take the next time. Software doesn't wear out. It might need to be replaced, but if so, it's because it was inadequate in the first place, not because a part wore out.
I bring this up because I came across an article by P.J. Plauger (a respected computer scientist) from the February 1991 issue of Computer Language (reprinted in the February 2006 issue of Software Development) that said this better than I could ever hope to. An exerpt:
Heresy 2: If you've never done it before, you don't know how to do it. ... what makes programming unique is that we have trouble judging the depth of complexity we can't fully grasp all at once. Thus it's particularly difficult to estimate how long it will take to write a new program. The more new things lurking in the program specification, the more out of control you are as a programmer. Take one try to figure out how to write a program, and a second to figure out how to write it elegantly. After three times, it should be good enough that you need never rewrite it again.
This exactly describes what happened to me when I started my current position. After three tries, we have a program that receives very few defect reports, but I couldn't get to that stable program without writing the other two versions first.
Go Top