So I just had an experience of being forced into "vertical slice" development (not quite the same as architecture, but still). This seemed initially as crazy as erecting a multi-story building in vertical slices. But it turned out to have some advantages, and I might do it again by choice.
At the risk of stating the obvious, at the end of the day, it's the use cases and user stories that matter, and in my experience, these almost always evolve over the life of a project. Designing from the ground up often ends up supporting potential requirements that never become real. As the project grows and matures, it becomes hard to trace whether some capability in a lower layer is critical or unneeded, so the tendency is to keep everything. This can become an albatross.
The virtue of vertical development, is that it's easier to do all the work and only the work that is required.
Theoretically, the flip side is that it's easy to avoid thinking up front about the big picture, and easy to promote stove-piping with all of its disadvantages.
My guess is that either the traditional or the vertical approach involves eventual refactoring, and that the first leads to bloat in unused capability while the second leads to bloat in duplicated capability. But the bloat comes later in the project with the vertical approach. In the early phases of a project, the vertical approach may lead to leaner, more malleable systems, with faster delivery and user interaction.
Bottom line for me, is that vertical development didn't fail (I thought it would), and had some surprising benefits.
At the risk of stating the obvious, at the end of the day, it's the use cases and user stories that matter, and in my experience, these almost always evolve over the life of a project. Designing from the ground up often ends up supporting potential requirements that never become real. As the project grows and matures, it becomes hard to trace whether some capability in a lower layer is critical or unneeded, so the tendency is to keep everything. This can become an albatross.
The virtue of vertical development, is that it's easier to do all the work and only the work that is required.
Theoretically, the flip side is that it's easy to avoid thinking up front about the big picture, and easy to promote stove-piping with all of its disadvantages.
My guess is that either the traditional or the vertical approach involves eventual refactoring, and that the first leads to bloat in unused capability while the second leads to bloat in duplicated capability. But the bloat comes later in the project with the vertical approach. In the early phases of a project, the vertical approach may lead to leaner, more malleable systems, with faster delivery and user interaction.
Bottom line for me, is that vertical development didn't fail (I thought it would), and had some surprising benefits.