|
|
|
|
|
|
by quietbritishjim
1785 days ago
|
|
|
I like the advice in Thinking Fast and Slow by Daniel Kahneman about estimating, which is not specific to software but still very applicable to it: Start with a known past project that is in some way similar in magnitude and adjust from there. For example, "this is twice as complex as some other project I did, and that took 2 months so this one might take 4 months". Most importantly, resist the temptation to say "although 1 of those 2 months was because of unexpected thing X so I shouldn't include that". Overall, it's highly flawed, but much less highly flawed than anything else. This is called "reference class forecasting". He gave a really compelling explanation of why estimates are almost always underestimates by a significant amount, and this technique is the best defence against it, but I won't try to resummarise because I'll surely misrepresent it. But I do recall he gave an example where he and some colleagues were trying to make a school syllabus about deductive biases, and underestimated the effort required for their own project. |
|
|
"Dr. Kahneman, you've been at this for 40 years. Do you think you've changed anyone's ways of thinking?"
He smiled and said "No, not even my own!" and then recounted how in his personal life he'd made a mistake which he'd written about extensively (not the one about planning, though). It's a human failing, not a methodological one.
I'm also vague about his example, but I think it was a new textbook. He asked his committee to reflect on their own past experiences with similar books. "Two years" was the past experience. Then they decided that it really should be six months, and that's the estimate they went with.
No one wants to accept that shit happens and it's going to happen again. That's why estimation is hard.