6 ms·

It is weird how people look at this as a NP-hard scheduling problem. That doesn't touch the fundamental issue of uncertainty. Digging a hole can take between

by jhncls 4y ago

It is weird how people look at this as a NP-hard scheduling problem. That doesn't touch the fundamental issue of uncertainty. Digging a hole can take between 5 minutes and eternity, depending on whether tree roots, old cables, old reinforced concrete, possible archeological finds, ... are encountered. A delivery of new material can be held up by traffic, by unforeseen stock issues, ... . The time concrete needs to dry depends on the weather. Things would be easy if it just were a NP-hard scheduling problem that only needs to get at 0.1% of the optimal solution.

thewarrior 4y ago
Sounds like software estimation
- sdiupIGPWEfh 4y ago
  We'll just call what the construction workers are already doing a "stand-up" and have them estimate work while they're standing there. Then we'll ask them to report on progress every morning, while holding them to the original estimate. All we need to do is write a manifesto, design a bunch of indecipherable workflow charts, name our system after some sports term or silly acronym, sell ourselves out as agile construction coaches, and watch the sweet consulting money roll in.
throwaway0a5e 4y ago
When people who have dug holes in the local area before are doing the digging the frequency with which digging a hole goes anything other than "pretty much exactly as expected" is vanishingly tiny. This applies to damn near every other task. Just because some techies don't know to look at the forecast and budget extra time for unloading trailers of material in inclement weather because this particular job site happens to be a mud pit doesn't mean that the people who's job it is to schedule those things don't know to do so. Edit: I chose my words for a reason. Some of you people would do well to understand that not going smoothly is not the same as not going as expected. The people who dig holes for a living both know how long the average hole takes, how long the median is and how frequently "well shit we hit bedrock where we didn't expect it, now we gotta do X, Y and Z" type outliers occur.
- cnity 4y ago
  Not going to comment on hole digging because I am a "techie", but going to use your comment as an accretion point for a thought I've had for a while. In software, until we acknowledge the way in which the coastline paradox[0] pertains to task estimation, we're going to continue spinning our wheels saying things like "people have worked on this area before, the estimation should be easy" and keep getting really inaccurate estimates, and the engineers will continue to be blamed. The fractal nature of task complexity suggests that _complexity can only go up_ (more or less). This is why estimates always seem to be wrong in the direction of "too short". Your comment about hole digging is to assert that the fractal dimension[0 again] is 1 for that particular problem. Great! Estimation is easy in those cases. My proposal: identify the particular fractal dimension of your particular problem domain (by observing past estimations compared with their reality) and use it as a multiplicative factor in estimates. Unfortunately, most managers call this process "sandbagging" and my proposal is considered too "mathematically complex". I believe that until this is accepted and resolved, we will continue to have unrealistic estimates. [0]: https://en.wikipedia.org/wiki/Coastline_paradox https://en.wikipedia.org/wiki/Coastline_paradox
  - bumby 4y ago
    In big projects, there are also incentives to underbid up-front. It’s common for project managers to low-ball to get their projected funded and then use the sunk-cost fallacy to get it funded to the appropriate level. This unfortunately leaves people who actively try to give accurate estimates with unfunded projects
    - CrimpCity 4y ago
      Yup! The change order strategy or nickel and dime strategy tho autocorrect suggested “buckle and dime” and that would also work. Unfortunately as much as engineers and owners reps complain about this way of doing business it’s quite accepted since people generally want to keep their reputations. No one wants to be known as “difficult to work with”. So only very excessive transgressions get punished.
- SantalBlush 4y ago
bumby 4y ago
It’s not just that, but also because the uncertainty is partly based on the scheduling order. Installing, say, electrical conduit may be much quicker if it’s the first job than if you have to work around recently installed ductwork. This often changes the dynamic of the solution to a nonlinear problem. This isn’t just related to new construction. If you’re trying to minimize life-cycle costs, does it make sense to install solar panels now (and potentially - within some uncertainty - reduce the life of your current roof) or wait and lose the benefit of free electricity? Factoring in volatility of labor and materials increases the uncertainty further, and so on.
- bluGill 4y ago
  > Installing, say, electrical conduit may be much quicker if it’s the first job than if you have to work around recently installed ductwork Note that real contractors have the plumbers come in first because the pipes have to slope downhill. Then the HVAC people because while they can go around obstructions it makes for ugly duct work (which needs to be accounted for in pressure calculations), only after they are done can the electricians come in and they have to work around whatever was done.
  - bumby 4y ago
    That’s why a lot of the discussion about schedule optimization is somewhat flawed. Critical path is often constrained just as you said, they can’t be treated as a bunch of isolated job shops. Also, I think it’s also a bad assumption to assume every construction effort is a greenfield project, just like it would be with software. Even multi-million dollar construction projects often have to work around existing infrastructure.
  - tunap 4y ago
    In a perfect world, perhaps, but that's why mechanical chases are engineered in the blueprints. If an HVAC installer comes in after the plumbing or electrician & pipes or wires are in the 'no-go' zone, guess who gets to re-do their run(s)? It isn't the metal installer. As a former res sparky, I was often the 1st sub in after the framers finished... often enough, before the framers were finished.
roenxi 4y ago
The uncertainty doesn't have to result in people standing around though; that should [0] manifest as periods where the job site is empty because there is a short period of slack in the schedule. And it is easy to over-sell the variance of tasks. These things have regular and predictable times with rare outliers. The challenge of scheduling them is nothing like the impossibility of scheduling a software project accurately. [0] Lots of exceptions, yes. No I don't know anything about construction but I do know quite a bit about scheduling work.
- Retric 4y ago
  The differences in construction are relevant here. Construction work involves people and machinery which can’t easily move between locations the way programmers can hop between tasks. Further there are orders of magnitude cost differences between people and machinery. The guy with a shovel standing next to heavy machinery might not actually do much labor in a given hour, but sending them elsewhere would be a mistake.
  - roenxi 4y ago
    Precisely. You're describing a scenario where the variance of the task time has little to do with why people are standing around. The tasks could have 0 variance and there would still be people standing around. Probably for the same amount of time, in practice. The situation is controlled by the cost of moving equipment around & the order tasks need to be done. The uncertainty would manifest as periods of buffer when equipment isn't bought to site yet/men don't get bought in at all. Obviously sometimes the situation just falls apart, but usually I'd bet the downtime would be planned and predicted.

by jhncls 4y ago

thewarrior 4y ago

Sounds like software estimation

sdiupIGPWEfh 4y ago
We'll just call what the construction workers are already doing a "stand-up" and have them estimate work while they're standing there. Then we'll ask them to report on progress every morning, while holding them to the original estimate. All we need to do is write a manifesto, design a bunch of indecipherable workflow charts, name our system after some sports term or silly acronym, sell ourselves out as agile construction coaches, and watch the sweet consulting money roll in.

throwaway0a5e 4y ago

When people who have dug holes in the local area before are doing the digging the frequency with which digging a hole goes anything other than "pretty much exactly as expected" is vanishingly tiny. This applies to damn near every other task. Just because some techies don't know to look at the forecast and budget extra time for unloading trailers of material in inclement weather because this particular job site happens to be a mud pit doesn't mean that the people who's job it is to schedule those things don't know to do so. Edit: I chose my words for a reason. Some of you people would do well to understand that not going smoothly is not the same as not going as expected. The people who dig holes for a living both know how long the average hole takes, how long the median is and how frequently "well shit we hit bedrock where we didn't expect it, now we gotta do X, Y and Z" type outliers occur.

cnity 4y ago
Not going to comment on hole digging because I am a "techie", but going to use your comment as an accretion point for a thought I've had for a while. In software, until we acknowledge the way in which the coastline paradox[0] pertains to task estimation, we're going to continue spinning our wheels saying things like "people have worked on this area before, the estimation should be easy" and keep getting really inaccurate estimates, and the engineers will continue to be blamed. The fractal nature of task complexity suggests that _complexity can only go up_ (more or less). This is why estimates always seem to be wrong in the direction of "too short". Your comment about hole digging is to assert that the fractal dimension[0 again] is 1 for that particular problem. Great! Estimation is easy in those cases. My proposal: identify the particular fractal dimension of your particular problem domain (by observing past estimations compared with their reality) and use it as a multiplicative factor in estimates. Unfortunately, most managers call this process "sandbagging" and my proposal is considered too "mathematically complex". I believe that until this is accepted and resolved, we will continue to have unrealistic estimates. [0]: https://en.wikipedia.org/wiki/Coastline_paradox https://en.wikipedia.org/wiki/Coastline_paradox
- bumby 4y ago
  In big projects, there are also incentives to underbid up-front. It’s common for project managers to low-ball to get their projected funded and then use the sunk-cost fallacy to get it funded to the appropriate level. This unfortunately leaves people who actively try to give accurate estimates with unfunded projects
  - CrimpCity 4y ago
    Yup! The change order strategy or nickel and dime strategy tho autocorrect suggested “buckle and dime” and that would also work. Unfortunately as much as engineers and owners reps complain about this way of doing business it’s quite accepted since people generally want to keep their reputations. No one wants to be known as “difficult to work with”. So only very excessive transgressions get punished.
SantalBlush 4y ago

bumby 4y ago

It’s not just that, but also because the uncertainty is partly based on the scheduling order. Installing, say, electrical conduit may be much quicker if it’s the first job than if you have to work around recently installed ductwork. This often changes the dynamic of the solution to a nonlinear problem. This isn’t just related to new construction. If you’re trying to minimize life-cycle costs, does it make sense to install solar panels now (and potentially - within some uncertainty - reduce the life of your current roof) or wait and lose the benefit of free electricity? Factoring in volatility of labor and materials increases the uncertainty further, and so on.

bluGill 4y ago
> Installing, say, electrical conduit may be much quicker if it’s the first job than if you have to work around recently installed ductwork Note that real contractors have the plumbers come in first because the pipes have to slope downhill. Then the HVAC people because while they can go around obstructions it makes for ugly duct work (which needs to be accounted for in pressure calculations), only after they are done can the electricians come in and they have to work around whatever was done.
- bumby 4y ago
  That’s why a lot of the discussion about schedule optimization is somewhat flawed. Critical path is often constrained just as you said, they can’t be treated as a bunch of isolated job shops. Also, I think it’s also a bad assumption to assume every construction effort is a greenfield project, just like it would be with software. Even multi-million dollar construction projects often have to work around existing infrastructure.
- tunap 4y ago
  In a perfect world, perhaps, but that's why mechanical chases are engineered in the blueprints. If an HVAC installer comes in after the plumbing or electrician & pipes or wires are in the 'no-go' zone, guess who gets to re-do their run(s)? It isn't the metal installer. As a former res sparky, I was often the 1st sub in after the framers finished... often enough, before the framers were finished.

roenxi 4y ago

The uncertainty doesn't have to result in people standing around though; that should [0] manifest as periods where the job site is empty because there is a short period of slack in the schedule. And it is easy to over-sell the variance of tasks. These things have regular and predictable times with rare outliers. The challenge of scheduling them is nothing like the impossibility of scheduling a software project accurately. [0] Lots of exceptions, yes. No I don't know anything about construction but I do know quite a bit about scheduling work.

Retric 4y ago
The differences in construction are relevant here. Construction work involves people and machinery which can’t easily move between locations the way programmers can hop between tasks. Further there are orders of magnitude cost differences between people and machinery. The guy with a shovel standing next to heavy machinery might not actually do much labor in a given hour, but sending them elsewhere would be a mistake.
- roenxi 4y ago
  Precisely. You're describing a scenario where the variance of the task time has little to do with why people are standing around. The tasks could have 0 variance and there would still be people standing around. Probably for the same amount of time, in practice. The situation is controlled by the cost of moving equipment around & the order tasks need to be done. The uncertainty would manifest as periods of buffer when equipment isn't bought to site yet/men don't get bought in at all. Obviously sometimes the situation just falls apart, but usually I'd bet the downtime would be planned and predicted.