Why software estimation is so hard
I once worked with a guy at JPL who had an uncanny ability to give extremely accurate estimates. You could give him a problem, he could sketch it on the whiteboard, then give you an estimate. He would usually use a 10% margin of error (say, 80 hours +/- 8). And he was always dead-on. I thought it was amazing, and assumed it was because he was such a skilled programmer.
I noticed something once when I was admiring some of his code. I saw some code that he'd written that I knew was available from some pretty common third party libraries. I've always been a lazy programmer--so I steal a lot. I'm always on the lookout for cool libraries and frameworks that I can use. I'd rather not write code somebody else has already written. But Scott wrote pretty much everything he needed (and only the things he needed--he never tried to build-out for a future that might not arrive).
Fast forward 15 years: I've been spending my spare time this week programming. I've decided that every manager should be required to write a certain amount of productive code every so often to keep them grounded in the reality of the technical problems they're supposed to be managing day-to-day. As I reflect on the things that have burned most of my time in the past week I realize that it's usually not my code, but my dependencies on other libraries and frameworks. The very libraries and frameworks I leverage to amplify my productively are also the most unpredictable. If it was only my code, I would be in complete control. If it's some other library that works as expected, I zoom ahead of my scheduled progress. But when I don't know I need to upgrade a third party library to get the behavior I require, I do things like spend time trying to figure out why the library doesn't work the way I expect, then spend time trying to find a solution, then spend time trying to figure out how to work around it, then spend time trying to unravel my stack to get back on track..
Today we don't write modern software without leveraging powerful and complex platforms, frameworks, and environments. This is what makes software estimation so hard--these areas outside our code are so unpredictable.
This is why I'm a big fan of the XP style estimation that uses a "load factor" and "velocity" in estimation. These techniques pragmatically adjust for the uncertainty of the factors surrounding your code.
I noticed something once when I was admiring some of his code. I saw some code that he'd written that I knew was available from some pretty common third party libraries. I've always been a lazy programmer--so I steal a lot. I'm always on the lookout for cool libraries and frameworks that I can use. I'd rather not write code somebody else has already written. But Scott wrote pretty much everything he needed (and only the things he needed--he never tried to build-out for a future that might not arrive).
Fast forward 15 years: I've been spending my spare time this week programming. I've decided that every manager should be required to write a certain amount of productive code every so often to keep them grounded in the reality of the technical problems they're supposed to be managing day-to-day. As I reflect on the things that have burned most of my time in the past week I realize that it's usually not my code, but my dependencies on other libraries and frameworks. The very libraries and frameworks I leverage to amplify my productively are also the most unpredictable. If it was only my code, I would be in complete control. If it's some other library that works as expected, I zoom ahead of my scheduled progress. But when I don't know I need to upgrade a third party library to get the behavior I require, I do things like spend time trying to figure out why the library doesn't work the way I expect, then spend time trying to find a solution, then spend time trying to figure out how to work around it, then spend time trying to unravel my stack to get back on track..
Today we don't write modern software without leveraging powerful and complex platforms, frameworks, and environments. This is what makes software estimation so hard--these areas outside our code are so unpredictable.
This is why I'm a big fan of the XP style estimation that uses a "load factor" and "velocity" in estimation. These techniques pragmatically adjust for the uncertainty of the factors surrounding your code.
posted by Steve at 6:38 AM
0 comments
