Indeed.

However, it's my observation that a very significant economic gain is there to be had with a better, up front investment. Not just drawings and models. Intent.

It's entirely possible to package up a ton of stuff that can be used to assemble a project, and when that's done, those packages can drive all the info needed by the contractors each day, if desired. This technique was applied to a major airport we probably both know, and it was done on mechanical CAD for those reasons. The bid was more accurate, and the project ran much closer to on time and on materials.

Buildings are sort of dumb and sort of simple too. Of course, in the one time, forward create kind of way, sure. It's just a pile of simple geometry. On the other hand, if one actually wants to move up a level, add intent, build in design rule checks, etc... suddenly, you've got a class of buildings possible, those buildings largely derived from set pieces, with the real design effort being more centered on the unique aspects of a given site.

Couple this with a bid process that is driven off that same intent, and doing prospective designs starts to change. Not only do they get a realistic idea of the design outcome, but they get bids, materials, etc... that are closer to real, and derived from a team with a history of doing that.

I never classified anyone as idiots. I see it more like being too conservative. Happens in mechanical spaces too.

It's just process pieces that are laying around waiting for people to make better use of them. Many are fat 'n happy, so they don't. Others, particularly in the strategic project space, really are looking for better ways to get things done, and done on time and on budget.

Real property has it's own set of requirements to deal with, but in the end, they are just requirements. Employing more of what the tools can do really can have an impact. I've been a part of a couple of those, and the results were pretty impressive. Coordinating those humans, once you've got a dataset that is live, real time, able to iterate based on variances that just happen with property, doesn't look a whole lot different from that same process in the product space.

Manufacturing, and the product space in general, struggles with this same thing, and there have been significant improvements in overall communications in the last 10 years that are just now really starting to see wider use. All electronic shops are here now. 10 years ago, there were a few, and some concept places, but most everybody was slogging through the piles of paper and high latency, high labor means and methods. Ugly stuff.

Today, it's possible for a CAD dataset to drive all of it. And parts of that are still ugly, but improving. AEC can do this too. Again, it's being done by a few progressive groups out there, and that's direct experience. I happened to be one of the Mechanical CAD guys willing to work with them and translate techniques, and understand their scenario, language, requirements, etc...

Hey, this also ties in with boats...

So, when a yacht gets made, it's custom. They do ungodly hacks during actual construction. The less up front planning and visualization work they do, the more hacks there are. "Just make it fit, and send the result back to engineering..." Fine. Each boat ships with a document set that basically attempts to detail what happened and why. Tons of books.

One artifact of the CAD process was planning more of those hacks away. Another was packaging up core bits where intent can be well defined. And the docs were derived from all that, then more lightly marked up. All electronic, with a paper back up, just because the sea. The sea is toxic. But, it cost a lot less to do just a little bit more up front.

Forward 5-6 years, I ended up in a scenario where it worked the same way with a building. (I have a dataset of a library in SF that I helped figure out how to work on.) They got their site study docs, and then drove the CAD from there, building in options, expressing intent, etc... On the prospect walk through, they were able to make real time changes and sell that deal. Potent stuff. I heard a lot about "client didn't pay" and being able to work directly with them, real time, can change that equation. And each project, sold or not, does produce a lot of great stuff that can be used on future ones too. One example might be that parking garage I mentioned. Property varies a lot. However, it is possible to build a parking structure with a lot of flexibility and design rule checks that can fit into a lot of scenarios. Worst case, it's an 80 percent basis, for the 20 percent real work of dealing with that particular site.

When site construction began, a computer went to live there and all the coordination, handling of problems, documenting variances, distribution of materials, measure, etc... happened on it. Sometimes drawings got output, maybe for the more device toxic tasks (and that gets tossed when work is done), and a lot of people read 3D data and worked from it directly on a laptop or pad. Walk on site, pull up model, expose the relevant bits, compare, measure, do.

When the building is done? Computer stays there. It's the living record of the thing.

Employing these means can yield the ability for doing more than one project at a time too, or at the least, more projects, faster, with fewer people.

Right now, cars, airplanes and other big things also have those living records too.

What I'm trying to get at here is the clusterfuck of CAD (and it's often just that) has a lot to do with how connected and fluid and accessible the data is to people. When the people can work from the data, and that data is derived from the model and the intent in that model, a whole lot of that clusterfuck goes away.

I think, after having this very interesting chat, the desire to realize a more compute oriented approach has some elements in common with just making the CAD more widely and directly usable by most people, not just CAD people.