Sorry to have to say it, but this is bullshit. The problem of dividing a problem is in software, often almost as complex as the original problem! You can see the problem with teams applying the agile process, implementing user stories, and keeping accumulating technical debt. Yes, users or product managers have it easy dividing their specifications in "user stories", but software is not architectured following those lines.
I agree that software from a user-facing model is not divided up the same way as its internal structure, but at some point, you have to think about how a user story maps onto the structure of your software, and I think it can be valuable to think about this ahead of time rather than seeing what needs to happen while you're writing the code.
Not advocating for a waterfall model here, but I sometimes wonder whether we've thrown out the baby with the bath water by ditching all up-front design.
Sorry to have to say it, but this is bullshit. The problem of dividing a problem is in software, often almost as complex as the original problem! You can see the problem with teams applying the agile process, implementing user stories, and keeping accumulating technical debt. Yes, users or product managers have it easy dividing their specifications in "user stories", but software is not architectured following those lines.
I agree that software from a user-facing model is not divided up the same way as its internal structure, but at some point, you have to think about how a user story maps onto the structure of your software, and I think it can be valuable to think about this ahead of time rather than seeing what needs to happen while you're writing the code.
Not advocating for a waterfall model here, but I sometimes wonder whether we've thrown out the baby with the bath water by ditching all up-front design.
Ditching all up-front design is dumb. Not sure where you're getting that from.