bugshaw: (Default)
Add MemoryShare This Entry
posted by [personal profile] 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!
There are 8 comments on this entry. (Reply.)
dalmeny: (Default)
posted by [personal profile] dalmeny at 10:51am on 28/01/2012
It's not just software projects. Our env sci projects follow this too.
 
posted by [identity profile] history-monk.livejournal.com at 11:21am on 28/01/2012
The long walk in the link is quite a decent analogy. The biggest problem with it is that the terrain is very much harder, and the real route longer, than the original estimate was based on. If the journey was on straight roads, the estimate would have been reasonably valid.

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.
 
posted by [identity profile] bibliogirl.livejournal.com at 11:48am on 28/01/2012
Brilliant.
 
posted by [identity profile] coth.livejournal.com at 12:34pm on 28/01/2012
Enjoyed that, and passed it on. Thanks.
andrewducker: (Default)
posted by [personal profile] andrewducker at 12:55pm on 28/01/2012
I like that a lot!
 
posted by [identity profile] kevin-standlee.livejournal.com at 04:34pm on 28/01/2012
Oh, yeah, so true. And if I triple or quadruple my time estimates to try and give people a more realistic projection, they accuse me of padding things on the grounds that it can't possibly take that much time.

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.
 
posted by [identity profile] voidampersand.livejournal.com at 06:39pm on 28/01/2012
And then there is the guy who suggested a better analogy would be a mapping project, and that a more clever pair of mappers would decide to hire a boat. Right. I guess he doesn't know that the California coast is a lee shore with very few harbors. Lots of shipwrecks.
 
posted by [identity profile] unwholesome-fen.livejournal.com at 07:37am on 29/01/2012
Not just software - many major civil engineering projects in the last few decades have been late and over budget (e.g. the Humber Bridge, Channel Tunnel etc.) In some cases this is indeed because new ground is being covered, but in others I suspect that cannot be the whole story, so I think it's a lot more complicated than the analogy given there implies. The Cambridge Guided Bus looks like it ought to be an object lesson in how not to run a project, although we don't have access to all the details at the moment as everyone is still suing each other.

September

SunMonTueWedThuFriSat
  1
 
2
 
3
 
4
 
5
 
6
 
7
 
8
 
9
 
10
 
11
 
12
 
13
 
14
 
15
 
16
 
17
 
18
 
19
 
20
 
21 22
 
23
 
24
 
25
 
26
 
27
 
28
 
29
 
30