If I asked you how long it would take you to write a program to sum a list of 1,000 numbers that varied from 0 to 20000 after reading them from a file, I'm sure you could give me an answer that would be very accurate on the time frame of days.
Most programming is applying known solutions to known problem types and can be estimated quite easily if people take the time to account for everything The problem I see is that most of the time, they don't. They ignore how long it will take to test it, or to update the documentation, or that they don't quite understand the problem, so they'll have to find Jean in Accounting to explain Requirement 2B to them, etc.
In a healthy development environment, you can separate the "problems we know how to solve" from "the problems we don't know how to solve yet" and deal with them separately.
> If I asked you how long it would take you to write a program to sum a list of 1,000 numbers that varied from 0 to 20000 after reading them from a file, I'm sure you could give me an answer that would be very accurate on the time frame of days.
Is a console utility sufficient, or do you need a GUI?
Is the file we're reading in a specific location, or do we need to be able to specify the location at execution?
If using a GUI, can the user type the path, or do we need to provide a specific file picker UI?
What platforms is the utility expected to run on?
Can we assume that the file is in the format we expect, or do we need to perform any validations?
If we find that the file is invalid, what action should we take?
Does the output of the tool need to be machine readable?
Yes, I'm being a bit silly, but that's kind of the point. Even those of us who know how hard the problem is often oversimplify matters. That's the root of the challenge, and the reason that even seemingly simple projects are difficult to estimate accurately.
To compound this problem, you'll often find that the customer will answer the set of questions you propose differently on the first day than they do two weeks in to the project. "The situation is fluid", so to speak. All of this adds up to a lot of uncertainty in the estimating process.
You are, of course, correct. And in the absence of any context, I'd say those questions must be answered. Note that the time required to get them answered (requirements gathering) should also be estimated.
However, in most cases, there is a surrounding context to that set of "requirements" I gave, so you'd probably be able to answer accurately.
The overall point is that you still have some idea of (a) how long it will take and (b) what level of confidence you have in the estimate.
I hate to go back and forth, but I spent 6 years doing freelance work, and I hate to see people repeating my mistakes. They can be costly. I would "probably" be able to answer accurately, but we're definitely talking probabilities here.
I learned that estimating was really a negotiation of risk. When I put an estimate down on paper, I'm saying to a customer, "I accept responsibility to deliver the product for this price." I'm taking on the risk if I don't, so I pumped the prices up. Also keep in mind that "the product" is what's in the customer's mind, not yours.
At some point I decided that I needed to have the "risk negotiation" conversation with all new clients in very candid language. Once a client is aware that they're paying for you to take the risk, they're usually willing to buy some of it back. Customers who were willing to buy back some risk always turned out to be better to work with than customers who wanted to offload all the risk to us. It turned out to be a marker by which I would steer the course of client development.
If people were actually to "account for _everything_" they would have, by definition, solved the problem already.
So the time to make the estimate would be 100% of the project time, and the estimate would be 100% accurate, since all the work would be done.
That is reductio ad absurdum, but the underlying problem is, as Donald Rumsfeld would say, there are "unknown unknowns" which cannot be accounted for ahead of time.
No. Accounting for everything is not the same as doing everything. You can tell me it will take a week to implement a feature and it may take you half an hour to come up with that estimate. It doesn't mean it took you half an hour to implement the feature!
Then I wouldn't be accounting for everything, and my estimate is most likely wrong.
I might not account for the cat tripping over my network cable.
I might not account for a server unexpectedly crashing.
I might not account for the office being too noisy to think in on Tuesday.
I might not account for Amazon having EC2 issues
I might not account for a DDoS attack on my DNS provider.
All of those things impact the time it would take, and the only way to fully account for everything that could happen would be to actually complete the project. Of course, if the project was identical to one I've done before, I could get a lot closer to an accurate estimate, with fewer real unknowns, but in 20 years of software, I've never had to create an identical solution. Because if it was an identical problem, I'd just use the previously developed software.
If I asked you how long it would take you to write a program to sum a list of 1,000 numbers that varied from 0 to 20000 after reading them from a file, I'm sure you could give me an answer that would be very accurate on the time frame of days.
Most programming is applying known solutions to known problem types and can be estimated quite easily if people take the time to account for everything The problem I see is that most of the time, they don't. They ignore how long it will take to test it, or to update the documentation, or that they don't quite understand the problem, so they'll have to find Jean in Accounting to explain Requirement 2B to them, etc.
In a healthy development environment, you can separate the "problems we know how to solve" from "the problems we don't know how to solve yet" and deal with them separately.