Layers aren't Layers

[garethace]

Software engineers always write something that conforms to well established practice, such as, "COBie in the USA recommends uses Table 21 - for Systems (what cost consultants call elements) (what good CAD used to use layering for) (what revit uses AssemblyCode for) and Table 23 for Types (because of the link to products)(what good CAD used to use Blocks/cell names for)."

Some time, I'm just going to have to sit down and write a software, so that the industry can have a technology that is actually fit for purpose. The trouble with 'layers' is that they were weekend visitors in the 1980s, which turned into permanent residents, and not good ones at that. The analogy used by software engineers in layers, was broken to begin with all those years ago. It disobeyed a whole swath of basic rules for how a CAD system should behave. The trouble with layers, is that by the time software engineers got around to giving us proper layers (they were called references), CAD was yesterday's DJ, and BIM had already arrived, carrying with it, its own bundle of 'classic hits' from the 80s.

The fundamental rule that was broken in CAD in the implementation of the 'layer' concept, was to allow their definition to be left inside the individual drawing file. This breaks every rule there is, that is worth having. BIM software seems to have avoided this to a degree, in that families etc can be shared and loaded from outside, but still make the same mistake of bringing the family into the project file, which is the last place it should be. If layers are to work at all, they should never be allowed into the house. Because then they lose all of their natural object-like characteristics, which allow them to have real share-ability.

Layers aren't layers. Reference files are layers. Layers are just block/cells. Everything has to shift one place to the right. Layers were broken. References fixed layers. References finally gave us layers (but not for long, because BIM came along and broke it all over again!). References had gave us layers that worked, so that the original 'layers' could go off and do whatever it was they should have been doing all along.

'Layers' experienced 'mission creep', because their engineers piled more and more on top of the wagon, until it couldn't move. Software engineers have now turned a new corner and we have all ended up back in 1982! BIM families break references, which were sent out to rescue layers from themselves. It's like a search party getting into trouble, and sending out a second party - and allowing that search party to get lost also. Software engineers will keep shaking this same rattle, every decade, until eventually someone takes the rattle away from them.

Cells/blocks aren't cells or blocks. Cells/blocks aren't anything in particular. They are a subset of what used to be called 'layers'. Cells/blocks can live outside the file, but can inherit whatever layer pre-definition already exists within the file (so they tend to be good neighbours). A BIM family is a cell or block with a flak jacket put on. Fair enough. But it doesn't know what problem it is trying to solve, much less find an answer.

Layers should never be allowed into the house. Layers should be used to establish a perimeter guard. Inside the house, they are only sitting ducks. The more perimeter you can get your layers to guard, the more value you will create. BIM seems to have forsaken that rule in favour of more flak jackets. The wrong approach. It's basic strategy.

We NEED layers to work again, because we use those to gather the intel that construction project owners and guys in facilities management need. Layers are the tip of the sword, the Recon Marines. Think of layers like how search engine providers use spiders or crawlers - to GATHER stuff. If we can't create a perimeter, then all we have is a bunch of guys sitting in a house wearing (expensive) flak jackets, and that is what BIM is, nothing else. The hands of construction professionals are tied until this gets fixed.

Give us back layers that work, and we can deliver every scrap of information demanded by owners or governments, and then some. They will be astonished, amazed with the kind of data that will flow in their direction. Much of current discussion will become academic, as it should be. But the problem is contained above in original statements by software engineers, and has been, for the last thirty five years. Until then, I'm just going to admire my shiny new flak jacket. Wow! Check out these zippers. Make tools that are able to fit correctly around a process, not the other way around. At some stage, I am going to fix CAD/BIM. Because I know that software engineers are incapable of doing it. They will always end up back in 1982.


Brian O' Hanlon

-

[tedg]

Nice rant....made me chuckle.
I agree with the message that BIM is step in the right direction, but there are problems that need to be adressed and things could be made easier.

And that programmers are creating pretty things that pop and whiz, but not necessarily valuable to us in the trenches using this stuff.

:beer:

[garethace]

Underwhelmed is the word that springs most to mind to describe my mood in recent weeks, while starting a training course in BIM. I had heard so much about BIM. I even wrote a 15,000 word dissertation about BIM for cost control in construction (which focusses on present day research about transactions between collaborators in a BIM-centric environment).
http://www.scribd.com/doc/135072288/Decision-Making-and-Design-Cognition-in-the-age-of-Building-Information-Models

There is nothing wrong with BIM I guess. But it hasn't blown my socks off yet. That can happen, when one is still using training wheels. It's not so much what is in BIM products available, but what is not in it. Back when I worked in all 2D, we had more ambition about what kinds of collaborations would be made possible with the technology we had available then. I find BIM very sober in its aspirations and objectives, by contrast.

I think, it is still worth having lofty objectives. What gets my back up most of all, is when I hear software engineers refer to standards that were relevant in a world where 64 megabytes of RAM was standard. We've got 64 gigabyte machines on some desks now, 64 gigabytes! But where is the ambition that one would expect to see arrive hand in hand (from software engineers), with access to such a vast resource pool as that?

Here are a few lines, I wrote today, which I hope are easy to interpret.

When I look at something like say, PMBOK, the project management book of knowledge, what we find are 40+ standard knowledge areas. That is, a lot of standard components. What we see is a system, robust enough to scale across a lot of different sizes of projects, in a lot of industries, in many parts of the world. But we also notice the level of discretion, which is given back to the PM in this system.

It goes even further than that.

In the PMBOK, each knowledge area has inputs and outputs, and 'stuff' that can happen in between. Each knowledge area is a standalone thing by itself, which can be assigned its own resources and its own management. Each one, then fits into an overall project plan. There is merit in this. Instead of trying to build one big huge database, we end up with several that fix together. When one looks across the whole landscape of BIM now in 2013, there is no talk of anything like that. Something which will give back a measure of discretion to a central manager, in how to build their system, to suit the type of road they will travel on.

That's what I talked about in the idea of references, or something that lives outside the native file. One can then whip up something, by fitting parts together. I think with PMBOK, it is 'the fitting of different knowledge areas together' part, which is important. In BIM, people rave on about 'objects' that float around inside of a native application. Fine. These kinds of applications have existed for 20 years, and they improve continuously. But it is those objects that can survive outside the native application, which I find most interesting from a collaborative working process point of view.

Consider the 'eight fallacies of distributed computing', as described by James Gosling and his predecessors at Sun.
http://nighthacks.com/roller/jag/resource/Fallacies.html

To date, I find that evidence of thinking and writing about these external object chaps, is thin on the ground where BIM is concerned. So much that I read is about big native files (not just in construction, but also in mechanical design and product engineering). You read about projects, which have files shared between three offices (presumably three disciplines), each with its own project file database, in the region of 500MB. That is not an object. One could not say that something is object oriented, with three 500MB databases, that somehow try to communicate with each other.

Objects are small, robust little chaps, that get the job done. Each has its own mission and its own self-reliance, a support mechanism. They number in the hundreds or many more, and always survive outside the embraces of the home base.

[garethace]

I will give one example, just for the sake of examples. Take 'grids'.

I don't know why in the world anyone would ever want to internalize a grid into a central database. The first thing that should be floated out into the atmosphere never come back again, are grids. When you do that, you can assign whole teams to manage and monitor the grid - and what its interaction between itself and everything else. That is, if one wants or needs to assign responsibilities down to that level of granularity one can.

Where I am coming from in all of this, is the hand over to the Owner, and the production of this COBie file I am always hearing about. One thing that one of the software engineers said was interesting. If COBie can work efficiently, then the Owner is not just a guy standing at the finishing line, but they can be brought right back into the actual process itself and work with the Commissioning team for the project, providing input. That is what 'objects' are wonderful at doing. Accepting input, doing something, and producing some output, which is useful to some one else.

But I find it amusing to listen to those 'explorers' who have been on expeditions into the massive jungle of BIM, in search of the fruits that they require in order to make this meal that they refer to as COBie. I find it amusing. Because they come back looking and sounding like the walking dead, like they have been on some month long 'slash and burn' exercise. And what astonishes me, is that some people still think that having this huge, singular central jungle and building this road into that jungle to deliver the COBie, is the right approach. I find that amusing.

There should be no going into any jungle, and the jungle should not exist. It goes back to 'layers' all over again. That was a jungle if ever there was one. One had to hire this special Michael Douglas kind of character, a bit dodgy, a bit reckless to attempt to negotiate the jungle of layers.

Satellites. Satellites, are a good analogy. Sputnik. I would have my grid information in my project file, launched out as soon as possible and allow it to orbit. Allow everyone down in the jungle to look up at the orbit path, and know that Sputnik was passing over their heads. Take them out of the mentality of being in a jungle, where it is all about slashing and burning to try and get by. But the BIM guys seem to think it is all about jungle maintenance, and the COBie guys think it is all about building highways into the jungle. What we really need in all of this are Russians (circa 1950s).

[garethace]

We have geometry, and we have data. A lot of people believe, that we need both of those, and that we need more of the later. Geometry was always robust enough, that it could be allowed to float freely in space. Because as human beings, one of our capabilities is pattern recognition, and we know is less than seconds, how to pick up on something that is pattern related. The nature of our brains are such. But it's different with metadata, data about data. Computers are better there, and yes, by all means lets have a central database for that. But the mistake that BIM makes is trying to keep the geometry alongside the data. And then the COBie guys have to figure out how to run into the jungle the gather the data, distributed around inside that mass of geometry. It is pre-agricultural stuff.

I don't see geometry as geometry, I see geometry as data, intelligent, fluid and meaningful. It is important for people who only see geometry as geometry to change their way of thinking. What some do not seem to acknowledge, is what they refer as data, is not raw 'data' at all. It is only data about data. I'm all for keeping the 'metadata' that people refer to centralized. Software engineers do understand the possibilities inherent in being able to work on metadata in a central sand box. But equally, the software engineers do not seem to understand how geometry needs to operate.

I know that it is important to make geometry in the form of distributable objects, which are not central to any native application file. On the other hand, where metadata is concerned, the SPEED and efficiency comes from working in the one sand box. I learned a little about metadata recently, because I was able to work with some of the systems that cost planners and estimators use. Those cost estimation tools are all data about data, and all about single, native application files. They are quite cool actually, when one gets to know them. When one understands them a bit, it is amazing what they can do, without ANY geometry whatsoever, used only (meta-)data.

Yes, the trend nowadays is for cost control systems to be able 'to see' geometry. It the past they may have been accused of being deaf and blind as far as geometry was concerned. But the modern cost control systems, do assume that the geometry is remote from the application file. Cost control systems therefore, remain satellites themselves, and do not have to become huge standalone databases. They do amass a considerable amount of metadata, but they don't become overweight. The cost control and estimation databases, are like objects itself within the greater environment.

Why can't COBie be more like that?

BIM applications should have a capability of launching satellites into orbit on a regular basis. They should also have strong communications antennae, that is internal and allows them to receive back stuff in return. All BIM applications should constantly be sending things out, that become independent in themselves. The native file should only be data about data, and annotation as far as possible. Geometry should be out there doing its own thing. The case for having any proprietary geometric format, or combined geometric and metadata format in 2013, with the pretence that it leads to some efficiency is just not true.

[jakob_k]

Give us back layers that work, and we can deliver every scrap of information demanded by owners or governments, and then some. They will be astonished, amazed with the kind of data that will flow in their direction.

their amazement will be brief. then they'll be creative and have more (impossible) requests. :-)

karl