[dkersten]

Sure, but:

> these claims mostly hold, but they break down when applied to distributed systems, parallel code, or complex interactions between software systems and human processes

The claims the GP quoted DON’T mostly hold, they’re just plain wrong. At least the last two, anyway.

[beyarkay]

Say more? I stand by my statement, but you're not specific enough for me to explain why I believe I'm correct.

[dkersten]

Focusing on the last two, which I called out specifically:

> Once a bug is fixed, it won’t come back again

Regressions are extremely common, which is why regression tests are so important. It is definitely not uncommon for bugs that were fixed once to come back again. This statement doesn't "mostly hold".

> If you give specifications beforehand, you can get software that meets those specifications

In theory, maybe, but in practice its messy. It depends on your acceptance testing. It depends on whether stakeholders change their mind during implementation (not uncommon). It depends on whether the specification was complete and nothing new is learned during development (almost never the case). Providing a specification in advance does not necessarily mean what you get out the other end meets that specification, unless its a relatively small, trivial, non-changing piece and the stakeholders have the discipline to not try change things part-way through. I mean, sure, it may be true that if you throw a spec over the wall, then you will get something thrown back that meets the spec, but the real world isn't so simple.