5 ms·

That's a fascinating article on the construction of the Empire State Building. Thanks for sharing it. However, what the article describes is fundamentally a wa

That's a fascinating article on the construction of the Empire State Building. Thanks for sharing it. However, what the article describes is fundamentally a waterfall methodology. The innovative part was breaking the large project into several overlapping stages of parallel projects, but the project management was still much more waterfall than agile. The waterfall methodology is not a product of "naive fantasies" but of business realities. In many cases changing the plan after you get started is phenomenally expensive. AN agile approach of building three stories and then deciding you want to try a different support structure or to add another sub-basement would be absurd. We all have a natural bias to assume that people in the past were foolish for not doing things the way we do, but for the most part, they were every bit as smart as we are and were making perfectly rational decisions. In terms of the pacemaker example, I've never built one myself, but I suspect that the constraints are not only the need for additional testing but that the functionality and hardware itself would require regulatory approval, and so a waterfall approach to the project might make a lot of sense. The developers could, of course, use an Agile or iterative approach to deliver on those requirements, but I think a waterfall approach might be a better fit for the overall project.

ealexhudson 8y ago
I don't believe the pacemaker example is necessarily a great one. In order to meet the risk-mitigation requirements for device approval, you have to document the design and the various decisions that led you to that point. If you're working in an agile fashion, you end up documenting a bunch of stuff that isn't in the product and doesn't get used, and at best your technical file is going to be much bigger than it needs to be (at worst, you confuse the assessor and don't get approval). That's not to say you can't use agile methods, but I think the sensible way would be to use agile to explore the solution space and learn what to build, but continue using a formal methodology in parallel construction to document the development of the device.
endymi0n 8y ago
Well, at least _some_ aspects of a 50k feet Waterfall are not avoidable in any construction project, as you can‘t redo parts of the foundation when you‘re building the 50th floor. Something that works quite in the same way (not as strongly, but still significantly so) in software by the way is re-modelling of the underlying entity schema. Which by the way is my favorite beef with process-driven agile methods and why I‘m leading my projects with an initial phase of data model and UX sessions until it‘s exactly clear _what_ needs to be built and _how_. Only then does it make sense to build any working code IMHO. Scrum and friends come with a complete disregard for distinguishing the stuff that‘s easy to change later on vs. the parts that are not.
- AstralStorm 8y ago
  You generally can change those things even in a building but it gets exponentially more expensive, and at some point such deep changes are better done by a full careful rewrite - building a second building.
- Scarblac 8y ago
  I think Agile's point was that even if you do all that work figuring out what to build first, it will STILL change later. There needs to be a mindset that everything is temporary, even the underlying entity schema, because it is. That doesn't work with huge software systems, which is why they mostly stop being developed and can only be somewhat maintained after some time.
  - marcosdumay 8y ago
    Things always change. This is unavoidable. You can either work to minimize the amount of change you'll have and identify the places where it's more likely, so you can add flexibility there, or you can be caught by surprise every time and pray that the next change won't suddenly throw years of work away. Both are perfectly sane attitudes on different contexts.
wpietri 8y ago
It is definitely not Waterfall. Waterfall's distinguishing characteristic is that the total plan is known before any material action happens. For the Empire State Building example, that emphatically isn't true. And that's one of the parts that is fantasy: total knowability. Bosses want that so they can indulge another fantasy: complete control. Perfect plan, perfect, obedience, perfect outcome. > I've never built one myself, but I suspect that the constraints Right. Note that here you are indulging in fantasy, in the face of me pointing to expert practitioners saying otherwise. This too is a characteristic of the adoption of waterfall. As the original article says, the paper that defined it said it was a naive, bad idea. But that stopped nothing. People ignored that and made it a template, ignoring the experts.

ealexhudson 8y ago

I don't believe the pacemaker example is necessarily a great one. In order to meet the risk-mitigation requirements for device approval, you have to document the design and the various decisions that led you to that point. If you're working in an agile fashion, you end up documenting a bunch of stuff that isn't in the product and doesn't get used, and at best your technical file is going to be much bigger than it needs to be (at worst, you confuse the assessor and don't get approval). That's not to say you can't use agile methods, but I think the sensible way would be to use agile to explore the solution space and learn what to build, but continue using a formal methodology in parallel construction to document the development of the device.

endymi0n 8y ago

Well, at least _some_ aspects of a 50k feet Waterfall are not avoidable in any construction project, as you can‘t redo parts of the foundation when you‘re building the 50th floor. Something that works quite in the same way (not as strongly, but still significantly so) in software by the way is re-modelling of the underlying entity schema. Which by the way is my favorite beef with process-driven agile methods and why I‘m leading my projects with an initial phase of data model and UX sessions until it‘s exactly clear _what_ needs to be built and _how_. Only then does it make sense to build any working code IMHO. Scrum and friends come with a complete disregard for distinguishing the stuff that‘s easy to change later on vs. the parts that are not.

AstralStorm 8y ago
You generally can change those things even in a building but it gets exponentially more expensive, and at some point such deep changes are better done by a full careful rewrite - building a second building.
Scarblac 8y ago
I think Agile's point was that even if you do all that work figuring out what to build first, it will STILL change later. There needs to be a mindset that everything is temporary, even the underlying entity schema, because it is. That doesn't work with huge software systems, which is why they mostly stop being developed and can only be somewhat maintained after some time.
- marcosdumay 8y ago
  Things always change. This is unavoidable. You can either work to minimize the amount of change you'll have and identify the places where it's more likely, so you can add flexibility there, or you can be caught by surprise every time and pray that the next change won't suddenly throw years of work away. Both are perfectly sane attitudes on different contexts.

wpietri 8y ago

It is definitely not Waterfall. Waterfall's distinguishing characteristic is that the total plan is known before any material action happens. For the Empire State Building example, that emphatically isn't true. And that's one of the parts that is fantasy: total knowability. Bosses want that so they can indulge another fantasy: complete control. Perfect plan, perfect, obedience, perfect outcome. > I've never built one myself, but I suspect that the constraints Right. Note that here you are indulging in fantasy, in the face of me pointing to expert practitioners saying otherwise. This too is a characteristic of the adoption of waterfall. As the original article says, the paper that defined it said it was a naive, bad idea. But that stopped nothing. People ignored that and made it a template, ignoring the experts.