OPEN VCS, a lens for looking at models

Has anyone measured the participation rate in the Architecture, Engineering, and Construction (AEC) industry, in discourse about, or sustained interest in, the topic of software?

Looking back over my career since the mid 90s, it seems to me generally that those who maintain an interest in software are a subgroup who keep talking with each other year after year, decade after decade while trying our best to downplay the fact that most people, both during design (A and E) and construction (C), are not interested. 

And we put quite a lot of effort, conscious or unconscious, into suppressing ourselves from asking why.

Most people who’ve reached an adequate level of experience and competence in A or E or C are motivated by the higher order thinking that’s necessarily involved in the work associated with their professions. 

And they know that doing that work requires dedication to building up their experience doing that work. So they do that. And they’re attracted to that, to the higher order work.

Those on the other hand who are attracted to software and its development and use sometimes split their interest between software and the higher order work involved in A, E, and C. Splitters are very rare though because both are full time jobs. And people have limits. 

Here’s the bitter pill to swallow.

Mostly, those who sustain an interest in software have sacrificed the effort needed to maintain competence in the higher order work of their profession(s).

Many don’t even know what that work is. Having never attained what’s needed to practice it, they don’t know it so they don’t see it. They don’t recognize it even when it’s right in front of them. 

Software enthusiasts are occupied with solving problems related to software. They took a fork in the road, to software, too early. So they walked not far enough down the other road to know where it leads.

We’re on different roads. Those who took the path to higher order professional work, don’t talk about it.

With us.

They talk about it with each other, but not with us. It’s why we never hear from them. They know we won’t understand anyway and that we won’t care. And they lack the time. The stuff we do is a distraction from cultivating what it takes to do the work of their profession.

Rarely, when they do try to tell us that, we ignore it. Because, well, we’ve gone down this other path and, well, our path cannot be wasted effort? 

Can it?

We can easily avoid thinking about that.

Really.

It’s very easy.

We have a menu of things to choose from, any of which will make us feel better. Sort of. Things we can devote to that make us feel there’s a goal that makes the effort worth it.

Here’s a partial list in no particular order:

• Industry unification on a dominant software vendor and set of products (now passé)
• Industry de-unification via open data standards
• Data classification standardization
• software and process terminology definition debates and standardization
• AEC work conceived of as ‘data’ diffusion in, and as, gaseous nebulae, vapor clouds of ‘data’ in motion
  • While ‘literally’ ‘true’, like many things that are literally true, this, need not be the focus of forthcoming decades of software development —- nor can it be relevant to practitioners, who operate on a completely different plane of perception, thought, and action —- particularly in the increasing absence of anything in that vapor nebula that provides, or can provide, anything tangibly solid to grasp onto.
• ‘AI’

Some of these are valuable in their own right and do contribute to AEC work, like open software. One need not make absolutist evaluations of such things.

But among the things we generally don’t talk about are:

• the degree to which these contribute to AEC outcomes
• the degree to which some of these are done anyway without software (like item classification, and whatever ‘AI’ does when useful)
• the degree to which interest in these are confined to specialist groups who’ve detached themselves from the professions as we’re drawn down the software road instead.
• how much space (cognitive bandwidth) and budget they’re taking up measured against the value of their project contributions.

Maybe you’re starting to recognize something, some light shines on why we’re a minority, why most AEC professionals have little interest in things that fork them onto roads drawing them away from their work and instead into an endless slog through a morass.

Are you slogging through it and still curious what’s down the other road that leads toward the higher order work of AEC?

What is the higher order work that’s involved in A, E, and C?

I’m hardly qualified to say and won’t presume I can put my finger on it. But I’ve noticed a few things. I was on that road for 12 years before I jumped off into software. 17 years if you count my education. I saw some things and remember some of those.

The most general statement I can make that’s still meaningful, about those who went that way, is:

They’re thinking about the project.

They think about it all the time.

We need to be more specific though. What does it mean to think about the project?

To avoid getting lost in the weeds describing every detail in the Homeric sense, I’ll just hit the highlights. 5 highlights, 0, 1, 2, 3, 4, interrelated.

(0) Initiation

First, there is some reason to work on a project. Some client for some reason needs something. By some manner you end up engaged in the project at their service and you listen to them. This initiates a long term conversation that becomes one of the inputs into the higher order thinking that generates the actions that generate the project outcome.

Let’s call everything in the paragraph above that initiates, step (0). Initiation.

A mental model of the project then starts to form, starts to take shape. Initially. It’s sketchy, fuzzy, fluid. A mist, really. The fog lifts though. The sun comes out and makes things clearer. 

It’s iterative.

And sometimes a model that’s becoming clear then gets shrouded again in fog, maybe because that model should dissipate to make way for better ideas, for better things to become clear.

We all might reflect on the function of technical drawings here, a function inseparable from models mental and digital. The function is multifold:

(1) Visual Close Study (VCS) of models

Any single technical drawing is an expression of the act of looking somewhere specific within a model mental, digital, or physical.

A drawing is the act of visual close study (VCS), there, at that location, and the articulate expression of this close study.

(2) Physical evaluation

There at that location, we evaluate, is everything that should be shown THERE actually shown there? Is anything that matters THERE missing?

Again, I am not trying to describe in meticulous detail everything involved in higher order AEC work. I’m just trying to draw some highlights. The main idea hinted at, here in step (2) has to do with evaluation. But it’s evaluation of a particular kind and not other kinds.

The evaluation is not primarily about (it is there, but it’s not primary) classification, nor conformance with classification standards.

The evaluation in step (2) is primarily about physicality. 

It’s about putting things together, about assembling an assemblage. It’s a check against omission of physical things. It’s a check on how complex physical systems are actually fit together, and how we affirm (step 3, below) their quality in terms of whether or not any of the physical pieces necessary are missing, and whether or not all the pieces that are present fit together well, or not. 

Fitting, good fit, good form, involves many kinds of sub-evaluations, like:

economy, firmness, and delight

(Vitruvius)

Is it fit for purpose, including ‘doing the job’ and meeting the budget? 

Is it durable, stable, reliable?

Does it stir something in us?

(3) Affirmation

Finally at some point after the long work of model development and review, someone with authority (experience, knowledge) to do so, AFFIRMS the status of the questions in (2).

(4) INTERPLAY: the engine of thought

Along the way (0, 1, 2, 3…) an INTERPLAY is engaged, in our minds, between:

• a set of expressions of visual close study (VCS) at various locations of narrowed attentive visual focus within a model 
  
  and
• the wider expanse of the whole of the modeled project environment.

The interplay is a back and forth continuous dynamic and there is good argument that this, the interplay, is the basic observable dynamic of thought itself, that the wide/narrow (environment/focus) interplay is the machine of thinking at work, the engine of thought.

In the interplay, thought happens and understanding grows. 

Fuzzy initial ideas are sorted and judged. Selected stronger concepts are thought through, clarified along the way, and ultimately, thought through all the way through so they can be carried to fruition.

0, 1, 2, 3, and 4 are the higher order work of AEC professions.

Those of us who took the fork in the road into software might have a happier life if we build our road closer to theirs.

And we can take it there.

There’s that old saying, 

Traveler, there is no road. The road is made along the way.

If you don’t believe that, listen to this and see if you do:

Written by: Antonio Machado / Joan Manuel Serrat

Survivorship bias

During World War II, the statistician Abraham Wald took survivorship bias into his calculations when considering how to minimize bomber losses to enemy fire.^[19] The Statistical Research Group (SRG) at Columbia University, which Wald was a part of, examined the damage done to aircraft that had returned from missions and recommended adding armor to the areas that showed the least damage.^[20][21][22]The bullet holes in the returning aircraft represented areas where a bomber could take damage and still fly well enough to return safely to base. Therefore, Wald proposed that the Navy reinforce areas where the returning aircraft were unscathed,^[19]: 88inferring that planes hit in those areas were the ones most likely to be lost. His work is considered seminal in the then nascent discipline of operational research.^[23]

https://en.wikipedia.org/wiki/Survivorship_bias

Is this what we’re doing too?

Maybe the planes that don’t come back are the AEC professionals who are engaged in the higher order work (0, 1, 2, 3, and 4) who don’t talk to us. Maybe we’re just talking to ourselves and putting armor over the holes only we have taken, ignoring all the other planes, the ones we don’t see and don’t hear from.

Maybe there are very good reasons why still 20 years later (or almost 40 years depending on where you start to count from), digital models in AEC remain underutilized, and show enough gaps in utility to belie our limitless rhetoric.

We use all kinds of techniques typical in the masking of facts and avoidance of critical thought. We double down with stubborn adherence to slogans that lack any load-bearing thought supporting them. We resort to cliques and in-group behavior. And even to governmental mandates. All without anything close to the sort of self reflection that’s due.

We can continue this way, keep doing the same things and expecting different results, or we can start walking a path closer to the higher order work of AEC.

I listed the work tasks 1, 2, 3, and 4 in shorter form here:

Why evolve equipment for visual close study (VCS)? Pragmatic reasons

But so what?

Well, so:

software development can bend the path it walks, to get software better engaged with the higher order work of AEC professionals

Here is a development proposal for doing that:

Visual Engagement with Modeled Worlds

The TGN proposal engages steps 1, 2, 3, and 4 (above) directly, and does so inside the digital model.

This will elevate digital model utility, raising the model into the higher order work. This should increase model utilization as many of those planes ✈️ we never saw before, return and we find them well and truly engaged in their core work, thinking about the project (1, 2, 3, 4).

We are developing the new lens for looking at models, open source, equipment for visual close study (VCS) of models, for implementation in all modeling apps, platforms, and formats.

If this doesn’t resonate with you, yet, there might be a very good reason for that. You’ve been talking to the wrong people for too long and your entire discourse has become self-referential and stale.

Message me if you want to participate, help develop, implement, or use TGN OPEN CODE in your preferred modeling app, platform, or format.