A common question heard in companies that produce software, either for in-house use or for sale, is “When will this software be done?” I’ve observed this question being asked when it was not yet decided what the software was to include, nor who was to build it. It’s clear that we have little on which to base an estimate, given this state of affairs. Nevertheless, in many organizations, people will start to anticipate what it will include and who will be available to build it in order to give an answer to this question.
Not everyone is so compliant, though. Some people will say that not only can you not estimate the construction with so little information, but you don’t need to estimate it. They’ll say it’s enough if you can build it in little increments of functionality, and stop when it does enough. I’ll grant them that this is a fine strategy for building software, but It doesn’t give an answer the question.
Should you give an answer to the question? Often people worry that their estimate will be treated as a commitment, and they’ll be found at fault if the date is not met. Too often this is the case. In such an environment, refusing to give an estimate will likely not enhance your reputation, either.
Assuming that the question is actually asking for an estimate, telling the questioner that they don’t need an answer seems a bit presumptuous and disrespectful. Who are we to decide that their question is of no value? It seems to have value to them. Maybe it would be better for us to learn why it has value to them.
With two options, we find ourselves between a rock and a hard place. We either make a lot of assumptions and do a lot of work for a date that may have little value, or we take an opposing stance to the expressed needs of the questioner. But what really are those needs?
If I’m feeling comfortably safe, I might answer the the Date Question with “42.”
“42? What kind of date is that? What do you mean?”
“What do you mean by ‘when will the software be done?’ What will you do with the answer?”
When we ask the Date Question, “When will this software be done?,” we have more in mind than a simple date. Perhaps we thought it should be done by now, and we’re expressing our impatience. Perhaps we’re getting ready to start, and we want to put time pressure on the development team so they’ll work as fast as they can. Neither of these thoughts have much to do with an estimate, though the request may be formatted as if it were asking for one.
We might, however, be trying to make a decision. Perhaps we want to know if we’ll have a viable product by the Christmas season, or in time for an industry conference. Do we have time to undertake this project? Or perhaps we want a rough idea of how much the project will cost, multiplying the duration by the cost of the development team. If we compare this cost with the expected value of the developed software, is the project worth the investment? Maybe we need to produce packaging, or training courses, in parallel. When will these things will be needed? There are many perfectly valid reasons for estimating the end date of the project.