posted by
bugshaw at 10:13am on 28/01/2012
via someone on Twitter
And once you get to the end, you have to set off on another walk straight away, but in a shorter time than the original estimate as you will have learnt so much from the first!
And once you get to the end, you have to set off on another walk straight away, but in a shorter time than the original estimate as you will have learnt so much from the first!
(no subject)
(no subject)
So how do you learn the terrain? Mostly by traversing it, and getting a feel for how hard it really is. But when you're estimating software development, it's always for a new route, because you've already written the code for the routes you've done. Except you didn't do it perfectly; this is where the analogy breaks down, because there are always bugs in the code you've already created.
Fixing those is maintenance, rather than development. The trick is to make things better as you re-work the routes, building chunks of paved road to fix bugs, rather than just chipping a step into a rock that's precariously balanced in position. To be able to do that, you need maintenance to be an accepted part of the way the business works, and a worthwhile activity, rather than "something that shouldn't be needed", to be bodged hastily. Making that happen is a problem in structuring the business, not a problem with estimating.
(no subject)
(no subject)
(no subject)
(no subject)
On a recent project, the actual thing requested took me less than an hour to run, but it took three sixteen-hour days of preparation (plus a 20-hour "overnight" unattended run for the software to crank through about 20 million combinations of things to find the 60,000 or so combinations that I needed) to get it set up. My managers see the run time of the final product but don't understand the grinding tedium of the set-up.
(no subject)
(no subject)