Confusing Abstract and Concrete makes it hard to figure out things

I had conversation with a mechanical engineer from the East Coast who worked for years on buildings.  I am an industrial engineer from the West Coast who worked for years on software.  We were chatting about some things I am working on and he was providing feedback.  The conversation was good in that it got me thinking about how different people will look at the same situation, identify different problems, and then take different actions.

This took me down the path of thinking of Abstract vs. Concrete.

The abstract/concrete distinction has a curious status in contemporary philosophy. It is widely agreed that the distinction is of fundamental importance. And yet there is no standard account of how it should be drawn.

Reflecting I can think of so many conversations that confused people because i was explaining abstract ideas and the listener was hearing concrete things.  Part of working on software is you get used to working in abstract, and then shift phases to the concrete when need be.  Part of the challenge of user interfaces is some users favor abstraction others favor concretism.

Going back to the conversation I realized that the user interface we created favors a concretism user, the use of the system by analyst, managers, engineers, and others who consume the data are people who can think in the abstract and understand the value of concrete.

Ironically part of what we were discussing is the process tracking in the pouring of concrete.  Now, I am more confused.  The abstraction of processes to pour concrete vs. the concretism of the concrete pour.