[choffstein]

Robert Martin (https://en.wikipedia.org/wiki/Robert_Cecil_Martin) once tweeted (@unclebobmartin):

"When designs are cheaper than builds, e.g. a skyscraper or a bridge, big up front design makes good sense. But when builds are cheaper than designs, e.g. software or oil painting, short and iterative design and build steps are best."

I couldn't agree with that more.

I work in an industry where builds are not cheap and iteration after launch is nearly impossible. You better believe we have a very, very long design cycle.

[scrumper]

This is why I like coming here. I'd never thought of the tradeoff in that way before reading that quote, yet it makes perfect sense.

(I'm not arguing with your point at all, but of course there's software... and then there's software. Building might be cheap for both, but cost of deployment could be entirely different. Spacecraft control, microcode in an appliance, even certain classes of enterprise software all benefit from big up-front design because it's so expensive to patch later.)

[IsaacL]

I would go further and argue that software is design.

I don't know that much about real-world engineering, but I imagine you can plan out a car, or a bridge, or a skyscraper, almost perfectly before you build it.

Wheras the only perfect design for a piece of software is the software itself. If you wrote pseudocode that was unambigious and covered every detail, it would simply be code.