I have been in the IT industry for over 13 years now. Long enough to have worked directly for a eight companies (excluding name changes, twelve with name changes). So you could say I have seen a few different company cultures.

In that time I have never ceased to be amazed by peoples optimism and inability to learn from past experience. People make the same mistakes over and over again. Nothing highlights this better than when people develop estimates for a project. It seems like people just forget the lessons of the previous project. They do things like:

  • Do not allow time for proper testing;
  • Schedule time for reviews, but then do not allow time for rework;
  • Say there is not enough time for doing a proper design to try and save time (XP guys, please talk to the hand:-); and
  • Convince themselves that everything is easy - this manifests itself that if the requirements are not understood, they must be easy.

But the thing I find most sad is when developers allow people who are not doing the actual development to talk down their estimates. These are people like project managers and sales people who do not really understand what is involved in development at the coding level.

Now before you jump on me saying that I am just a bitter twisted developer (which I probably am at heart), I should say that I have spent a number of years as a technical lead responsible for developing the estimates with the developers for projects. I have also spent the last couple of years estimating fixed price bids (and this a whole other story).

I would much prefer a developer to tell me that a component will take 4 weeks to develop and then take 3.5 weeks, than telling me that it will take 2 weeks and then take 3.5 weeks. Sure, I would love them at the start for such a small estimate, but at the end of the project I know who I want to work with again.

I just wish that developers would learn the benefit of the motto - under-sell to over-deliver.

That all said, I must confess that I am not that simplistic in my estimations and how a team of development team should work. Ideally I like to use the Theory Of Constraints as described in the excellent book Critical Chain by Goldratt.