3 ms·

I think this is due to people adhering to a bad implicit analogy: "Estimating software construction projects must be like estimating other types of construction

I think this is due to people adhering to a bad implicit analogy: "Estimating software construction projects must be like estimating other types of construction projects, e.g. bridges or cars." The problem is that most software projects don't have a myriad near-identical existing solutions from which to source a project's duration. We aren't making a building with the exact same floor plan, using the exact same crew size with the exact same skills, in the exact same regions, using...You get the point. It's just a bad comparison. Most software projects are more like R&D than construction. For the adventurous analogy, software is like hiking an unknown trail. You might generally know where you're going, but you can't foresee the river, detours, and feral hogs you'll have to battle to reach the end. You simply can't estimate software the way you can more tangible products. You can do Scrum planning poker and pretend your're not playing Numberwang, if that makes you feel more in control.

wvenable 7y ago
Construction projects have detailed blueprints used to construct the estimate. Developing the blueprints is much more like developing software and probably has similar issues with estimating the time it takes, effort, etc. But nobody ever compares that. There is no construction phase in software (except compiling); the entire project is the planning stage.
- meheleventyone 7y ago
  I also think this comparison is made by people that have never been involved in construction projects. Even something reasonably small in scope like rebuilding a house is still an exploratory process. Redoing ours we found the frame was no good and had to go back to get planning permission to build a new top structure. Even now we're getting our lower outer wall repaired (basically the only part of the structure that's actually original now) and the initial cleaning showed there was more work involved. So we renegotiated the cost with the builder. Then you look at big civil engineering projects that seem to always be over-time and over-budget. The treatment of estimates in project management for software is way more like the assumption we have an assembly line where even if there are issues these are routine enough that they can be padded in. The problem is that software is an exploratory process and not an assembly line. It's even worse the more creative the project is. I've worked in games for fifteen years and I don't think it's possible to estimate when a game will be 'good'. Making one is a process that requires a lot of feedback, iteration and scope management. It's part of why we see so much reflexive crunch as the reality of making a game hits poor project management strategy based on this assembly line thinking. The words Gantt chart make me shudder.
- TeMPOraL 7y ago
  That's why I think a more correct analogy is that programming is making the blueprints; the blueprint is the source code, and construction is what compilers do.
chrisweekly 7y ago
I'm reminded of the book "The Hard Thing About Hard Things"... and even more, of this also-classic post: https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=3Gx https://www.quora.com/Why-are-software-development-task-esti...
verinus 7y ago
I even think that the construction analogy does not hold merrit: I have never heard of a really big project that was a) on time b) on budget. I think those projects might be best compared to the software projects we think of here...

wvenable 7y ago

Construction projects have detailed blueprints used to construct the estimate. Developing the blueprints is much more like developing software and probably has similar issues with estimating the time it takes, effort, etc. But nobody ever compares that. There is no construction phase in software (except compiling); the entire project is the planning stage.

meheleventyone 7y ago
I also think this comparison is made by people that have never been involved in construction projects. Even something reasonably small in scope like rebuilding a house is still an exploratory process. Redoing ours we found the frame was no good and had to go back to get planning permission to build a new top structure. Even now we're getting our lower outer wall repaired (basically the only part of the structure that's actually original now) and the initial cleaning showed there was more work involved. So we renegotiated the cost with the builder. Then you look at big civil engineering projects that seem to always be over-time and over-budget. The treatment of estimates in project management for software is way more like the assumption we have an assembly line where even if there are issues these are routine enough that they can be padded in. The problem is that software is an exploratory process and not an assembly line. It's even worse the more creative the project is. I've worked in games for fifteen years and I don't think it's possible to estimate when a game will be 'good'. Making one is a process that requires a lot of feedback, iteration and scope management. It's part of why we see so much reflexive crunch as the reality of making a game hits poor project management strategy based on this assembly line thinking. The words Gantt chart make me shudder.
TeMPOraL 7y ago
That's why I think a more correct analogy is that programming is making the blueprints; the blueprint is the source code, and construction is what compilers do.

chrisweekly 7y ago

I'm reminded of the book "The Hard Thing About Hard Things"... and even more, of this also-classic post: https://www.quora.com/Why-are-software-development-task-estimations-regularly-off-by-a-factor-of-2-3/answer/Michael-Wolfe?srid=3Gx https://www.quora.com/Why-are-software-development-task-esti...

verinus 7y ago

I even think that the construction analogy does not hold merrit: I have never heard of a really big project that was a) on time b) on budget. I think those projects might be best compared to the software projects we think of here...