[groestl]

Software that is used, changes, because successful software influences the world around it, which in turn changes it's requirements. So typically, even if a team gets it right the first time (which by itself requires enormous effort), the once perfectly specified requirements will have changed shortly after release.

Edit: sibling is right as well, it depends on what you're building. Sometimes there is nothing better than waterfall.

[edejong]

> Software that is used, changes,

Yes, but... A good model can support larger changes than a bad model. For example, a well designed relational model can support iterative change better than a slapped together system using CSV. So does a system that supports a consistent mental model for the end-user.

This is the fundamental skill: abstraction. To find the right abstractions, sustaining simplicity while opening up ability to change is an extremely difficult and hard-fought skill.

Unfortunately, due to a constant influx of new developers, its value is underappreciated. Requirements for this skill are (non-exhaustive): excellent communicative abilities, combined with a predilection for logic reasoning, good technical understanding, some psychological understanding and perseverance for when a model proves unsuccesful.

From my experience, the best systems we have designed and implemented started with long sessions at the white-board, often followed by some tech 'spikes' [1].

[1] https://en.wikipedia.org/wiki/Spike_(software_development)

[thedancollins]

Survivorship bias/fooled by randomness. If a system can be abstracted to a model that can account for the bizarre stuff that the business throws at it, then the domain you are operating in is either Simple or slightly Complicated (as defined by the Cynefin framework). The real problem lies in Complex/Chaotic.

[gt2]

Beautifully said. Anyone can understand this when it's put this way.