I can only assume you are putting incorrect readings into the calculators.

Are you making sure to put the temperature at the time of the humidity reading, since they reach their maximums at very different times of the day. If you just put max temp and humidity readings for a day in you are going to be wildly wrong.

Though I agree that the analogy doesn't really buy you much useful leverage when seeking useful understanding.

I would characterize all the statements you made as false. Though it does depend on what your standards are.

Most of the critical things are done well enough, but that is a pretty low bar.

Your service life is also going to take a hit due to having a lot more of the most unreliable aspects in construction - a joint.

There is a ton of prefabrication in construction already. There are also large libraries of shared details.

Most of the bits that are not already prefabricated are the bits that don't have simple interfaces. Either to each other or to their surrounding environment.

Overall design and how it is detailed is the dominant factor in time it takes to build things.

Do I have lots of joints that have to be perfect or can they be rough cut and covered with trim?

Do things assembly easily without having to fiddle due to having the correct tolerances?

Cuts and joins are what take the most time. The less cuts and joins you have the cheaper and faster things will be. Also cuts and joins that have to be done to high tolerances take a lot longer.

I have hope that as designers and tools get better at dealing with the connection detailing and with material/assembly tolerances it will lead to better outcomes in the future.

I would really recommend watching "The Building Science of Prefabricated Construction". It does a good job of going over the realities of this form of construction.

[1] https://www.youtube.com/watch?v=aIeZlCfweMo

I can see how the recommendation you mooted would improve incentives in some procurement domains. Large civil works isn't one of them however.

I am not sure if you can implement a system that would work well when your actors are profit driven work that needs to be done can only be done exclusively by one entity at a time, and as a bonus that extra profit gives you more feedback into how the system operates. There aren't a lot of natural negative feedback to keep things under control in that system.

Especially if your goals are to reduce overhead.

I just don't think your incentives would produce better outcomes, from my perspective it would make things worse.

Even as an ethical actor you can only price what is specified. However, you can then use your knowledge about likely the real variances that will be needed and risk profile to place a bid that takes this into account to remove margin or discount the bid price.

It also seems like you are only trying to address the problem of people introducing needless variances as a way increasing profit.

Which is not the case being discussed here and I don't think it is major reason for cost overruns. They haven't requested an increase, they have found out that to satisfy the engineering requirements of the project that more work has to be done.

Let alone that we basically award this work one estimated number and the ability to get through a paper work hurdle.

If you start making those rules complex it becomes hard to compare bids to each other, since your bids are likely to become non-transitive based on the scenarios.

Cost plus is the normal way this is side stepped, but unless you have a system that is mostly ethical actors that can break down. And if you have all ethical actors pretty much any system will work...

[1] http://media.digikey.com/pdf/Data%20Sheets/Cherry%20PDFs/MX%...

http://search.digikey.com/us/en/cat/switches/pushbutton/1114...

If you find you are using a lot of EAV, polymorphic associations, multicolumn attributes, trees, graphs it might be a better option to go down one the on of the many NoSQL routes. Key/Value, Column Stores, Document and Graph databases. Sometimes you can make huge gains in design simplicity because you persistance and/or queries map far more cleanly.

An interesting example of "NoSQL" on top of an "RDBMS" is Salesforce [1].

A huge upside to RDBMS in my view is that they are 'well understood' in production, and operations know how to deal with them.

It is a big design space out there, and you can make a lot of tradeoffs :)

[1] http://www.infoq.com/presentations/SalesForce-Multi-Tenant-A...

The difference between waiting a couple of hours for a crane one day every few months, seems like a good tradeoff against sitting in gridlock everyday or the risk of being run down by a car imho.

But yes I agree that humans are not rational and would not do it for petty reasons. Can easily solve the 'look at my legs' problem with opaque tubes :P

I am not sure this is a 'solvable' problem. You can mitigate by always working in pairs. But even that just reduces the potential for privacy breaches.