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