8 ms·

The reason construction workers stand around is because construction is a job-shop scheduling problem. [1] Hence, the optimum schedule is NP-Hard. The simples

• eru 4y ago
  NP-hard problems are solved in practice all the time. The average instance of most NP-hard problems in pretty tractable. However, you are right that if you can get a bit of slack, you can get much more robustness and simplicity. But that observation about slack giving you robustness against perturbations applies even in scheduling (or flow) problems that we can solve in P. (To be fair to your position: the situation in continuous problems is not quite as bad as in discrete problems. I think the stiffness of some underlying matrix might give you an idea of how bad it is in the continuous problem (for some formulations where that makes sense).) https://en.wikipedia.org/wiki/Stiffness_matrix https://en.wikipedia.org/wiki/Stiffness_matrix
  • deleted 4y ago
    [deleted]
  • blt 4y ago
    > The average instance of most NP-hard problems [is] pretty tractable. I don't think the "average" and "most" in this claim make sense. If we could solve NP-complete problems efficiently, we would suddenly want to solve a lot of NP-complete problem instances that we currently do not even attempt.
    • deanCommie 4y ago
      The "prototypical" NP-complete problem - the travelling salesman problem - is "solved" every time you punch in navigation directions in Google Maps.
      • imtringued 4y ago
        Google Maps is breadth first search at worst...
      • NineStarPoint 4y ago
        Google Maps doesn’t need to solve the traveling salesman problem (shortest route between all nodes in a network). To find a route between two points on a graph is just a shortest path problem, solvable by Dijkstra's algorithm and very much in P. (They almost certainly use heuristic algorithms that are more efficient than Disjkstra’s of course, since the size of the graph of all roads is such that a V^2 algorithm is still fairly expensive to run)
        • eru 4y ago
          > Google Maps doesn’t need to solve the traveling salesman problem (shortest route between all nodes in a network). To be more precise, the traveling saleman problem asks for the shortest tour that visits all nodes in a directed, weighted graph. That's a general graph. If you do this on a map, your travel times have a lot of structure already. See https://en.wikipedia.org/wiki/Travelling_salesman_problem#Special_cases https://en.wikipedia.org/wiki/Travelling_salesman_problem#Sp... especially 'Metric' and 'Euclidean'. And, of course, when asked for directions Google Maps gives you just the shortest path between two nodes; or perhaps the shortest path that visits a given sequence of nodes in a fixed order. Google Maps doesn't (yet?) re-shuffle your stops for you. If it did that in general, it would indeed have to solve something at least as hard as the (metric) TSP. (Of course, they could also only support that feature for eg up to five stops. That would be comfortably in P.)
        • boloust 4y ago
          > They almost certainly use heuristic algorithms that are more efficient than Disjkstra’s of course There are techniques like contraction hierarchies[1] that can efficiently compute exact shortest paths on extremely large road network graphs. [1]: https://en.m.wikipedia.org/wiki/Contraction_hierarchies https://en.m.wikipedia.org/wiki/Contraction_hierarchies
• Jensson 4y ago
  • burnished 4y ago
    Think you might be overestimating the average intelligence of engineers and doctors and underestimating the average intelligence of people in the trades if you think there is a (new, novel, exceptional) brain drain going on.
  • lelanthran 4y ago
    You wouldn't have this opinion if you ever tried to build something. These people solve problems all the time. Maybe not math problems, but hard problems nonetheless. Reality has a surprising amount of detail - http://johnsalvatier.org/blog/2017/reality-has-a-surprising-amount-of-detail http://johnsalvatier.org/blog/2017/reality-has-a-surprising-... I build stuff. There's always problems that need to get solved that you haven't anticipated.
    • Jensson 4y ago
      I have been in the military, I know very well how different skills correlate with intelligence since the military relies heavily on that. Removing the top 50% would have a huge effect, and that is exactly what we did in manual labour.
      • lelanthran 4y ago
        I am not claiming that it does not have an effect, I am contending that this assertion: > But today we have ensured that basically no smart people are left is wrong.
        • Jensson 4y ago
          • uoaei 4y ago
• kqr 4y ago
  I wish we would do this with software development too. Having programmers work at near 100 % utilisation means even simple things take weeks or months to go from idea through validation into production.
  • LaundroMat 4y ago
    It's a tough read, but you may want to look into "The Principles of Product Development Flow" [1]. [1] https://www.academia.edu/8250071/The_Principles_of_Product_development_flow https://www.academia.edu/8250071/The_Principles_of_Product_d...
    • kqr 4y ago
      I have read it twice! A good grade for any book in my collection.
  • bluGill 4y ago
    Your best programmers should be on your least important problems. That means your second best are on the hard stuff and this grows them. It also means your second most important project isn't bothered by asking your best people for help. It also means if some new project that needs to be done now comes up your best people are free to do them. This comes from principals of project development flow mentioned below. I strongly recommend the book.
• LaundroMat 4y ago
  If resources are utilized a 100%, the system will run slower than when there's some slack built in. "The Goal" [1] does a good effort of explaining the theory of constraints. [1] https://en.m.wikipedia.org/wiki/The_Goal_(novel) https://en.m.wikipedia.org/wiki/The_Goal_(novel)
  • kqr 4y ago
    My main gripe with Goldratt's ideas is that they are based on the hypothesis that globally analysing a system's averages gives information about bottlenecks and constraints that can be usel to control ingress. It's true for simple systems, and for complex ones better than nothing, of course, but as anyone who has ever run a large system has experienced, the global bottlenecks and the actual, dynamic behaviour of the system at a local level can be quite different. Both demand and capacity can fluctuate unpredictably as people get sick, machines break down, large orders come in, bugs are found, requirements change, and so on. Any optimisation needs to react dynamically to these changing conditions, and changes need to happen locally first and then spread upstream, rather than upstream being globally controlled by the current bottleneck. If you react to bottlenecks only at ingress, you will have large batches traveling through the system only to pile up at the bottleneck anyway, because by the time you choke ingress, large batches that were let through before the bottleneck changed will be making their way through the system unrestricted anyway. Similarly, when a bottleneck goes away, it will take longer for the system to recover if your only control point is globally at ingress. There's a great example of this which I've forgotten where I found it -- could be in the Reinertsen book referenced elsewhere in this discussion. But basically WIP constraints as backpressure outperform global constraint analysis even in quite trivial situations, simply because it adapts more dynamically to the local conditions of the bottleneck and it's surroundings.
• 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.
• just_boost_it 4y ago
  Well, having worked many years in construction as an engineer, I'd say the author has it about right. If you're doing something visible like installing a pipeline in a road, you might have a couple of engineers inspecting the work, someone reviewing how the contractor is assembling the pipe and someone reviewing the safety of the trench and the backfill of the hole (which are all different specialties) and a surveyor. They're probably only on site for a few hours a week, but when they're there, they're probably standing near the work all together talking to the foreman and project manager to make sure everything is being done correctly. The actual labor on a worksite is also a bit stop start. Doing that same work, say backfilling the hole after installing the pipe, the excavator will spend a few minutes filling the hole, then the laborer will climb in to compact it. The poor guy might have 10 minutes break before climbing into a hole to push a compactor around for 15 minutes and then climb back out again. That's hard work. Construction runs pretty tight, having been optimized by market forces over decades. People here complain about estimates, but imagine if you had to bid on every sprint you did, and you couldn't go above your estimate. That's what construction is like. Like the author said, it just looks like construction workers are hanging around because they have to work out in the open, and because people driving by don't know what they're doing, they assume that they're just hanging around.
  • engineer_22 4y ago
    What do you do now? Are you in tech?
    • just_boost_it 4y ago
      I drifted into data science, based on what I used to do to estimate projects as it happens. These comments are pretty funny to me. There's clearly a lot of people here who have absolutely no idea what they're talking about! They sound very confident though, which is a bad combination.
      • juancb 4y ago
        That's hacker news in a nutshell. I come for the link aggregation and stay for the comment sections, it feels like watching a train wreck but it's hard to stop. There are of course diamonds in the rough, comments from experts that are always informative yet humble. Comments like your comment above about your experience as an on-site engineer. Thank you for the insight.
• eternityforest 4y ago
  It would be nice if more things prioritized safety, consistency, and predictability over maximum output. So many things seem to have very little tolerance built in. I suppose some things are limiting factors for things we really want done, but a lot of stuff is already producing more than is needed, and the solution is usually to try to create more demand instead of to enable more slack or to do something else.
• goodpoint 4y ago
  > the optimum schedule is NP-Hard This is not important. The tricky part is that the plan changes constantly.
• jaredhallen 4y ago
  Another reason that someone might appear to be "just standing around" is that they're acting as the spotter for the operator. This is a pretty critical role. There are many things buried in most places, both documented and not. When you're going to dig a hole, at least in the US (and I'm sure other places have similar processes) you're supposed to notify mark the site in advance, and any owners of buried "things" are supposed to come out and mark them before you start digging. Now whether these thing (pipes, cables, etc.) are marked or not, someone needs to be keeping an eye on the hole. The operator typically doesn't have great visibility into the hole, and it's the spotter's job to keep a close watch on what's going on. If the spotter sees anything (sand, caution tape, PVC, etc.) they'll communicate with the operator using hand signals to provide increased precision of operation for delicate work, or frequently send the machine out and hand dig over/around whatever may be in there. Until then, the spotter may just be "standing around"
• _ph_ 4y ago
  I agree it is quite likely also a scheduling challenge. But it doesn't matter how difficult it is to compute, my take is, that there is so much variation in the intermediate steps which have a mutual dependency, that an elaborate schedule wouldn't last for long. Like a truck with sand arriving a few minutes early or late to the site. So the construction workers will dynamically have to deal with the situation. And at times step aside and wait for that truck with the sand dump it into the pit they are working in. And of course, beyond what was said about the workers needs for breaks, it might be most efficient to have reasonably large groups of workers which are needed to work together to perform a task efficiently and then that group having short breaks between the tasks instead of trying to have schemes how to increase the utilization per worker.