I've always sort of disliked that one, because there are very good reasons that it is difficult for programmers to write programs the way builders/engineers build physical infrastructure.
However, there are not any good reasons to avoid improving your process and output iteratively via feedback.
I always took it as the general way we throw piles of stuff on top of other stuff until eventually it's so unstable a woodpecker would knock it all over rather than as an accurate indictment of software practices which are of course different to building, software is part science, part art and part prayer.
>> write programs the way builders/engineers build physical infrastructure
> Mostly we just haven't been doing it as long.
This is a popular analogy (among non-programmers) but I have more recently been countering it like this:
It's generally predictable how long it will take to build a house, because many have been built, and they're all more or less the same. Sure they have different layouts, number of windows, etc, but essentially it's the same materials, same tools, and same methods.
Most programs written are not similar in the same way two houses are similar. They are more comparable to the way a house is different from an airport terminal, or a water treatment plant is different from a golf course.
Once you've built many different types of programs, you get a bit better at estimating, but each new type of program poses brand new challenges. A builder used to building small houses from wood is going to be pretty bad at estimating how long it will take to build a missile silo from concrete, and even after building both, will still not be able to come up with a very good estimate for the time to build a railway line between two cities.
Also keep in mind that typically, programmers don't build the same (or even similar) program more than once: unlike builders, we have copy+paste.
However, there are not any good reasons to avoid improving your process and output iteratively via feedback.