I wouldn’t say it’s bad advice; it depends heavily on the context of the work. In an environment where you have some combination of:
1) a tight feedback loop with the relevant stakeholder (ideally the individual(s) who are going to be using the end product),
2) the product itself is amenable to quick iteration (i.e. composed of many smaller features, ideally with a focus on the presentation),
3) the requirements aren’t clear (for example, the client has a mostly intuitive sense of how certain features should work; perhaps there are many implicit business rules that aren’t formally written down anywhere but will come up as obviously “oh, it’s missing the ability to do [x]” as the product gains capabilities)
...then avoiding significant investment in upfront design and adopting an iterative approach will very often save you spending a bunch of time designing something that doesn’t fit your stakeholder’s needs.
On the other hand, if you’re operating in an environment where those conditions don’t exist, such as one where you’re mostly working on features or products that aren’t easily broken down into smaller components that can be individually released or demoed to a stakeholder, and you have fairly clear requirements upfront that don’t often change (or you have access to a product manager who you work with to iterate on the requirements until they’re sufficiently well-detailed), then doing upfront design can often save you a lot of headache in wandering down dark alleys of “oops, we totally didn’t account for how we’d incorporate this niche but relatively predictable use-case, so we optimized our design in ways which makes it very difficult to add without redoing a lot of work”.
Having some experience with both, I’ll say that the second seems better, in the sense that there are fewer meetings and interruptions, and the work is both faster and more pleasant, since there’s less context-switching, conditional on the planning and product design being competent enough to come up with requirements that won’t change too often. The downsides when it goes wrong do seem larger (throwing away three months of work feels a lot worse than throwing away two weeks), but ultimately that degenerates into a question of mitigating tail risk vs optimizing for upside, and I have yet to lose three months of work (though I did manage to lose almost two consecutive months working at an agile shop prior to this, which was part of a broader pattern that motivated my departure). I would recommend side-stepping that by attempting to find a place that does the “planning” thing well; at that point whether the team you’re on is shipping small features every week or two or working on larger projects that span months is more a question of domain rather than effective strategy.
I wouldn’t say it’s bad advice; it depends heavily on the context of the work. In an environment where you have some combination of:
1) a tight feedback loop with the relevant stakeholder (ideally the individual(s) who are going to be using the end product),
2) the product itself is amenable to quick iteration (i.e. composed of many smaller features, ideally with a focus on the presentation),
3) the requirements aren’t clear (for example, the client has a mostly intuitive sense of how certain features should work; perhaps there are many implicit business rules that aren’t formally written down anywhere but will come up as obviously “oh, it’s missing the ability to do [x]” as the product gains capabilities)
...then avoiding significant investment in upfront design and adopting an iterative approach will very often save you spending a bunch of time designing something that doesn’t fit your stakeholder’s needs.
On the other hand, if you’re operating in an environment where those conditions don’t exist, such as one where you’re mostly working on features or products that aren’t easily broken down into smaller components that can be individually released or demoed to a stakeholder, and you have fairly clear requirements upfront that don’t often change (or you have access to a product manager who you work with to iterate on the requirements until they’re sufficiently well-detailed), then doing upfront design can often save you a lot of headache in wandering down dark alleys of “oops, we totally didn’t account for how we’d incorporate this niche but relatively predictable use-case, so we optimized our design in ways which makes it very difficult to add without redoing a lot of work”.
Having some experience with both, I’ll say that the second seems better, in the sense that there are fewer meetings and interruptions, and the work is both faster and more pleasant, since there’s less context-switching, conditional on the planning and product design being competent enough to come up with requirements that won’t change too often. The downsides when it goes wrong do seem larger (throwing away three months of work feels a lot worse than throwing away two weeks), but ultimately that degenerates into a question of mitigating tail risk vs optimizing for upside, and I have yet to lose three months of work (though I did manage to lose almost two consecutive months working at an agile shop prior to this, which was part of a broader pattern that motivated my departure). I would recommend side-stepping that by attempting to find a place that does the “planning” thing well; at that point whether the team you’re on is shipping small features every week or two or working on larger projects that span months is more a question of domain rather than effective strategy.