> 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.
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.