undefined | Better HN

0 pointshbrn3y ago0 comments

> you are doing a bad job of producing an up-front system design

Or, it could be that you're actually innovating and requirements are changing faster than you write code.

A late change in requirements is a competitive advantage.

There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.

0 comments

7 comments · 3 top-level

marcosdumay3y ago· 2 in thread

I have nothing against undescriptive product names. But if you are constantly changing the entire problem your software is intended to solve, you have a problem.

And if you just happen to change it eventually, it's best for everybody if you go and make it a different project with a different name. Descriptive or not.

__t__3y ago

Commercial software is mostly to solve real world problems. Real world problems can change very quickly and as such, software changes too.

Sure constantly changing in the complete opposite direction is probably a sign of something wrong, but changes are inevitable and we can’t expect to reinvent the wheel or start a new project as you say when you can potentially reuse what you already have.

marcosdumay3y ago

> Real world problems can change very quickly and as such, software changes too.

So you keep the old product, and make a new one for solving the new problem. (You can even sell them on the same package.)

The alternative will have almost all of your customers badmouthing you because they brought your product, and you pulled the functionality out of their feet.

1 more reply

mindcrime3y ago· 1 in thread

There definitely are systems where BDUF is a valid approach. But at the same time there are systems where making mistakes is the best way to learn. Emergent design is a thing.

This strikes me as a false dichotomy. The choices aren't limited to "BDUF" OR "NDUF" (No Design Up Front). There's a continuum along which the amount of up-front design that is required can range. I prefer the term SDUF (Sufficient Design Up Front). And of course we all have to keep in mind that design and architecture aren't things that only happen "up front". Design and architecture work-streams should continue throughout the lifecycle of the project, IMO. The relative weighting of the different work-streams can vary, but the key is that it doesn't just end after the first (iteration|sprint|phase|whatever-you-call-it).

bcrosby953y ago

SDUF and redesign as necessary is where my job mostly falls. If we're facing an unreasonable deadline, "redesign as necessary" can turn into "just hack it in" though, which is what I'm currently dealing with.

FWIW most of our deadlines are reasonable.

sidlls3y ago· 1 in thread

It’s not “innovative” to double-down on mistakes.

hbrnOP3y ago

Not necessarily, but could be.

Have you heard of brainstorming? The worst thing you could do is to ban mistakes.

Innovation is doing something that hasn't been done before. Inevitably that leads to mistakes.

Being sloppy also leads to mistakes.

Presence of mistakes doesn't tell you much. But lack of them tells a lot.

If all your experiments are successful, it doesn't mean you're a genius. It means you're experimenting too slow.

j / k navigate · click thread line to collapse