Search This Blog


Friday, November 23, 2007

The problems with Forecasting Software Shipping Date

When was the last time you have successfully predicted the shipping date of your software?

As far as I can recall, we never failed on this effort.

Yes, out of all the projects I participated, we never failed--even just once-- to forecast our software release date, as far as our customers were concerned. We might be late for our own internal milestones, but we were never late for customer's delivery.

Want to know our secret?


OK, let me tell you our dirty little secret. But first promise me you will keep this piece of information to yourself and please, please don't tell anyone that I gave this secret to you.


It's easy, we never tell customer when we can release our software until we are readied. That is, we don't even bother to forecast the software release date. No try, no failure, as simple as that.

We all know how hard it is to forecast software release. There are always last minutes bugs, killer features that are impossible to be left unattended. And it is very, very hard to keep track of software scheduling also. I mean, you the developers love coding but despise paperwork right? How about filing in forms or logs, those boring forms that ask you about what you have done in the morning, afternoon, evening and night? No only that, you need to remember meticulously
  1. Where all the log forms are kept, and
  2. how long you spend on each task, and
  3. Adding in new tasks whenever needed
For most the developers I know of, after a day of hard work, they would rather:
  1. Play, or
  2. Hack even more code
But not filing out forms so that their managers can judge them clumsily.

Furthermore, keeping time logs just doesn't make much economical sense, especially for a small team. Because even if you can faithfully keep all your time, what use is it to it? You still need someone to read everyone else time logs, to extract information from there, update the Gantt chart in Microsoft Project and setting all the path dependencies. All these overheads add up. And yet at the end of the day, no one knows how useful the Gantt chart is.

There are just too many barriers to even track the software development process, let alone to produce an accurate software forecast. Some of barriers, to borrow phrases from the Mythical Man month book, are because of the essence and others are of the accident inherited in software development process itself. Some of the examples of the essence are volatile requirements, difficulties in debugging etc. The accident is, in a large part, due to the decoupling of time log keeping from the software development process and the tediousness in updating all the charts.

But, not all hopes are lost. A good issue tracker can help to reduce the accident, and thereby making shipping date forecast more like a science.

The best way an issue tracker can do this is by directly integrating the time keeping functionalities into an issue. Whenever a developer gets an issue, he will have to set the estimation time, and starts clocking his activities. When everyone starts to do this, the issue tracker will have a wealth of data regarding the developers' time as well as their best estimates in finishing their remaining tasks. Of course, these data can be processed in order to give a meaningful interpretation of the current stage of software development. It can then be used to generate forecast as well.

A neat solution, isn't it?

Of course, there are more to using an issue tracker as a software project management tool. This I will explore in the future posts.


Dan said...

This is a great post. I am going through great gnashing of teeth with my boss, who is also the owner of the company. He's got no background in software, in fact no technical background at all.

He has refused to lock down the product, he's constantly changing the user interface. He's constantly adding features & changing the behavior of existing features. He's adding new hardware (this is an embedded product) and changing hardware (changes due to cost -- "Can we replace part "X" with part "Y"? Yes? But it requires changes? Why? Aren't they compatible?")

And the biggest problem is this: he refuses to allocate any time to project management or planning. He doesn't see the ball moving any closer to the goalline when I am updating a spec or doing a basic PERT chart. Then he's furious when I can't guarantee him with 100% certainty that the product will be shippable by date "X".

I told him, "the degree to which I can be confident that the ship date is solid is directly related to how much time I spend RIGHT NOW analyzing EVERYTHING left to be done.... unknowns, dependencies, red flags, open issues, side effects, performance impacts, etc...."

So then he says "OK just go back to developing and get it done as soon as you can!"

And then a week later he'll come back and ask me for a firm date, as if our conversation from the week before went in one ear and out the other.

What a jackass. Anyone need a solid embedded developer? :-)

Soon Hui said...


I have utmost sympathy towards you. The problem with a non technical boss is that he doesn't know the complexities of software development and he still tries to manage the software development activities as if they can be managed like building construction activities. And of course, his ignorance aggravates the problems.

Oh, regarding the matter the boss contradicting himself..well, that's just too common. *sigh*

Pierre-Henri Trivier said...


maybe it is background information available in your blog but ... who are you working for ( and where is the application form ? )

See, I would love to be able NOT to give a delivery date, except that in my world, we have customers that are, ahem, quite, you know, pointy about this 'the site has to be available on the 1st of something'-delivery thing.

I completely agree with you that it is a non-optimal way to work -- customer saying "we want this baby born in two month", and our salesperson saying "sure, we'll just put 5 women on the job", then some other company's salesperson saying 'no, wait, we can do it in less time by using 10 cheaper women in India', etc ...

This usually ends up with the customer buying all this salesperson crap before paying for our developer crap.

Again, I would love to be able to say ' when its done', but that's not what the people we build software wants. As I can remember, when I was doing in-house dev, that wasn't what the other teams wanted either.

So, talking the werewolf into not existing might not be a silver bullet, either.