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?
Really?
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.
Ready?
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
- Where all the log forms are kept, and
- how long you spend on each task, and
- Adding in new tasks whenever needed
For most the developers I know of, after a day of hard work, they would rather:
- Play, or
- 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.
