> The drawings are more for the regulators such as building control than actually for the people working on site.
It would also depend on the architect, primary contractor, and what kind of relationship they have. Sometimes plans are just thrown over the wall, but other times there is more collaboration.
I watch the YouTube channel of Matt Risinger, a building science focused contractor in Austin, Texas, and he seems talk with architects a lot (and they supposedly make up a good portion of his viewing audience). He regularly features Steve Baczek for example, on both his main channel and the 'secondary' Build Show Network, and latter does get into the details of the building process:
These high-end high-price high-rises usually use very detailed plans that feed into a building information model.
Sure, that doesn't mean there will be no problems whatsoever. (Plus there's always a difference between the as-planned and as-built plans, but at this size of project most of the differences have to be approved by various domain experts.) ... which again, doesn't mean there will be no problems.
Especially considering that these ultra-skinny super-tall high-rises use new/innovative/different methods and trade offs for some engineering challenges.
Residential construction exists in an entirely different universe from commercial construction. The team sizes allow for much easier collaboration and generalists who can paper over impedance mismatches between groups.
I think Alexander's ideas and patterns are very lean processes instead. He see what's the terrain like, what's the use like, builds a bit, and reevaluates along the way. He even explicitly have drawings rendered 'for regulation' but changes it after it's built.
Context: I'm assuming Alexander here refers to Christopher Alexander. He has authored books related to identifying architecture patterns with 'liveness' in them, from the very small to the big scale. I think a lot of his ideas can be applied to software too and even really matches up with Extreme Programming. I recommend reading The Nature of Order for the fundamentals of his ideas and how it fits with the world. I'll refer to him as CA in this comment.
I think it's the overspecialisation of roles and the 'waterfall' aspect of the engineering that normalises this. The architect don't (or can't) verify whether their designs work along the way. CA once described a story where he needs a constant feedback with the soil engineer for the start of the project but his request is denied by the client. The client wants the engineer to start and finish his survey first and then for CA to receive the reports only. CA ended up declining to work with the client due to that. As with Software Engineering/Development, there are questions that only surfaces when we do a part of the building, and can't be predicted. This is why the continuous feedback is important. I'm not sure whether the architect in your case _can_ come back to the site and direct the constructors against the drawings, even if the later directions are more suitable to build.
It's a bit weird that now we're taking missed plans as the default, when the Empire State Building (and NYC skyscrapers of the time) ran ahead of their schedule, with Lean principles by focusing on constraints and workflow instead of planning the minute details: https://chrisgagne.com/1255/mary-poppendiecks-the-tyranny-of...
I'm afraid that a lot of churn in Software Development also comes from a similar overspecialisation, overplanning, and the wrong kind of feedback loops. 30% of costs wasted seems like the better end for software. The difference is that building physical buildings has happened for thousands of years and there is a lot of history to compare with the current day. Software has at most 100 years of history, and currently it's still very much the wild west and every team is trying to stumble upon a process that is sustainable. This doesn't even count that a lot of developers see themselves and the job differently, and the organization also sees the Tech/Engineering team differently.
This comment is more of a rambling than a coherent thought, but I thought I'd get it out there. I'm sure I'm not the only one feeling like the current Software Development process is a mess. There has been good efforts (Extreme Programming and agile, not branded Agile) and current good effort (Basecamp's evangelism of their work process and the Shape Up book) to carve a sane way, but it needs to be the normal practice instead of the contrarian view/practice.
Yeah, the practice of extracting of patterns in software does refer a lot to A Pattern Language[0][1]. Admittedly I stumbled upon CA's work when I'm looking into building a design pattern for my current workplace. But it's a bit disheartening that currently CA is referred more towards the design and design system side of software instead of the building/writing, although patterns are still very much practiced.
> Talking to the constructors it is normal for architects to specify the impossible
If the drawings are indeed for regulators, then architects should be sued when they prove to be impossible impossible. Failing that, we should get rid of architects to begin with (if they draw impossible things, what good are they?), and have actual engineers draw something that can actually be built. (Of course, the engineer should risk a lawsuit if something goes wrong).
When we built, we had both, an architect and a construction engineer. The architect was a necessity to send plans for approval (you need a permission to hand in these plans, and an official stamp, both of which our engineer didn't have anymore since he was retired). Besides that, the architect was a complete waste of money. Unable to properly use his CAD software, made a ton planning mistakes. These mistakes had to be fixed by the contractors, e.g. plumbing requires a pump to get waste water to sewer level. For the ground floor that is, first floor is already above sewer level. Our architect passed both floors through the pump. And it continued on.
Basically, the architects plans were used as a basis to work from during construction. Luckily we had people able to do so. As our engineer put it: architects "paint" houses, the actual drawings and design to turn into something you can build is done by engineers.
Both, architects and engineers are liable for their designs so over here. Reason why the stamp is so important and expensive, you need quite a pricey insurance for that.
> The architect was a necessity to send plans for approval. […] Besides that, the architect was a complete waste of money
That's the problem I was trying to point at: you need to pay someone useless for the sake of bureaucracy. How is this not insane?
> Both, architects and engineers are liable for their designs so over here. Reason why the stamp is so important and expensive, you need quite a pricey insurance for that.
Ah, insurance: the reason why they're allowed to suck, and still be in business. That's not right. If the design is wrong, and it has consequences, whoever approved it should be personally liable for it, at least to a significant extent. A sufficiently serious blunder should bar them from approving designing buildings, or at least approving building designs, ever again. As should repeat offences.
Perhaps that's already the case, but the anecdotal evidence I amassed thus far (in France) doesn't isn't encouraging.
They are personally liable. That's what their stamp means.
And are you claiming that insurance should not be permitted? If so, that seems... Silly. People make mistakes. If a single mistake has the potential to ruin your entire livelihood, you'll quickly find that you're lacking anyone willing to put on their stamp without putting up enough money to cover all the liability. That is, instead of them pooling together to get liability insurance, each individual will instead have to pass on those costs to their customers.
> And are you claiming that insurance should not be permitted?
I'm saying insurances should probably be limited. So there'd be some cost of doing mistakes. Ideally it wouldn't be crippling if one makes a mistake here and there, but repeated negligence would drive one out of business. I expect this would drive the price of insurance down, and the salary of the engineer up. Hopefully this evens out for the customer.
Alternatively, let the insurances cover everything, but if one makes too many mistakes (or a very serious enough one), then they would lose their right to vet designs at all.
Let me compare this to physics. We theoretical physicists will publish an experiment that we think is perfectly feasible. When we show it to the experimentalists, they will laugh and implement a very basic version of it with lots of simplifying assumptions, because that is all that is possible within technology and budgetary constraints. They will write a paper about it. The theoreticians will understand things a little better and publish simpler variants of the experiment that are better than what the experimentalists did. This goes back and forth for years, sometimes decades, until both sides have come to an agreement on what is possible and yet useful.
I don't think this back and forth is what happens between architects and contractors. Contractors are not paid to produce knowledge, and they have no incentive to better conform to regulations. So I expect the convergence between architects and contractors is very slow.
I don't think the solution is to regulate architects more, but rather to create a system where contractors actively provide feedback, so that processes can be iterated upon.
> I don't think this back and forth is what happens between architects and contractors. Contractors are not paid to produce knowledge, and they have no incentive to better conform to regulations. So I expect the convergence between architects and contractors is very slow.
> I don't think the solution is to regulate architects more, but rather to create a system where contracts actively provide feedback, so that processes can be iterated upon.
I really recommend Christopher Alexander's work to you because of these views. He explores how past buildings have managed to be built and how the architect <-> contractor feedback loop can be effective.
Thanks. A Pattern Language is on my reading list. But I agree that in different times, cultures and legal regimes the feedback loop might have been much stronger. We should learn from those places.
It's not quite the same though. You are operating in uncharted waters and writing the rules with a feedback loop between theoretical and experimental. But the only bounds are what can practically be achieved given today's technological limits and understanding. Whatever both groups are working on, it stays between those 2 groups of experts.
In civil engineering you add a thick layer of regulation. Because what the architect theorizes about, and what the engineer ends up building will be directly populated or operated by the general population. An architect delivering something that isn't actionable as-is or an engineer implementing approximations that don't do the job will sit somewhere between worthless, fraudulent, and maybe even to criminal.
>and have actual engineers draw something that can actually be built. (Of course, the engineer should risk a lawsuit if something goes wrong).
The engineers put a note in the drawing that basically tells the contractor to overrule their drawing if it isn't up to building code. Somehow this lets them wash their hands of liability if the contractor builds to specifications that don't meet building code.
Calling someone an ‘engineer’ doesn’t make them magically a more practical person. I’ve been on the contractor’s side in arguments with structural engineers where they’ve designed details that were literally impossible to weld.
The goal is not to call people "engineers". The goal is to find the engineers. One way to do it is selection pressure: if the people who routinely produced non-working or otherwise impossible designs where eventually barred to do so, there'd be a better chance that the people left would be any good.
Does that mean we'd suddenly have a serious lack of engineer? Perhaps. That's only true to the extent that we already lack capable engineers now. It'd just be more visible.
I for one would like to be liable for my programming work (at least the part for which I'm paid). I could at least say to my boss "sorry, I can't risk approving that, we need more tests/refactoring for such and such part for such and such reason".
The implication is that regulators would never approve a design that is actually possible to build. That we're in a state where you have to lie to the regulators if you want them to approve your building.
The drawings are more for the regulators such as building control than actually for the people working on site.
Talking to the constructors it is normal for architects to specify the impossible, leaving it to the constructor to actually make it up on the job.
Somebody said to me that over 30% of construction costs is waste.
It looks like there is an opportunity to implement lean methods in construction. And weirdly implement Alexander’s ideas patterns and anti patterns.