The 4 points in the article are all well detailed/explained, but he has a few parts that are either missing or represent theory much more than practice (on a site titled practical engineering).
>Will you build a bridge that’s inexpensive, but will have to be replaced in 25 years, or will you spend twice the money for more concrete and more steel to make it last for 50?
Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired .
> Most construction projects are bid using a set of drawings and a book of specifications that include all the detail necessary to build them. An engineer, architect, or both has gone to great lengths to draw and specify exactly what a contractor should build, often to the tiniest details about products, testing, and procedures. You can see for yourself; just google your city or state, plus “standard specifications,” and scroll through what you find to get a sense of how detailed contract documents can be. We go to that level of detail in defining the project before construction so that it can be let for bidding with the confidence that an owner will end up with essentially the same product at the end of construction, no matter which contractor wins the job.
This is pure theory/wishful thinking, the regulations/norms/specifications are a needed thing (and a good one), but projects in reality (non-trivial ones) are largely "vague" or however not detailed enough (there are exceptions, of course, but while the project does make an even enough bidding ground it usually fails to properly detail the construction). It is of course a compromise of sort, making a good project would simply cost too much and take too much time.
The assumption here is that all the architects and/or engineers are omniscient, competent, honest and have all the time in the world to think about the project and an unlimited budget.
>But, the lowest bidder model is still used around the world because it generally rewards efficient use of public funds.
No, the lowest bidder model is still used around the world because it is the simplest way to assign a contract without (the public manager) being responsible of the decision to award it to company A instead of company B.
1) the builder changes are accepted at the same cost AND they are actually same or better than project
2) the builder changes are accepted at an extra cost AND they are actually same or better than project AND the construction goes over budget
3) the builder changes are not accepted, the project is (hopefully) executed as designed BUT the builder losing money will not complete it (or not complete it in time) with daily bickering on site AND an endless trail in Courts
No, the plans - generally speaking - are not good enough.
A change order always changes the cost of the work.
“Change order” and “cost of the work” are terms defined in the contact (often by reference) and come with implementation protocols.
Once a person has been around the block a few times, they usually realize that the plans are not the construction, the design brief is not what the owner actually wants, and the contractor doesn’t build everything right.
And the whole thing is about working together to get the building built in a way that favors getting the next project.
>Once a person has been around the block a few times, they usually realize that the plans are not the construction, the design brief is not what the owner actually wants, and the contractor doesn’t build everything right.
> No, the lowest bidder model is still used around the world because it is the simplest way to assign a contract without (the public manager) being responsible of the decision to award it to company A instead of company B.
You've made it sound as if it's about avoiding responsiblity, while the motivating force behind this model is to avoid creating situations which would incentivise corruption. When you take away any decision-making power from the official awarding the bid and he basically just has to follow a pre-written algorithm, he can't be corrupted.
I have made it sound like that because I wanted it to sound exactly like that.
The "official" motivating force is the one you mentioned, but that doesn't mean that it is the actual one, nor that lowest bid is actually the best possible formula[0].
It is the up-to-date "the algorithm made me do it" version of the "officer, the devil made me do it" excuse when (if) the project is delayed or goes over budget, the builders are usually considered the culprits (whether it is actually their fault or not) and they were selected by applying the algorithm (so all is fine).
Consider how you (private person) would normally award the construction of your house, likely you would:
1) find a list of local contractors (mostly from world of mouth)
2) get from 3-5 of them offers
3) compare them, analyze them with your arhitect/engineer, talk with offerers about possible mistakes/inconsistencies
4) finally choose the builder (more often than not you will choose not the lowest bidder but rather the one that overall seems to you more capable/reliable/interested in the work)
With what a (say) local council would probably do to build (still say) a small school:
1) publish a request for bids
2) obtain anything between (say) 10 and 200 offers
3) award the contract to the lowest (and valid according to the algorithm) offer
It is clear that in your private case you have no incentive for corruption, but - in order to avoid the risk of corruption - the council just awarded the contract to a "number".
This "number", more likely than not, is the result of "blind shooting", the builders need a certain number of contracts and they need to make many offers, and have no time to analyze them in detail.
[0] as a matter of fact "pure" lowest bid is relatively rare there are usually a number of corrective items either in the algorithm or in the norms regulating the bid, in some cases they can be effective, in some cases they introduce some perverse incentives to the offerers.
Why wouldn't corrupt people just bid low and give the public manager a bigger kickback? And if the contractor & public manager are both corrupt, wouldn't the job likely be shoddy anyway?
I spoke with a family member at a wedding recently who manages civil engineering projects in his city (he himself is a civil engineer), a regional transportation hub. He said it's all lowest bidder with one exception: a contractor with a history of shoddy work. His reasoning was that he'd really have to justify going with anyone but the lowest bidder. In other words, he'd be responsible for the outcome.
Keep in mind, most of his job is ensuring that the city's spec is followed and if not that contractors fix shoddy work. It's non-trivial, certainly couldn't be replaced by an algorithm and gives him pretty significant skin in the game (if he did his job poorly and let shoddy construction make it through, he'd be out of a job).
>Why wouldn't corrupt people just bid low and give the public manager a bigger kickback?
Well, if the public manager has no powers in the assignment, there is no reason why the builder should "pay" him/her, from this point of view lowest bid is effective as an anti-corruption method.
And by bidding low the builder will have less available money to possibly attempt to bribe anyone.
But then (maybe - just hypothetical) once the lowest bidder is awarded the contract they will find each and every possible way (including bribing) to get more money for the contract, changes, improvements, extensions, etc..
The usual counter-argument is that all builders are the same, so if you award the contract to (say) the 2nd lower bidder, they will make exactly the same, only starting from a higher "base",
There are often very fine lines between "contributing to bankrupcy of builder", "paying a fair price" and "spend too much public money".
>>Will you build a bridge that’s inexpensive, but will have to be replaced in 25 years, or will you spend twice the money for more concrete and more steel to make it last for 50?
> Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired .
Why does that time extension hold for the 50-year bridge but not the 25-year bridge?
It does, but to a different probability of failure. A 25-year bridge extended to 35 years will have a higher probability of failing during that 10 year extension than a 50 year bridge extending life to 60 years.
The most common survivability analysis is a Weibull model which typically has a longer right tail to the failure distribution.
The point I was trying to make[0] is independent from the actual planned duration of the structure[1].
Of course it would apply also to the less lasting one.
In a perfect world, besides ordinary maintenance (which rarely is performed anyway in a timely manner) when a bridge is near to its planned end of life (let's stay on the 50 year duration) it should be inspected and - if it is the case - its life could be extended by - say - 10% or 5 years, BUT there should already be present:
1) the projects and all authorizations for the new bridge
2) a reserve of money ready to be spent on the new bridge
Then (and this is actually an increased cost/waste) these "granted" extensions of life could be repeated a number of times BUT should be "hard-capped" anyway to - say - 30% of the planned duration, in name of more certain safety, it will happen that you will demolish and rebuild a perfectly good bridge, but you will also in many cases prevent a disaster.
What happens in the real world is that once the 50 years have passed, an inspection is made, and it is determined that everything is good enough, let's make another inspection in 5 years time or let's make this minor repair, and let's see what happens in 5 years time, rinse and repeat until the structure has double the planned lifetime and finally something happens (be it a structural failure, an accident, whatever) that forces to close the bridge (or to reduce load on it or in the worst case the bridge collapses) and at this point starts the race to make the project, get the authorizations, gather the money, etc, which adds two or three years to the time needed to have the new bridge built and usable.
If you prefer, the issue I was trying to point out is that usually we need an "unexpected" event to trigger an "emergency response" whilst the bridge nearing its end of life is something known and expected.
[0] which is that once something is built, for some reasons it is often considered (wrongly) to be eternal
[1] which anyway is only a very rough estimate, not an exact number, duration for reinforced concrete or steel bridges depends on so many factors that is impossible to determine accurately a possible "structural" life.
The vast majority of bridges do not fail. Sure a few get in the news because they fail early, and some are sabotaged (earthquake, war, or some other event that cause an early failure), but the vast majority of bridges last until they are intentionally torn down.
Sure they don't, but they also do not last for eternity (without maintenance or repairs).
The theme is more about whether to build "massive" (and expensive) more lasting structures or build more economical but less lasting structures and how to properly evaluate the expected lifetime of these structures.
We know empirically that many (reinforced concrete) structures built 70/80 years ago (some even less than that) start showing a number of issues (that often require "heavy" repairs) besides the few that made it to the news.
We don't have that many examples of earlier constructions of this kind (pre-stressed concrete is relatively recent as a technology), but we do know that in many countries a large number of bridges were built in the '60's and '70's so they are nearing the time they will reach the age we already found to be critical.
Actually no, it isn't working because it cannot possibly work, at least not with decades old structures (that however do not collapse because they were often over-engineered, because after all they weren't built so shoddily and for a thousand other possible reasons).
A bridge inspection more often than not amounts to a visual inspection, to detect cracks, check bearings, but while some elements of the structure are visible (as said bearings and concrete surface) the state of internal cables is hard or impossible to check, though there are some new techniques that look promising (though they are not yet AFAIK properly documented/standardized), as an example, JFYI:
And there is another key point, norms have obviously changed a lot in the several decades since the construction, original calculations and drawings may have been lost, and there is the need to re-do the calculations with the new standards of loads and check whether the current loads/frequency of traffic is compatible with those the original project took into account.
Ok, I see what you mean. To me this sounds like you not taking a simplified example for what it is. In a perfect system all you say can be quantified down into money, and be priced in when comparing 25 and 50 year bridges.
In the real world there are other factors too, like the risk that the nearby city will grow enough that the bridge will need to be expanded after 25 years. The entire second half of the 50 year cost may be wasted in that case, as expanding the bridge may be at least as costly as building it in the first place.
Or in 10 years traffic demand goes down, so that this bridge is no longer needed. Or boat traffic changes, and this bridge is now too low. More waste to tear down the 50 year bridge than the 25 year bridge.
Or if the bridge gets bombed after 25 years. Then too the 50 year bridge is a waste.
> Will you build a bridge that’s inexpensive, but will have to be replaced in 25 years, or will you spend twice the money for more concrete and more steel to make it last for 50?
> > Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired.
Assuming the bridge would actually be replaced at its actual end of life (25/50 years) and assuming a horrible return on spending (double money for only double the life), I'd say the 25 year option would be better in many (not all) cases.
From a cash flow perspective, it'd be helpful for a local government to avoid immediately spending on infrastructure costs that could be delayed for 25 years (when the lower cost bridge would be due to be rebuilt).
From the unknown future perspective, the city/town population could possibly change (bigger/smaller) 25 years into the future.
If the population grows, replacement bridge would need to be bigger and they could use the saved money to build a bigger one. Of course, if the population shrinks, they could spend less on a smaller replacement bridge.
Again, this assumes a poor return on increased spending. Doubling the costs to double the life. If you could double the costs and triple the life or increase the cost by only 50% to double the life, the equation favors going with the longer term bridge.
But the assumption here is that the replacement bridge is built "overnight" or however without altering in any way the normal traffic on and around it, which is very rarely the case, more likely you should expect months or years (of course depending on the size/complexity of the bridge) of limitations/difficulties with the city traffic, noise, dust and all the issues usually connected with construction sites.
This is an indirect (hidden) cost of all kind of infrastructures that the population/users will have to bear.
> >Will you build a bridge that’s inexpensive, but will have to be replaced in 25 years, or will you spend twice the money for more concrete and more steel to make it last for 50?
> Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired .
Was just relating this story to someone else the other day. As a kid, there was a lot of roadworks around us. Due to cold weather and hot summer, roads were constantly developing seams/buckles and potholes. This was often chalked up to 'unions bad - cheap materials - etc'. Newspapers would run 'investigations' every few years, etc.
I think the road folks often did poor jobs of explaining decisions, and maybe it was literally always just "cheapest bid".
But I look back at a road that was bad for years - it was repaved at least 3 x over a 10 year period I remember. THEN... it was expanded from 2 and 3 lane road to 6 lane. The land was there on both sides, and it had been in planning for probably 10+ years. Knowing the road will be torn up less than 10 years in the future, I can understand "just use cheapest patching for now" because it will get thrown away 3 years from now.
However, that was never something that ever seemed to get across in news 'investigations'. Note, I'm going back to the 80s and 90s in my head, and I was younger - there may have been some info I missed, but even as I grew in to an adult... little hard info seemed to make it out to the general public.
[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.
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).)
> 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.
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)
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.)
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.
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.
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.
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.
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.
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
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.
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.
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.
There are many smart people in construction. I went to Cal and know some classmates that went into it as management. There's also tons of people that went to "good" schools and studied construction management and I would put them up against CS majors from "average at best" schools any day.
To say that the average cs grad got straight As in highschool is laughable. I know tons that couldn't even get into Cal or Stanford.
Why do you insist that high school test performance is a valid metric for intelligence? Why do you think the kind of intelligence tested for in high schools is readily transferrable to conclusions about the ability of someone to get their job done?
> How many construction workers do you think got majority A's in high school?
There are many smart people who did not get majority A's in high school. High school performance is not a good metric for problem-solving skills (AKA, general intelligence).
Maybe in your middle class bubble all the smart kids graduate high school with good grades. From meeting people in a variety of walks of life in the USA it seems to me that what actually happens is that your grades are determined by zip code lottery with smart kids in underfunded school districts set up to fail by poor schools.
Half of my high school class dropped out and I got a good view of the average of society in the military, I have seen a ton of people struggle from all walks of life.
Also it is so strange that people here don't think that poor wages has any effect on the quality of workers in construction, even though they believe that to be true basically everywhere else. I strongly believe the reason we see so many problems with construction is simply that the wages today are so skewed and that greatly impacts the availability of talent, since people who can choose to go elsewhere mostly do so today.
Only reason I can think of is that most here assumes construction work is so easy that you don't need to be that smart to do well there. Otherwise I don't understand these comments.
The half-joke/half-truth that "millitary intelligence" is an oxymoron has been widely circulated - heck, there are even Quora layman questions that take it for granted.
And of course all kind of insider jokes about such illogicallity and inefficiency (including long standing acronyms, like S.N.A.F.U), about how high command has little understanding of the situation on the ground in any real scenario, things dressed-up to look good, and so on.
Construction is a very conservative business that innovates slowly. This is partly by design. It carries a lot of risk to human safety and capital that isn’t amenable to the “fail fast” paradigm of SV.
> I strongly believe the reason we see so many problems with construction is simply that the wages today are so skewed and that greatly impacts the availability of talent
I guess that explains why the majority of software is so performant, bug free and a pleasure to use?
Perhaps you’re conflating general labor to construction? Construction involves all kinds, from general labor to skilled trades to project managers to engineers
John needs to watch YouTube to learn how to use a framing square to layout his stair stringers and how to pack wood shavings into a screw hole to reset it.
Believe it or not, there are entire research labs dedicated to just construction optimization. There’s a lot of PhDs actively working on these problems, but I guess they aren’t very smart or they’d be in software :-)
If that was true, wouldn't it mean at least some of those intelligent people were in management of software? Meaning it should always be 1. On time, 2. With all features and 3. Without defects?
Or maybe the people in software aren't very intelligent... Or they are all hard problems.
Just like the article states, there might be something to the slacking construction being so visible leading to the common perception of waste. If SWE “non-productive” time was visibly broadcast to the same degree, there might be more customer outrage regarding the cost of development.
A digression, but is this type of attitude just as prevalent in other domains? Do chemists/pilots/aerospace engineers have the same weird status flex sentiment?
Not at the same level, because in a lot of those fields you have to study quite a bit and the more you study the more you realize how much more there is to learn.
It’s a humbling experience in the natural sciences. You can study chemistry for 4 years as an undergrad, then 4-6 years as a PhD. Then you go to a conference and even in the small room dedicated to your little sub-sub-discipline, someone can get up and talk about something you have never heard of.
The incorrect lesson to take from getting a PhD is that you are really smart and can solve everyone’s problems. The correct lesson is that there are many fields this deep, and you can’t just read a bit and think you are knowledgeable about the whole field.
That's assuming that your society does a good job of funnelling smart people into higher education. Most societies I've visited don't do that good, the USA does a worse job than most.
There are plenty of smart people on construction sites. I've met many, on site. Many just didn't get to complete high school because of the school system of their country, because family issues etc. Many of the skilled workers actually enjoy what they do and regard sitting in front of a screen all day as a waste of a life.
Anyone managing a crew or subcontracting _can't_ be dumb - it's a very challenging role
If there are people standing around on a building site it is mostly not because of blockers or scheduling issues - there is generally a subcontractor who is financially very incentiveized to make sure stuff happens when it should with no blockers for his crew
Overall your comment is really out of touch with reality, and a bit... dumb.
Our educational system is not perfect, and is geared towards sitting still on a bench and cram in theory. I'm sure most people here had no problem with that.
But there are also kids who get bored easily, who hate sitting still on a bench. They are therefore not that much less intelligent than the rest of us. They might also hate getting told what to do.
I worked with blue collar people, and yes, a lot of them have their limits intellectually. But I also saw blue collar workers that had to correct lesser bright mechanical designers in their designs. For them it was "obvious" how something couldn't work.
In Belgium, I see a lot of bright people that did not fit in our educational system, to become contractors (electricians, floorers, plumbers, ...)
Technical schools play a role here where those kids can practically work with their hands and learn that way.
While doctors, lawyers and software engineers make pretty good money, I've never met anyone with their name on a construction company who was poor. I think there are plenty of smart people are in the field. Feeling that doctor/lawyer/software engineer as the default path to wealth just shows a failure of imagination.
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.
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.
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.
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.
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.
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.
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.
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.
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%.
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.
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.
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.
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.
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.
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.
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 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.
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.
So I read the last paragraph .... and I am thinking this must be the guy that designed the great millenium leaning tower of San Frencisco.
"Civil engineers don’t always have the luxury of founding structures on the most stable of subgrades, so we’ve come up with foundations that keep structures secure on sand, silt, clay, and even floating on water. When the rain comes down, and the streams rise, and the winds blow and beat against our structures, they almost always remain standing no matter what the geology is below."
I've noticed more than a few documentary style youtubers create a blog post with basically the script of the video.
Is this for SEO purposes, or is it some sort of plan B in case of Youtube takedowns or is it an attempt to build an on-platform following?
I like watching practical engineering, but I don't like reading video scripts, so while I understand that not everyone have their own preferences, I'm not really sure who this is for.
>Speech-to-text is quite good and cheap nowadays. So, why not?
It's gotten comparatively good. But my experience with podcasts was that if I wanted a professional transcript I'd put online--as opposed to this is the general gist of the thing that's better than nothing, possibly just for my own reference--I'd get it done by a person. Wasn't worth my time to do the extensive editing that would be required to polish it.
Satellite internet user: Video is effectively non-existent for me. Many hosts won't even attempt to serve connections at the "throttled" speeds we get.
> I like watching practical engineering, but I don't like reading video scripts, so while I understand that not everyone have their own preferences, I'm not really sure who this is for.
I mean, you answered your own question. I don't like watching videos that work just as well in text form, and I understand everyone has their own preferences.
Very thankful for the extremely few popular channels that do this!
Foundations do not have to go to bedrock but they do need to be poured on tightly compacted dirt or the building can eventually sink and crack as the loose soil gives under the weight of the structure.
If you watch a lot of home builders nowadays, they don't bother compacting, which is why people tend to have settling issues and cracking in their brand new homes after a few years.
Another issue is pouring a foundation on clay because it will move whether it is compacted or not because it is around 40% water by nature.
They don't bother doing more than a token effort at compacting because unless you have really crappy soil the foundation is likely strong enough to spread the load to enough soil to bear the weight without cracking. If foundations didn't need to do that job they'd have a lot less if any rebar. Basically the way they do it is cheaper and good enough.
Even pile foundations don't always go to bedrock. In fact, most of the load bearing strength of a driven pile is in the friction along the length of the shaft, and the end-bearing capacity is a fraction of that. (It's intuitive if you recognize the surface area of the end of the pile is much smaller than the surface area of the sides of the pile)
Soil calculations treat the soil almost as if it is a highly viscous fluid.
In regards to settling - all structures settle. It is the structural engineer's job to design a structure that anticipates settling and mitigates strain in the rest of the structure.
Clay is interesting, because it has a property called consolidation. If the clay is overconsolidated, that means the overburden pressure in the past is higher than the pressure on the soil now. If a clay is overconsolidated, it settles a lot less.
I think the problem with "Roman concrete was better" is that archaeologists don't know about construction neither. You can see that as well when they estimate the duration of the construction for pyramids, or when they state 20 men were needed to move some block/stone/whatever around. A sleight tool like a pulley or a sled decimates the amount of manpower needed. Our ancestors might not have had our technology and knowledge, but they were as smart as we are.
decimate:
verb
- 1.kill, destroy, or remove a large proportion of.
"the inhabitants of the country had been decimated"
drastically reduce the strength or effectiveness of (something).
"public transport has been decimated"
- 2.(historical)
kill one in every ten of (a group of people, originally a mutinous Roman legion) as a punishment for the whole group.
"the man who is to determine whether it be necessary to decimate a large body of mutineers"
Sorry, I'm not a native speaker, I wanted to say: effort*=0.1. Thx for pointing this out.
There is a field of experimental archeology (https://en.wikipedia.org/wiki/Experimental_archaeology) in which they try to actually reproduce ancient building techniques and the like. There's obviously some conjecture involved in the practice but this exact concern is why it's so valuable.
Reminds me of an HN post from last year about someone recreating a stool found in an Egyptian tomb. I thought the reverse engineering was really fascinating.
Fans of the Practical Engineering who would like to support the channel should consider pre-ordering a copy of Grady Hillhouse's book "Engineering in Plain Sight": https://practical.engineering/book
> If those construction workers stepped into any office building, they might see you hanging around the water cooler talking about your favorite YouTube channels and start a rumor that office workers are so lazy.
> That’s why engineering exists in the first place. With an unlimited budget, my 2-year-old could design a bridge that carries monster trucks over the English channel for a million years.
I'd like to see the math on this one. A million years is a lot of weather (including tropical storms that sometimes reach England), wars, meteors, earthquakes, climate variation, but especially a million years of weather.
I suppose if you truly had an unlimited budget you could build it thousands of feet tall out of gold plated titanium mined from the moon.
Wrt "people standing around", software is the same. You look at what it takes to ship a one-line change in any nontrivial, well-engineered website or app, compare the textual code change with all the work that goes in waiting for the compiler, code review, writing and running unit tests, integration tests, running release QA tests, testing in prod, and final release, and you got a lot of apparent overhead "waiting around". One difference is perhaps that the work is more amenable to automation and adding machines to replace humans, but even that (as in construction) has its limits.
My #1 frustration with road construction: You effing barreled/cordoned off 8 miles of road but you're working on about .1 mile of it for a day? I would LOVE to hear the justification for that.
While I'm loathe to credit accounting and economics for things considering how they've basically underpinned our societal direction towards environmental destruction, the issue is fundamentally misaligned incentives.
Flat bid basically optimizes for monetary extraction of the "ownership class" from the government, and labor and the actual project are just annoying costs.
Features + schedule + cost optimization would come from incenting labor and management. If workers got paid salary + a huge bonus for schedule then things would get a lot more efficient.
Just look at your typical big enterprise, it's basically an authoritarian boondoggle, with only very long-range economic realities ever intruding, and the organizations themselves use monopolies to avoid those. It's these big hierarchies, with people carving out sub-domains and knife fighting over budgets.
What probably should happen is internal competition: if you have several datacenters, let them compete against cloud offerings and other internal datacenters for customers. Don't organize them to a central org.
Road construction may not be vanilla cookie cutter, but it should be a well known problem at this time, and frankly it should be an embarrassing parallel one. YOu have the route set down, you have the plan in place, you have the 8 miles of barrels done, you have phases (tear up, clear out, re-grade, pave) that can be pipelined. You can have teams do it in parallel in separate parts of the road to compete for incentives.
But... that's not the point. The elephant in the room is that this is government revenue extraction, corruption in the guise of stimulus, and really, if we were totally efficient in road construction, we'd just have overbuilt the roads and sprawled even worse in the US.
People hate on Musk, but look at the infrastructure his companies produced:
Tesla has a national charging network, what, a half-decade and counting before anyone else?
SpaceX has a nutso cheaper space launch capability (if starship even approaches its targets)?
If Boring Company does the same for tunneling per their stated goals, it would be a trifecta.
The first two really aren't magic by some modern day wizard. Tesla is about changing the world for the better with EVs, Musk probably gets crazy overwork from his staff with just that core missions.
SpaceX is about getting humanity to the stars. Again, Musk doesn't have to whip people to get productivity, the mission and goal are the drivers: awesome cool space projects.
I also recall a story from decades ago about an all-in-one road builder that would dig up, break down asphault, regrade, and then lay down the asphalt all in one package, and it would crawl along. It never got adopted because it would make things too cheap. Or maybe some labor/unions killed it. This was pre-internet, so it was probably an old wives tale, or maybe it required a nuclear reactor. I can't find it in google, which heavily favors recent stories.
The lack of low-level robotics, specialized equipment, and other similar things after 20 years of gigahertz processors and robotics in manufacturing seems to point to industry resistance to productivity enhancement, which one would expect from a business that is fundamentally corrupt.
At CES I've seen multiple strength-enhancement exoframes, and this was 8-10 years ago. It is insane to me that these aren't in extensive use and undergoing active economies of scale and year-on-year improvement. It's simply too easy and satisfying for the elite class to have manual laborers do pure manual labor, enhancing their relative perceived position in the great pecking order or America's class system.
Don't know how things are done in Texas but I know in Alberta and BC most construction projects have a prequalification stage so while the lowest bid usually gets the job everyone that bids has already demonstrated they are capable of handling said project.
177 comments
[ 3.4 ms ] story [ 225 ms ] thread>Will you build a bridge that’s inexpensive, but will have to be replaced in 25 years, or will you spend twice the money for more concrete and more steel to make it last for 50?
Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired .
> Most construction projects are bid using a set of drawings and a book of specifications that include all the detail necessary to build them. An engineer, architect, or both has gone to great lengths to draw and specify exactly what a contractor should build, often to the tiniest details about products, testing, and procedures. You can see for yourself; just google your city or state, plus “standard specifications,” and scroll through what you find to get a sense of how detailed contract documents can be. We go to that level of detail in defining the project before construction so that it can be let for bidding with the confidence that an owner will end up with essentially the same product at the end of construction, no matter which contractor wins the job.
This is pure theory/wishful thinking, the regulations/norms/specifications are a needed thing (and a good one), but projects in reality (non-trivial ones) are largely "vague" or however not detailed enough (there are exceptions, of course, but while the project does make an even enough bidding ground it usually fails to properly detail the construction). It is of course a compromise of sort, making a good project would simply cost too much and take too much time.
The assumption here is that all the architects and/or engineers are omniscient, competent, honest and have all the time in the world to think about the project and an unlimited budget.
>But, the lowest bidder model is still used around the world because it generally rewards efficient use of public funds.
No, the lowest bidder model is still used around the world because it is the simplest way to assign a contract without (the public manager) being responsible of the decision to award it to company A instead of company B.
The same is true with experienced builders.
And experienced owners.
Hence everyone at their umpteenth rodeo knows that the low bidder has a list of change orders developed while preparing the bid.
And everyone knows how the owner will react.
And everyone knows how good or bad the plans are.
Almost inevitably, the plans are good enough, which is all that's needed.
1) the builder changes are accepted at the same cost AND they are actually same or better than project
2) the builder changes are accepted at an extra cost AND they are actually same or better than project AND the construction goes over budget
3) the builder changes are not accepted, the project is (hopefully) executed as designed BUT the builder losing money will not complete it (or not complete it in time) with daily bickering on site AND an endless trail in Courts
No, the plans - generally speaking - are not good enough.
A change order always changes the cost of the work.
“Change order” and “cost of the work” are terms defined in the contact (often by reference) and come with implementation protocols.
Once a person has been around the block a few times, they usually realize that the plans are not the construction, the design brief is not what the owner actually wants, and the contractor doesn’t build everything right.
And the whole thing is about working together to get the building built in a way that favors getting the next project.
Exactly.
You've made it sound as if it's about avoiding responsiblity, while the motivating force behind this model is to avoid creating situations which would incentivise corruption. When you take away any decision-making power from the official awarding the bid and he basically just has to follow a pre-written algorithm, he can't be corrupted.
I have made it sound like that because I wanted it to sound exactly like that.
The "official" motivating force is the one you mentioned, but that doesn't mean that it is the actual one, nor that lowest bid is actually the best possible formula[0].
It is the up-to-date "the algorithm made me do it" version of the "officer, the devil made me do it" excuse when (if) the project is delayed or goes over budget, the builders are usually considered the culprits (whether it is actually their fault or not) and they were selected by applying the algorithm (so all is fine).
Consider how you (private person) would normally award the construction of your house, likely you would:
1) find a list of local contractors (mostly from world of mouth)
2) get from 3-5 of them offers
3) compare them, analyze them with your arhitect/engineer, talk with offerers about possible mistakes/inconsistencies
4) finally choose the builder (more often than not you will choose not the lowest bidder but rather the one that overall seems to you more capable/reliable/interested in the work)
With what a (say) local council would probably do to build (still say) a small school:
1) publish a request for bids
2) obtain anything between (say) 10 and 200 offers
3) award the contract to the lowest (and valid according to the algorithm) offer
It is clear that in your private case you have no incentive for corruption, but - in order to avoid the risk of corruption - the council just awarded the contract to a "number".
This "number", more likely than not, is the result of "blind shooting", the builders need a certain number of contracts and they need to make many offers, and have no time to analyze them in detail.
[0] as a matter of fact "pure" lowest bid is relatively rare there are usually a number of corrective items either in the algorithm or in the norms regulating the bid, in some cases they can be effective, in some cases they introduce some perverse incentives to the offerers.
I spoke with a family member at a wedding recently who manages civil engineering projects in his city (he himself is a civil engineer), a regional transportation hub. He said it's all lowest bidder with one exception: a contractor with a history of shoddy work. His reasoning was that he'd really have to justify going with anyone but the lowest bidder. In other words, he'd be responsible for the outcome.
Keep in mind, most of his job is ensuring that the city's spec is followed and if not that contractors fix shoddy work. It's non-trivial, certainly couldn't be replaced by an algorithm and gives him pretty significant skin in the game (if he did his job poorly and let shoddy construction make it through, he'd be out of a job).
Well, if the public manager has no powers in the assignment, there is no reason why the builder should "pay" him/her, from this point of view lowest bid is effective as an anti-corruption method.
And by bidding low the builder will have less available money to possibly attempt to bribe anyone.
But then (maybe - just hypothetical) once the lowest bidder is awarded the contract they will find each and every possible way (including bribing) to get more money for the contract, changes, improvements, extensions, etc..
The usual counter-argument is that all builders are the same, so if you award the contract to (say) the 2nd lower bidder, they will make exactly the same, only starting from a higher "base",
There are often very fine lines between "contributing to bankrupcy of builder", "paying a fair price" and "spend too much public money".
> Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired .
Why does that time extension hold for the 50-year bridge but not the 25-year bridge?
The most common survivability analysis is a Weibull model which typically has a longer right tail to the failure distribution.
In terms of cost per year of having a bridge.
Of course it would apply also to the less lasting one.
In a perfect world, besides ordinary maintenance (which rarely is performed anyway in a timely manner) when a bridge is near to its planned end of life (let's stay on the 50 year duration) it should be inspected and - if it is the case - its life could be extended by - say - 10% or 5 years, BUT there should already be present:
1) the projects and all authorizations for the new bridge
2) a reserve of money ready to be spent on the new bridge
Then (and this is actually an increased cost/waste) these "granted" extensions of life could be repeated a number of times BUT should be "hard-capped" anyway to - say - 30% of the planned duration, in name of more certain safety, it will happen that you will demolish and rebuild a perfectly good bridge, but you will also in many cases prevent a disaster.
What happens in the real world is that once the 50 years have passed, an inspection is made, and it is determined that everything is good enough, let's make another inspection in 5 years time or let's make this minor repair, and let's see what happens in 5 years time, rinse and repeat until the structure has double the planned lifetime and finally something happens (be it a structural failure, an accident, whatever) that forces to close the bridge (or to reduce load on it or in the worst case the bridge collapses) and at this point starts the race to make the project, get the authorizations, gather the money, etc, which adds two or three years to the time needed to have the new bridge built and usable.
If you prefer, the issue I was trying to point out is that usually we need an "unexpected" event to trigger an "emergency response" whilst the bridge nearing its end of life is something known and expected.
[0] which is that once something is built, for some reasons it is often considered (wrongly) to be eternal
[1] which anyway is only a very rough estimate, not an exact number, duration for reinforced concrete or steel bridges depends on so many factors that is impossible to determine accurately a possible "structural" life.
The theme is more about whether to build "massive" (and expensive) more lasting structures or build more economical but less lasting structures and how to properly evaluate the expected lifetime of these structures.
We know empirically that many (reinforced concrete) structures built 70/80 years ago (some even less than that) start showing a number of issues (that often require "heavy" repairs) besides the few that made it to the news.
We don't have that many examples of earlier constructions of this kind (pre-stressed concrete is relatively recent as a technology), but we do know that in many countries a large number of bridges were built in the '60's and '70's so they are nearing the time they will reach the age we already found to be critical.
Actually no, it isn't working because it cannot possibly work, at least not with decades old structures (that however do not collapse because they were often over-engineered, because after all they weren't built so shoddily and for a thousand other possible reasons).
A bridge inspection more often than not amounts to a visual inspection, to detect cracks, check bearings, but while some elements of the structure are visible (as said bearings and concrete surface) the state of internal cables is hard or impossible to check, though there are some new techniques that look promising (though they are not yet AFAIK properly documented/standardized), as an example, JFYI:
https://www.youtube.com/watch?v=pKWxpHsLBRk
And there is another key point, norms have obviously changed a lot in the several decades since the construction, original calculations and drawings may have been lost, and there is the need to re-do the calculations with the new standards of loads and check whether the current loads/frequency of traffic is compatible with those the original project took into account.
In the real world there are other factors too, like the risk that the nearby city will grow enough that the bridge will need to be expanded after 25 years. The entire second half of the 50 year cost may be wasted in that case, as expanding the bridge may be at least as costly as building it in the first place.
Or in 10 years traffic demand goes down, so that this bridge is no longer needed. Or boat traffic changes, and this bridge is now too low. More waste to tear down the 50 year bridge than the 25 year bridge.
Or if the bridge gets bombed after 25 years. Then too the 50 year bridge is a waste.
> > Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired.
Assuming the bridge would actually be replaced at its actual end of life (25/50 years) and assuming a horrible return on spending (double money for only double the life), I'd say the 25 year option would be better in many (not all) cases.
From a cash flow perspective, it'd be helpful for a local government to avoid immediately spending on infrastructure costs that could be delayed for 25 years (when the lower cost bridge would be due to be rebuilt).
From the unknown future perspective, the city/town population could possibly change (bigger/smaller) 25 years into the future.
If the population grows, replacement bridge would need to be bigger and they could use the saved money to build a bigger one. Of course, if the population shrinks, they could spend less on a smaller replacement bridge.
Again, this assumes a poor return on increased spending. Doubling the costs to double the life. If you could double the costs and triple the life or increase the cost by only 50% to double the life, the equation favors going with the longer term bridge.
But the assumption here is that the replacement bridge is built "overnight" or however without altering in any way the normal traffic on and around it, which is very rarely the case, more likely you should expect months or years (of course depending on the size/complexity of the bridge) of limitations/difficulties with the city traffic, noise, dust and all the issues usually connected with construction sites.
This is an indirect (hidden) cost of all kind of infrastructures that the population/users will have to bear.
> Of course the second (which is what is actually usually done) the issue being that in real world after 50/60/70/80 years the bridge won't be replaced/repaired .
Was just relating this story to someone else the other day. As a kid, there was a lot of roadworks around us. Due to cold weather and hot summer, roads were constantly developing seams/buckles and potholes. This was often chalked up to 'unions bad - cheap materials - etc'. Newspapers would run 'investigations' every few years, etc.
I think the road folks often did poor jobs of explaining decisions, and maybe it was literally always just "cheapest bid".
But I look back at a road that was bad for years - it was repaved at least 3 x over a 10 year period I remember. THEN... it was expanded from 2 and 3 lane road to 6 lane. The land was there on both sides, and it had been in planning for probably 10+ years. Knowing the road will be torn up less than 10 years in the future, I can understand "just use cheapest patching for now" because it will get thrown away 3 years from now.
However, that was never something that ever seemed to get across in news 'investigations'. Note, I'm going back to the 80s and 90s in my head, and I was younger - there may have been some info I missed, but even as I grew in to an adult... little hard info seemed to make it out to the general public.
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.
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
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.
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.)
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
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 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.
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 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 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
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.
See eg https://web.mit.edu/15.053/www/AMP-Chapter-09.pdf for some examples of simulating non-linear constraints in integer programming.
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.
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 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.
Approximate solutions are much easier to reach. Methods like simulated annealing can even approach them stochastically.
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-...
I build stuff. There's always problems that need to get solved that you haven't anticipated.
> But today we have ensured that basically no smart people are left
is wrong.
There are many smart people who did not get majority A's in high school. High school performance is not a good metric for problem-solving skills (AKA, general intelligence).
Also it is so strange that people here don't think that poor wages has any effect on the quality of workers in construction, even though they believe that to be true basically everywhere else. I strongly believe the reason we see so many problems with construction is simply that the wages today are so skewed and that greatly impacts the availability of talent, since people who can choose to go elsewhere mostly do so today.
Only reason I can think of is that most here assumes construction work is so easy that you don't need to be that smart to do well there. Otherwise I don't understand these comments.
It's a whole microcosm with its own constraints...
In fact, since you piss on construction, one of the oldest running jokes is how dumb the millitary people are, and how illogical millitary is.
Wow, that is a really funny joke. “How illogical military is!”
The half-joke/half-truth that "millitary intelligence" is an oxymoron has been widely circulated - heck, there are even Quora layman questions that take it for granted.
[1] https://www.quora.com/Why-is-military-intelligence-considere...
And of course all kind of insider jokes about such illogicallity and inefficiency (including long standing acronyms, like S.N.A.F.U), about how high command has little understanding of the situation on the ground in any real scenario, things dressed-up to look good, and so on.
Note, I am not saying that the military is stupid, I am saying that the trope is simply very well known by now.
[1] A work of fiction.
Construction is a very conservative business that innovates slowly. This is partly by design. It carries a lot of risk to human safety and capital that isn’t amenable to the “fail fast” paradigm of SV.
I guess that explains why the majority of software is so performant, bug free and a pleasure to use?
/s, obviously. And directed at the OP, not yours
Or maybe the people in software aren't very intelligent... Or they are all hard problems.
The incorrect lesson to take from getting a PhD is that you are really smart and can solve everyone’s problems. The correct lesson is that there are many fields this deep, and you can’t just read a bit and think you are knowledgeable about the whole field.
"It's not rocket science." "It's not brain surgery."
There are plenty of smart people on construction sites. I've met many, on site. Many just didn't get to complete high school because of the school system of their country, because family issues etc. Many of the skilled workers actually enjoy what they do and regard sitting in front of a screen all day as a waste of a life.
Anyone managing a crew or subcontracting _can't_ be dumb - it's a very challenging role
If there are people standing around on a building site it is mostly not because of blockers or scheduling issues - there is generally a subcontractor who is financially very incentiveized to make sure stuff happens when it should with no blockers for his crew
Overall your comment is really out of touch with reality, and a bit... dumb.
Maybe the truth is that we are all smart.
But there are also kids who get bored easily, who hate sitting still on a bench. They are therefore not that much less intelligent than the rest of us. They might also hate getting told what to do.
I worked with blue collar people, and yes, a lot of them have their limits intellectually. But I also saw blue collar workers that had to correct lesser bright mechanical designers in their designs. For them it was "obvious" how something couldn't work.
In Belgium, I see a lot of bright people that did not fit in our educational system, to become contractors (electricians, floorers, plumbers, ...)
Technical schools play a role here where those kids can practically work with their hands and learn that way.
[1] https://www.academia.edu/8250071/The_Principles_of_Product_d...
This comes from principals of project development flow mentioned below. I strongly recommend the book.
"The Goal" [1] does a good effort of explaining the theory of constraints.
[1] https://en.m.wikipedia.org/wiki/The_Goal_(novel)
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.
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.
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
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.
I seriously don't know why people make up statements with such confidence.
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.
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%.
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.
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.
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
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.
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.
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.
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.
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.
As a former res sparky, I was often the 1st sub in after the framers finished... often enough, before the framers were finished.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
This is not important. The tricky part is that the plan changes constantly.
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.
"Civil engineers don’t always have the luxury of founding structures on the most stable of subgrades, so we’ve come up with foundations that keep structures secure on sand, silt, clay, and even floating on water. When the rain comes down, and the streams rise, and the winds blow and beat against our structures, they almost always remain standing no matter what the geology is below."
Yep. "Almost always!"
https://youtu.be/ph9O9yJoeZY
Is this for SEO purposes, or is it some sort of plan B in case of Youtube takedowns or is it an attempt to build an on-platform following?
I like watching practical engineering, but I don't like reading video scripts, so while I understand that not everyone have their own preferences, I'm not really sure who this is for.
1. He probably already wrote a script for his video before production. 2. Speech-to-text is quite good and cheap nowadays. So, why not?
It's gotten comparatively good. But my experience with podcasts was that if I wanted a professional transcript I'd put online--as opposed to this is the general gist of the thing that's better than nothing, possibly just for my own reference--I'd get it done by a person. Wasn't worth my time to do the extensive editing that would be required to polish it.
I mean, you answered your own question. I don't like watching videos that work just as well in text form, and I understand everyone has their own preferences.
Very thankful for the extremely few popular channels that do this!
If you watch a lot of home builders nowadays, they don't bother compacting, which is why people tend to have settling issues and cracking in their brand new homes after a few years.
Another issue is pouring a foundation on clay because it will move whether it is compacted or not because it is around 40% water by nature.
Even pile foundations don't always go to bedrock. In fact, most of the load bearing strength of a driven pile is in the friction along the length of the shaft, and the end-bearing capacity is a fraction of that. (It's intuitive if you recognize the surface area of the end of the pile is much smaller than the surface area of the sides of the pile)
Soil calculations treat the soil almost as if it is a highly viscous fluid.
In regards to settling - all structures settle. It is the structural engineer's job to design a structure that anticipates settling and mitigates strain in the rest of the structure.
Clay is interesting, because it has a property called consolidation. If the clay is overconsolidated, that means the overburden pressure in the past is higher than the pressure on the soil now. If a clay is overconsolidated, it settles a lot less.
https://news.ycombinator.com/item?id=28659898
Hell, am an office worker and would agree!
I'd like to see the math on this one. A million years is a lot of weather (including tropical storms that sometimes reach England), wars, meteors, earthquakes, climate variation, but especially a million years of weather.
I suppose if you truly had an unlimited budget you could build it thousands of feet tall out of gold plated titanium mined from the moon.
While I'm loathe to credit accounting and economics for things considering how they've basically underpinned our societal direction towards environmental destruction, the issue is fundamentally misaligned incentives.
Flat bid basically optimizes for monetary extraction of the "ownership class" from the government, and labor and the actual project are just annoying costs.
Features + schedule + cost optimization would come from incenting labor and management. If workers got paid salary + a huge bonus for schedule then things would get a lot more efficient.
Just look at your typical big enterprise, it's basically an authoritarian boondoggle, with only very long-range economic realities ever intruding, and the organizations themselves use monopolies to avoid those. It's these big hierarchies, with people carving out sub-domains and knife fighting over budgets.
What probably should happen is internal competition: if you have several datacenters, let them compete against cloud offerings and other internal datacenters for customers. Don't organize them to a central org.
Road construction may not be vanilla cookie cutter, but it should be a well known problem at this time, and frankly it should be an embarrassing parallel one. YOu have the route set down, you have the plan in place, you have the 8 miles of barrels done, you have phases (tear up, clear out, re-grade, pave) that can be pipelined. You can have teams do it in parallel in separate parts of the road to compete for incentives.
But... that's not the point. The elephant in the room is that this is government revenue extraction, corruption in the guise of stimulus, and really, if we were totally efficient in road construction, we'd just have overbuilt the roads and sprawled even worse in the US.
People hate on Musk, but look at the infrastructure his companies produced:
Tesla has a national charging network, what, a half-decade and counting before anyone else?
SpaceX has a nutso cheaper space launch capability (if starship even approaches its targets)?
If Boring Company does the same for tunneling per their stated goals, it would be a trifecta.
The first two really aren't magic by some modern day wizard. Tesla is about changing the world for the better with EVs, Musk probably gets crazy overwork from his staff with just that core missions.
SpaceX is about getting humanity to the stars. Again, Musk doesn't have to whip people to get productivity, the mission and goal are the drivers: awesome cool space projects.
I also recall a story from decades ago about an all-in-one road builder that would dig up, break down asphault, regrade, and then lay down the asphalt all in one package, and it would crawl along. It never got adopted because it would make things too cheap. Or maybe some labor/unions killed it. This was pre-internet, so it was probably an old wives tale, or maybe it required a nuclear reactor. I can't find it in google, which heavily favors recent stories.
The lack of low-level robotics, specialized equipment, and other similar things after 20 years of gigahertz processors and robotics in manufacturing seems to point to industry resistance to productivity enhancement, which one would expect from a business that is fundamentally corrupt.
At CES I've seen multiple strength-enhancement exoframes, and this was 8-10 years ago. It is insane to me that these aren't in extensive use and undergoing active economies of scale and year-on-year improvement. It's simply too easy and satisfying for the elite class to have manual laborers do pure manual labor, enhancing their relative perceived position in the great pecking order or America's class system.
I wish we'd have that in software development (hard to say "engineering" here).
I've experienced this, and it's not my ideal working condition.