97

Software architecture, at least in some circles, does not have the best reputation. When I introduce myself in a work context and feel particularly snarky, I say that I was recently demoted to software architect. Whether these vibes have merit is a whole different question, undeniably the field of software development draws heavily from metaphors from the physical world.

We build software, the result of which, if not broken, is shipped as a container, data flows through pipes, things we can share are put into libraries, objects are created in factories (which themselves might be created in factory factories ad infinitum), we have adapters, facades and bridges, we decorate objects. These examples are far from exhaustive.

Metaphors aren't true or false, they are useful or not. They can be useful if they help to make the arcane craft comprehensible to those who had better things to do with their life. They can be the opposite if an image is overstreched and becomes a leaky abstraction (yet another physical metaphor).

Uwe Friedrichsen for example elaborates on how the metaphor of assembly lines leads to The industrialization of IT fallacy. Or consider technical debt: the idea has ddifferent undertones to different people. The technical folks who came up with it quite certainly came from the mindset where debt is something you generally avoid (or at most take on for extraordinary important things in your life like education or buying a home). Now talk about debt to MBA and finance types: to them other people's capital represents leverage, and risk that is externalized, so naturally they think it is a good thing and want as much of it as they can get.

Either way, it is necessary for a practitioner to stay reflective and conscientious of the use of language.