> A well-thought design can save us many hours of coding, testing, and troubleshooting.
That is the very definition of a waterfall design model.
I've turned into a fluid-design advocate over the years, where every design principle follows a next question - "okay, this is good but how would I change it?".
So you start with a unique constraint and four months later, you find out that it is not actually unique (like "two patients with the same email, because the 2nd one is a newborn on day of birth").
Or you normalize a data-set only to find out that your 1:N relationship turns into a 2:N relationship from before/after dates (like "UK" goes from "EU" to "UK").
The lost-time work of a design is usually the "okay, we did it in a world where UK was in EU - but we undo it & here's how" notes.
Having a plan to decommission the nuclear plant you're building is super useful and often more relevant than designing it for efficiency alone.
That is the very definition of a waterfall design model.
I've turned into a fluid-design advocate over the years, where every design principle follows a next question - "okay, this is good but how would I change it?".
So you start with a unique constraint and four months later, you find out that it is not actually unique (like "two patients with the same email, because the 2nd one is a newborn on day of birth").
Or you normalize a data-set only to find out that your 1:N relationship turns into a 2:N relationship from before/after dates (like "UK" goes from "EU" to "UK").
The lost-time work of a design is usually the "okay, we did it in a world where UK was in EU - but we undo it & here's how" notes.
Having a plan to decommission the nuclear plant you're building is super useful and often more relevant than designing it for efficiency alone.