Hacker News Reader

Comment by gopalv | Hacker News Reader

> 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.

View on HN

Good design as advocated by the author is generally conducive to change and is saying pretty much the same thing as you are.

It's a lot easier to take away unique constraints later on instead of adding them in. It's easier to de-normalize some data for performance than to normalize it later on. The list goes on.

The reason the waterfall method received so much bad press is because of requirements gathering, not the software or data design phases. Requirements are hard to get right the first time and they also change over time. But I'd be surprised to find someone argue that good architecture and design is a bad thing (being defined as the ability to adapt to changes in requirements).

> The reason the waterfall method received so much bad press is because of requirements gathering, not the software or data design phases.

No, it was because all three were done wrong.

Requirements gathering is the biggest problem, true. But even if requirements were both knowable and fixed, for most projects, big up front requirements gathering, design, and then implementation would have lots of waste in the lean sense of effort expended that spends time not delivering customer value.

Now, that gets made worse with the rework created by the fact that requirements gathering without validation by use gets lots of stuff wrong and that the context is often evolving such that requirements will drift between gathering, design, and implementation in a waterfall project, so that lots of work is done which never delivers value and needs reworked before it can do so, but the problem exists even without that exacerbation.

Well-thought design saves time even in agile projects. Maybe it's a one day activity instead of three months of it and yet it makes a difference. Basically each activity (or whatever we call it) is a micro waterfall.

Example from today: a developer came back from a week of vacation, listened to the stand up meeting this morning and pointed out that we misunderstood the purpose of a table he worked on time ago. Result: a few hours of last week's coding were useless and we spent a couple of hours together at redesigning the activity. The total impact should be of about one day.

> That is the very definition of a waterfall design model.

I think you're conflating two different things. I've spent the last two days thinking about the impact of adding five new tables to our database for a feature, two of them just lookups. I've thought about the short term benefits and the long term possible problems (for something that isn't even spec'd yet).

This isn't "waterfall" this is just getting a design about right for the current circumstances.

If during the design phase you're already asking "okay, this is good but how would I change it?" then you're already waterfalling your design.

Being thoughtful about your design up front (waterfall as your claim) hopefully solves many a problem down the line when you've suddenly got 5900M+ rows of data in the wrong shape in your production database; because a production database of that size doesn't take kindly to being "agiled" around.

When you need to add info to your database, do you refactor existing tables or do you add a key-value table.

I've seen so many key-value tables that really needed to be refactored into proper normalized tables.

It's just so tempting to stick extra info into KV when you don't know where the project will end up.

> "okay, this is good but how would I change it?"

Otherwise known as Reversible Decisions. Any decision that can be undone easily does not require the level of scrutiny, the level of investment. Save that investment for the things you won't be able to change.

When faced with an irreversible decision, it's helpful to develop stalling tactics. Everything from distracting people with other issues to finding a way to get a 'taste' of the change without committing to it. It also helps if you stay on top of release notes for tools you use, and competitors of those tools. New opportunities might arise to use someone else's work to solve your problem better.

Are you presuming that a 'well-thought [out] design' means that all the thoughts, and the design, came only at first? I can see a well-thought out design either as the waterfall you presume, or as an accretion of design decisions made over time as in your 'fluid design.' Either way can save many hours of coding, testing, troubleshooting.

> That is the very definition of a waterfall design model.

No it doesn't mean that. When you can rely on your data it's easies to code and test than when you have to account for every bad data combination.

And remove the constraint is easier when you need it, than to add it later.

Thanks for the feedback!

It's easier to safely loosen constraints than to add them post facto.

Agile needs design too. Agile does not mean you don't do any up front work or any design work, it just means you have agility to adapt to change as you progress. A well thought out design often helps you be more agile, not less.

Reply on news.ycombinator.com