In his book “Code Complete”, Steven McConnel speaks about metaphors. He reasons that metaphors are necessary to be a good developer as it helps visualize the act of coding. The metaphor he prefers is the “construction” metaphor. This metaphor he argues best explain the act (some would say art) of programming and gives developers a language to speak in that brings clarity to the development process.
When in construction you prepare the building site, lay a foundation, frame the house, put siding and a roof on it, and plumb and wire it. This is equivalent to programming. In other words through the lens of the construction metaphor, the developer is someone who ultimately build someones house by working together with different disciplines (Architects, designers, contractors etc)
The problem with that metaphor IMO is that it's not actually what software development is.
The proper metaphor for software development is more "engineering and development of construction site equipment and material" i.e. a developer is not building buildings they are building the things necessary for building the building.
And so the developer will often find themselves in a situation where the material doesn't exist and they have to invent it it or the material exist but we dont know how it's going to work with some other material needed or the equipment used for that material isn't made yet or doesn't work with that material even though it normally does.
I.e. a developer is inventing, engineering and building all at the same time and that is what makes it impossible to estimate development regardless of process or metaphor.
The reality is that software development is nothing like engineering or construction, it's totally different. You don't build a quick house, let people live in it and start building the walls whilst they live there.
Humans like to think via metaphor because it's a least-effort mode of thought but sometimes there just isn't one and it's just tough luck and start thinking from first principles instead.
My point was more that the software developer have to not just build with existing material and equipment but have to invent and build those on the fly.
"building with material" implies that material cannot be reused, but code can be copied for effectively zero cost, so it isn't like building, so the comparison to inventing and build equipment on the fly doesn't work.
I think we humans find it hard to accept when something is completely new, when there's no analogy for it, because that's how our brains like to think. But software is just _different_ and it's better to give up on analogy than be misled by it.
When in construction you prepare the building site, lay a foundation, frame the house, put siding and a roof on it, and plumb and wire it. This is equivalent to programming. In other words through the lens of the construction metaphor, the developer is someone who ultimately build someones house by working together with different disciplines (Architects, designers, contractors etc)
The problem with that metaphor IMO is that it's not actually what software development is.
The proper metaphor for software development is more "engineering and development of construction site equipment and material" i.e. a developer is not building buildings they are building the things necessary for building the building.
And so the developer will often find themselves in a situation where the material doesn't exist and they have to invent it it or the material exist but we dont know how it's going to work with some other material needed or the equipment used for that material isn't made yet or doesn't work with that material even though it normally does.
I.e. a developer is inventing, engineering and building all at the same time and that is what makes it impossible to estimate development regardless of process or metaphor.