A few days ago a sales manager asked me that question. But at this moment I didn't know a answer which he can understand. He isn't a programmer!
At the moment I work on a product which is over 8 years old. Nobody thought about architecture or evolvability. I have a swamp of code in front of me every day which is not tested. Because of that, time estimates are very difficult for me.
How I can describe that problem to an salesman? Not only my swamp-code-problem, but general!
Ask him how long it would take to find his way through a maze. Not any particular maze, or any particular size of maze - just "a maze".
Programming is in some ways similar. You can't be sure how long it will take until you have fully explored the problems you'll need to solve. The only time you can be sure you've done that is when you already have the finished product.
The housebuilding analogy comes to mind: how long does it take to fix up a house? You won't know until you know what shape a house is in, what kind of work needs to be done. Is it just painting, or do you need to rewire the place, knock out walls and stuck up a new roof?
I do however think that if you take an inventory, (and based on the lines of code you could estimate the time to take an inventory more confidently) you can then be more specific on what you expect that needs to be done, and how much time it would take. (This is a two way process: by documenting the different issues you get more understanding of the project, and by getting to know the project you get a clearer view on the issues. So take some time to analyse the situation and take time to write your explanation as to why you think something will take the time you think. By the need for explaining it to someone else, it gets clearer for you.)
(Oh, and don't forget to remind the sales manager that everyone knows someone who started by stripping a piece of wallpaper only to find out that it was actually quite a loadbearing piece of wallpaper being glued to basically sand or crumbled plaster, so they ended up with a big hole and the need to rebuild the wall first. Things that may look like simple cosmetic changes might suddenly uncover a whole range of new problems.)
Estimating software is difficult because:
The solution I use:
Planning Poker in combination of velocity tracking and story points units.
Work perfectly on large projects with team of 5 to 7 developer and very small teams. Important: don't assign tasks. Let the team decide.
"Dunno, why is sales estimation so complex? What about market analysis? Conversion rates?"
Ask him how long it would take for him to take over for a colleague that was hit by a bus. This colleague kept notes in a cryptic format that he'd first have to figure out before he could follow up on the sales leads.
When he says, "I don't know", just smile.
Compare it to forecasting how much product the company plans to sell for the year. It is obviously not exactly the same thing, but hopefully it gets the point across. You could also ask him why it is so complicated to figure how to sell a product.
Start off with 'nine women can't make a baby in one month' and work backwards to the state of your (hopefully still on time) project.
Tell him, you can't possibly document a negative, and the time line for a project that has yet to be delivered is a negative. You won't know until you are close to being ready to ship it.
If the sales droid forces you into a time line, say six to eight weeks (wow, how that has caught on, the highlighted text can be clicked), then revise that starting on week one, after you know what you've gotten yourself into.
To grasp why (time based) software estimates are hard we need to do some thinking on the nature of software development.
The difference between manufacturing activities and design work is probably the most important concept business people need understand. During the industrial era there was a sharp distinction between design and manufacturing. We designed blueprints that were reproduced in a factory as many times as we wanted.
We are applying that same model in our heads to the software development process, we assume that first someone has to design the product after which different people manufacture it. Once you start thinking about when the design phase ends and when manufacturing starts, you realize this doesn't apply to software development. Consider the following representation of a product development cycle:
... => design => (blueprint) => manufacture => (product) => ...
Intuition might tell you that translates to software development like this:
... => design => (Interaction design deliverables) => manufacture => (Source Code) => ...
While in fact it's more like this:
... => design => (Source Code) => manufacture => (Software application) => ...
In other words: The source code is the design not the product! Manufacturing software is completely automated (compiling the source). Others have explained this far better than i can, I would recommend you read this essay by Jack Reeves: What is Software Design?
The difference between design and manufacturing is not just a conceptual one and has some very real implications for the way we manage software development. Design work is by nature highly unpredictable and depended on individuals while manufacturing is much more predictable and depended on resources.
From this line of thinking follows that variation of individual productivity among developers is so high that it's impossible predict how much someone can produce in a certain amount of time. For more insights on this, check out the following essay by Paul Graham: How to Make Wealth.
There are many more implications of the 'design != manufacturing' way of thinking. Another important one is the fact that you never set out to design something that's already available. This adds to the amount of uncertainty in development work.
Combine these with the many reasons business people pressure developers into lower estimates, plus the fact that people have a hard time estimating absolute measures and you got your self a recipe for highly inaccurate estimates.
If your Sales Manager still has doubts, this article might clear it up:
Fingers in the air: a Gentle Introduction to Software Estimation
...software development community has a very poor record in estimating anything—in fact is very common for projects to run over-time and over-budget, and deliver poor quality products with fewer features than originally planned.
Part of the problem is that software is quite difficult to estimate. In fact, huge differences in individual productivity, the fact that creative processes are difficult to plan, the fact that software is intangible, and the fact that during the life of the project anything can change - e.g., scope, budget, deadlines, and requirements—make software estimation a challenging task.
However, in my experience, the main cause of poor estimates is that the various stakeholders are often unaware of what estimates are for, and what they should look like. This lack of knowledge means that they have no way to judge if the project goals and the associated expectations are realistic. The result can be either overestimation which causes the allocation of an excess of resources to the project, or, more often, gross underestimation which often leads to "death march" projects [You], which are characterized by "project parameters" that exceed the norm by at least 50%, e.g.:
- The schedule has been compressed to less than half the amount estimated by a rational process
- The staff is less than half it should be in a project of the same size and scope
- The budget and resources are less than half they should be
- The features, functionality and other requirements are twice what they would be under normal circumstances
The rest of the article is an introduction to the software estimation process aimed at project managers, developers and customers who want to get a better understanding of the basics this subject, and avoid to make their projects a death march one...
Ask him if he as ever worked on a crossword or better yet a sudoku puzzle. Explain to him that software development requires a constant refinement after certain unknowns become known. As your understanding increases so does the accuracy of your estimates, at least some of the time.
If that fails, ask him "How long does it take to find your keys?".
Just tell him that after 8 years the project is very large. Now when you introduce some small change it can trigger more changes in the system before you can make it to work and that doesn't depend on you.
You must
1. make your job / write your code
2. test it
3. then test how the change will interfere with other functions of the system.
4. correct the system's behaviour.
You can estimate 1 and 2 but you can't tell how the changes will interefere with the whole big thing before you have it done. Because that's impossible without testing. And sometimes you'll have just to write your code and everything will work instantly and some other time you'll have to make many other changes in the system beside just writing the new functionality to make it work as intended.
It has been proven that you can solve any Rubik's cube configuration in 20 moves or less (http://www.bbc.co.uk/news/technology-10929159).
Ask how long it would take to solve some Rubik's Cube you can only look at, but not pick up.
The software in question is probably vastly more complex than a Rubik's cube, but often you're only allowed to "look at it, but not pick it up and fiddle with it".
I'm guessing you rarely give estimates that are too high. Make sure you're not operating under the fear/reluctance to give a lengthy estimate. All good sales people will try and convey a high-level of urgency for a client request. In your mind you're scrambling to figure out what is the least amount of time it will take.
If you have some questions, offer to take a quick look at the problem so you can gather enough information to make a better estimate. You also need to be able to determine how much time you will have available. Don't promise something in 10 days when you're on vacation for 2-weeks.
For the over-worked part, find out what previous request they want you to re-prioritize. You'll be shocked that more than half the time they'll want you to keep working on the previous one.
I have to disagree with some of the given answers. You can't compare programming to finding your way through a maze, I agree that there's a learning aspect but there isn't much skill in solving a maze. Neither is it like building or renovating a house, that is a pretty defined process.
The best analogy that I've come up with for programming IMO is like an artist painting a picture, it's impossible to estimate because there is an artistic aspect and more painters doesn't finish a painting sooner (well they might, but not better). People tend to think about programming is like engineering but in fact it's more like craftmanship with a little artistry, and that's tough to estimate
