Hacker News Reader

Comment by brudgers | Hacker News Reader

The reason construction workers stand around is because construction is a job-shop scheduling problem. [1]

Hence, the optimum schedule is NP-Hard.

The simplest solution to job-shop scheduling is to have slack in the system.

See https://www.johndcook.com/blog/2008/10/21/what-happens-when-...

[1] The contractor has other commitments. Each subcontractor has other commitments. Each material supplier has other commitments. It's true all the way down to the turtles being dug out of the ground. Having people waiting around for work to do, means that work can be done when it can be done. If the people aren't there waiting around, they are off at another site doing something that can be done for a few hours/days/weeks/months.

View on HN

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.

What do you do now? Are you in tech?

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.

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.

When I used to manage shipyard jobs in the oil business, I did a lot of walking or taking a boat from location to location, waiting for a delivery, trying to get a supplier or purchasing on the phone, etc. And there would be crane operators waiting for something to lift. Or a crew waiting on the crane operators to finish so they could shut down some system. Etc. Etc.

In general, my experience was that jobs took about twice as long as it seemed they should ideally take if you "sharpened your pencils" on the estimates. And that assumed no critical dependency like the delivery of critical equipment slipped out or some complicated refurb (like the subsea blowout preventer equipment) didn't take a lot longer than expected.

The classic: "This will take 15 minutes to do, and a couple of hours to validate. I better say two days"

Well, software is knowledge work and it's in big part creative. I am not sure that construction - where people are trained to do one thing in only a few certain ways - is that similar.

I mean, surely there are "oh crap" moments when something not foreseen needs to be addressed, but I don't assume each construction project is a product of spontaneous creativity and improvisation?

I don't believe anyone has ever even made a successful brick-laying robot, and all that needs to do is lay bricks in a straight line. Perhaps the work is more creative/problem solving than you believe.

Laying bricks involves more than putting bricks in a straight line, thats why all the brick laying automation has failed. You know that im sure.

I do know that, but I also know that not every brick job is like trying to build the dome on the Florence Cathedral - it's much more like playing with legos. My point is that perhaps people shouldn't dismiss jobs as trivial. Playing Chess is trivial to a computer now, but laying bricks seems near impossible.

It has not been my experience that for at least 95% of developers their needing to exhibit "spontaneous creativity and improvisation" to a degree greater than what a contractor might do while planning how to run a water line, is a good sign. As in construction or home repair or whatever, it's more likely that it means the person doesn't know the right way to do it.

The fact that we often have to do semi-creative things is more a sign that our industry is immature and shitty, than that the work is inherently much more creative than construction work. We keep trying to make spherical houses even though it'd be a hell of a lot cheaper, faster, and in many ways better, to just make ordinary ones. Then we pat ourselves on the back when we "creatively" figure out how to fit parts and furniture designed for normal-ass buildings into the curved-walled rooms of our spherical ones. Meanwhile the customer just wanted a fucking house and didn't care what shape it was.

100% agreed with this. And you're not even talking about all the resume-and-trend-based software development that goes on.

I met a team that had put months into building a simple job queue. They had a combination of a zookeeper and kafka cluster, an nginx instance, an API process to receive the inbound HTTP put/get, a database writer reading the kafka topic, a database, etc. It was crazy. The lead just had no idea how to build something simple.

I've seen tons of stuff like this. It is not unusual at all and really is about how immature the industry is.

> 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.

TFA elaborates on this:

> Bidding on contracts is a tough way to win work, by the way. Imagine if on January 1st, your employer gave you a list of all the tasks that needed to be complete by the end of the year, and you had to guess how many hours it would take. And, if you guessed a higher number than your coworker, you got fired. And if you guessed lower than the actual number of hours it took, too bad, you only got paid for the hours you guessed. It might incentivize you to look for innovative ways to get your job done more efficiently, but (admittedly) it might also encourage you to cut corners and ignore opportunities to add value where it’s not explicitly required.

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.

Sounds like software estimation

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.

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.

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

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

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.

This just isn't true at all. Digging holes comes with plenty of fun surprises, even for someone acquainted with the qualities of the local ground. For example, in an area I worked, while doing a routine dig we uncovered a boulder the size of a Mini Cooper just below the ground surface.

I seriously don't know why people make up statements with such confidence.

Totally concur with you. It's likely the OP has never fldug a hole or have one dug. Adjacent backyards can be vastly different.

My experience in southern Indiana was that you could confidently dig a good sized hole almost anywhere with little trouble.

My experience in upstate New York is that if you can get a rock to wiggle, you can eventually dig it out. I am always surprised when wait for a cool day with a couple of hours free and then end up hitting nothing and finishing my fence post in five or ten minutes; I've spent six or eight hours digging out enough of a boulder to wrap a chain around to plant a tree.

> 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.

Of course. Because with software both halves of the estimate are hard. A construction worker knows how much time a task normally takes (base estimate), and then estimates factoring in the likelihood of the unforeseen slowing things down (adjusted estimate).

A software engineer doesn't know how long a task normally takes, as software pretty much never gets written twice the same way, so the base estimate might be wildly off - far more than any adjustment could account for. I would adjust for this when asked for high level estimates by giving my best guess and then saying that it's ±50%.

>A software engineer doesn't know how long a task normally takes, as software pretty much never gets written twice the same way

Unless you are making cookie-cutter buildings with the exact same design, the same can be said about construction.

It’s interesting talking to other engineering domains when they don’t understand why it takes so long because “it’s just software” and assumes cutting and pasting from similar problems is all that is necessary. And here we are taking the same stance.

Most buildings are close enough to cookie cutter. I used to work for a builder, he could look at a brand new house print and estimate how much it would cost to build the house within a thousand dollars. You can count the walls, stairs, and a few other features and know what it will cost because those are cookie cutter. Sure the arrangement is different, but that doesn't actually cost anything. So long it is a "stick framed single family house" it is easy to estimate because they are all cookie cutter. Change any of that and you need someone else to estimate as there are different rules for each change. Most of the changes you can make have someone who has experience and can accurately estimate it.

Or in programming terms, I can estimate how long "hello world" well take me to write. My estimate won't change if you tell me to write in it in German, so long as you give me the German translation of hello world. You can substitute any of the thousands of other languages in the world, it won't change the estimate. Of course if you tell me instead of a programming language I know I need to write it in one that I don't that will change the estimate.

This is true, but mainly because you’ve constrained both problems to a well-defined domain. Stick-built single family residential construction is nothing like building a hospital or bridge any more than “hello world” is like a business CRUD app or avionics software.

Almost all construction projects are houses, whereas no software projects are hello world.

Ok, then replace “hello world” with a website.

Would you hire someone to write avionics software because they only have web experience? They’re plenty of people who group them together because they’re both “just software” but it really just shows their ignorance rather than their understanding of the domain

That doesn't matter to this. The point is that neither task is particularly estimable due to the amount of discovery required, rather than due to the difficulty of the task.

That's a better way of putting my point, thank you. I wasn't necessarily meaning to compare the difficulty of the tasks, but rather the dissimilarity of them which leads to additional discovery effort. But on retrospect, I can see why it would come across as a comparison of difficulty.

One part that isn't mentioned that I think would apply to both construction and software is that, in many cases, estimates are backed into based on budget/time constraints involved.

In my current job, aside from tasks that are small enough (less than a day), most estimates are closer to the minimum potential time to build a feature rather than an honest estimate that accounts for the risks involved.

>anything other than "pretty much exactly as expected" is vanishingly tiny.

Anyone who has ever worked construction on a historic site (even with ‘good’ as-built drawings) can give you plenty of examples of this going wrong whether it’s running into abandoned/moved utilities, unknown geology (increasingly common there deeper you go), or a host of other examples with anything more complicated that fence post digging.

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.

> 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.

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.

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.

The problem gets worse as buildings get bigger, with more systems. A lot of larger projects use 3D renderings now to limit the number of clashes.

IDK, this sounds like a solution looking for a problem. Whether the 3d renderings will become regular tools on-site, or not, IDK, IANAn engineer. However, I have never seen 3d models utilized beyond design, the conference room or as an on-site curiosity... mostly retail big-box & small manu, and the models I have seen are coarse and often omit critical minutiae. Blueprints have been, and should always be, readily available to provide exacting details to the experienced professional(not laymen) before & during the project, already. Lots of new ideas come & go, but the application of standard practices scales up quite well in commercial & industrial applications, more so than res, as coded requirements are scrutinized by more agents and are less likely to be curtailed in the name of ease, cost cutting, aesthetics or any other gains an inexperienced actor may wish for.

TLDR: I know 3D Modelling is very useful & meaningful for design & planning. On the site, however, there are already tested tools & standards that scale quite well.

Design blueprints do not have those types of exacting details. They try, but they’re almost always needed to be modified. That’s why, even after the design phase, they’re required to deliver “as-built” blueprints.

3D renderings are definitely becoming more common, but it seems like they’re often used only when in the customer defined SoW. Similar to energy modeling in my experience.

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.

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.

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.

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

> 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.

The "prototypical" NP-complete problem - the travelling salesman problem - is "solved" every time you punch in navigation directions in Google Maps.

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)

> 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#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.)

> 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

Aren't those two different problems?

I was under the impression that Travelling Salesman was about efficiently visiting multiple points in any order, where as navigation directions are ordered point-to-point, even if you add multiple waypoints.

As such Travelling Salesman would be much, much more complex.

I'm probably way out on current best solutions[1] but you could do one with Djikstra's Algorithm or A* but the other would require something probabilistic like Simulated Annealing.

1. Sorry, I'm almost certain that these are not optimal algorithms but I'm just using them as illustration for "small" graphs. I'd be very happy to be enlightened on what's more current.

If you want an exact solution, and are willing to wait for it, you can use an integer linear programming solver to work on your Traveling Salesman Problem for you.

If you abort them early, these solvers can give you an approximate solution and *crucially* also a guarantee how far away they are from the optimal solution. Eg at most 3.7% longer than the optimal solution.

Relating to the article on construction, I think this may be an instance where the theory breaks down in practice. Construction jobs aren’t just optimal linear programming because the order often impacts both the costs and duration of subsequent work, making much of it nonlinear.

Linear integer programming can model these kinds of dependencies.

Can you elaborate?

My understanding is they can in an iterative fashion, but the dependencies I’m talking about are not constraints but nonlinear dependencies between decision variables.

As an example, the decision variables may be integers denoting schedule blocks, but the cost is a nonlinear function of time and the other variables. Meaning each time block can be solved with linear programming iteratively, but to solve across all time blocks requires nonlinear optimization

The general answer is that linear integer programming is NP-complete.

The more specific answer is that you can abuse integer variables to do Boolean logic and then eg model piece-wise linear functions relatively easily.

In practice, this abuse might or might not be very performant, it depends on exactly what you are doing and what your solving is doing. It might be fine, or you might be better off with quadratic or complex programming solvers.

If you have a more specific example, I can try to model it.

Say we have some equipment condition estimated by time variant non-linear function like the Weibull reliability function. [1]

Say the cost of repair is based on a nonlinear relationship between between the equipment replacement cost and current condition. Something like

cost = replace_cost * [(100-current_condition)/(100 - failing_condition)]^2

After repair, the condition increases to some assumed value (say, 95). The overall facility condition is the cost-weighted average of the constituent equipment conditions at any point in time.

facility_cond = sum(equip_cond * equip_cost)/sum(equip_cost)

I want to plan repairs over some time period (say, 10 years) to optimize facility condition within some budget. Can I do this with linear programming?

I can set it up as a linear problem for a single snapshot in time, but haven't thought of a way to efficiently do it as a linear program concurrently across multiple time steps.

[1] https://weibull.com/hotwire/issue7/relbasics7.htm

That’s sounds like a slightly different problem than scheduling operations to carry some complex construction activity, which I think is what is being discussed.

I believe John Sterman used System Dynamics to model maintenance schedules in oil refineries. I’m an amateur at this but that sounds like a better fit to model what you’ve proposed.

Nonlinear programming has been used in similar construction problems, like maritime platforms. They usually optimize for something like availability. My issue is that there’re seems too be too much variance in the assumptions (like repair time or inspection duration) to make them practical.

You _can_ do this as a mixed integer linear program. Whether it's a good idea, is another question.

How would one go about setting that up? It’s been done on a per year basis, but every approach that looks at multiple years seems to require non-linear optimization

You can implement piecewise-linear functions with mixed integer linear programming. (And, of course: piecewise-linear != linear.)

See eg https://web.mit.edu/15.053/www/AMP-Chapter-09.pdf for some examples of simulating non-linear constraints in integer programming.

Oh that reminds me of something I worked on from long ago.

Not sure I'd use LP for Travelling Salesman[1] but I think it can be applied to production planning for scheduling in factories. That at least seems similar to what these construction workers are doing.

I think I recall that a floating point linear program will solve much faster than an integer one, at least with Simplex algorithm which is the only one I've ever really used.

I'm pretty sure it's possible to set up operation scheduling problems so that the decision variables become either 1.0 or 0.

i.e.

  1.0: do this operation at this preset time
  - or -
  0: don't do it.

Does that sound about right?

It was a long time ago that I did any LP though and I'm very rusty, so many pinches of salt recommended to be taken with this comment. :)

1. It'll work for Travelling Salesman but I suspect it will probably be too slow for anything not trivial.

You can use integer programming for the traveling salesman. The typical approach that I heard about goes as follows:

You model your map as a network flow graph. Ie each node has to have one salesman arrive and one salesman leave. Conceptually, that's half the work done.

If you solve this and get a single tour, it's guaranteed to be optimal.

If you solve this, and get multiple disconnected tours, you have a problem.

To fix this, for each way to split the graph in twain, you add a constraint that says that the tour has to go through that split at least once. (So you can't have independent tours.) That's called the (no-) subtour constraint.

In principle, that's enough to solve the problem.

In practice, there's an exponential number of inequalities for your subtour constraints. So what you do is add them one by one, as required: you solve your current problem, check the solution, then add violated subtour constraints, and repeat.

That's the most basic way to model the traveling salesman in linear programming. There are much better ways, I think.

Your recollection about scheduling problems is roughly correct.

Google Maps is breadth first search at worst...

Very often it's enough to obtain an exact solution. 95% on the way to the optimal solution is usually good enough.

Approximate solutions are much easier to reach. Methods like simulated annealing can even approach them stochastically.

s/an exact/inexact/ but cannot edit already.

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)

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.

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.

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_d...

I have read it twice! A good grade for any book in my collection.

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.

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"

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.

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.

> the optimum schedule is NP-Hard

This is not important. The tricky part is that the plan changes constantly.

Reply on news.ycombinator.com