About software development "metaphors"

As a software developer, it is inevitable to get involved in software process management, both managers and implementers are process participants. When we want to explain what software development is about to a layman, we usually use an analogy such as building a house. This is a "metaphor". When we encounter problems at work, how can we deeply and correctly understand and understand our software In the work itself, you subconsciously think that development should be like this, but what you actually do does not meet your expectations, and this is the source of pain.

There is an article "Software development cannot be compared to architecture" to illustrate an inappropriate software development metaphor. Worth thinking about.
This is somewhat similar to the Agile Manifesto.

The architectural metaphors that are often used to describe software are wrong. Sadly, with this layer of insinuation, we put a lot of emphasis in the wrong place:
strive to predefine requirements, not accept: change is the norm;
emphasize the importance of architecture and architects, not acceptance : software is adaptable and can be changed by anyone on the team;
assumes people are replaceable and timing issues can be solved by adding people, not accept: everyone is unique;
pursue predictability, while Not acceptance: our field is not well understood.

Software has nothing to do with architecture!
We're not building, we're exploring!


Manifesto for Agile Development:
Individuals and interactions over processes and tools;
working software over comprehensive documentation;
customer collaboration over contracts;
responding to change over following plans