Myths about construction
practical.engineering
practical.engineering
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).)
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.
Approximate solutions are much easier to reach. Methods like simulated annealing can even approach them stochastically.
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.
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.
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.
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.
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.
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
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.)
"The Goal" [1] does a good effort of explaining the theory of constraints.
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.
[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.
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.
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.
>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.
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 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".
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.
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.
> > 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.
> 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?
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.
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.
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.
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.
Hell, am an office worker and would agree!
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"
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.
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.
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!
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 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.
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.
"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!"