|
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 |
||||
|
|
|
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 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". |
|||
|
|
|
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: Intuition might tell you that translates to software development like this: While in fact it's more like this: 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 http://www.methodsandtools.com/archive/archive.php?id=79 Good luck! p.s. sorry had to cut out some of the links to the essays I mentioned because I have to earn more than 10 reputation points for that. Just Google them. |
|||
|
|
|
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 |
|||
|
