4 ms·

I'm very curious, what is your definition of waterfall?

kuschku 11y ago
The classical definition: 1. You research the actual requirements, including by testing some possible alternatives via mockups, etc. 2. You design the concept of your system, design APIs and interfaces. 3. You implement it. 4. You verify it matches the design and fulfills the requirements 5. You release it and maintain it. Most importantly, after Step 2 your APIs don’t change anymore. This is especially important as third parties might rely on them.
- matthewmacleod 11y ago
  I appreciate that's the definition, but the problem that agile tries to deal with is that this almost never happens as you describe in practice. In reality: 1. You research the actual requirements 2. You design the concept of your system, design APIs and interfaces. 3. You implement it. 4. You discover that the requirements are unimplementable because of some unforeseen design issue 5. You make changes to your implementation, documentation and requirements to deal with this 6. You discover that documentation regarding a third-party system is inaccurate and requires design changes 7. You make changes to your implementation, documentation and requirements to deal with this 8. You verify it matches the design 9. You discover previously unknown acceptance requirements 10. You make changes to your implementation… and so on. ??. You release it and maintain it Even with skilled, competent developers and architects, no system ever turns out exactly as expected. The goal of agile development is to accept that and try to incorporate the concept of continuous delivery and adaptation into the core of the process – since it's required anyway!
  - kuschku 11y ago
    And now imagine a big company develops a software interacting with yours at point 2, and finishes it at point 5. You’ll have to add backwards compatible wrappers that emulate an older API in 7 and later. Or you can actually test with proof-of-concepts, with mockups, with other tests, before you even write the design.
    - matthewmacleod 11y ago
      I think you missed my point there – I'm not describing an ideal agile process. It doesn't matter how many proof-of-concepts, mockups, tests and design documents you produce in advance. Change still happens.
- jdbernard 11y ago
  Matthew already highlighted the concerns. So, hypothetically, what happens when just after you finish step 3 it is found that one of the core security mechanisms that the security of your life-critical product depends on and that was part of your published API is suddenly found to be insecure due to some new breakthrough in a research lab somewhere? Do you throw it all away and start over from step 1? Or what happens when, again at step 3, you discover that one of he approaches advocated by the design, and tested by the mockup in the small is unacceptably non-performant when scaled to the real load? Or some other constraint that was not fully tested by the mockups? You can't say "well, we do a better job with the mockups." If the mockups covered 100% of the functionality and requirements of he system they wouldn't be mockups, they would be the product. And if your answer is, "well we do this kind of discovery in the testing and mockup phase, changing the mockups to reflect the issues we encounter," congratulations, you are doing Agile development.
  - kuschku 11y ago
    Okay, then let’s think about it. You write your software, you deliver it, you discover that your software, running in pacemakers, is insecure. What do you do? How do you send out security updates? How do you expect to be able to constantly update that software with agile? There are many cases where updates are literally impossible.
    - matthewmacleod 11y ago
      I'm not sure how a 'waterfall'-style development lifecycle will help you here. Even if you front load all of your design, documentation and implementation, you will still find bugs and security flaws in your software. As an example, see every software product ever shipped! I think you're maybe labouring under a misapprehension of what agile development means. In particular, you don't have to 'constantly update' deployed software in order to be able to develop in an agile fashion. You're free to follow the guiding principles to make sure you are able to cope with changes when they inevitably happen.

The classical definition: 1. You research the actual requirements, including by testing some possible alternatives via mockups, etc. 2. You design the concept of your system, design APIs and interfaces. 3. You implement it. 4. You verify it matches the design and fulfills the requirements 5. You release it and maintain it. Most importantly, after Step 2 your APIs don’t change anymore. This is especially important as third parties might rely on them.

matthewmacleod 11y ago
I appreciate that's the definition, but the problem that agile tries to deal with is that this almost never happens as you describe in practice. In reality: 1. You research the actual requirements 2. You design the concept of your system, design APIs and interfaces. 3. You implement it. 4. You discover that the requirements are unimplementable because of some unforeseen design issue 5. You make changes to your implementation, documentation and requirements to deal with this 6. You discover that documentation regarding a third-party system is inaccurate and requires design changes 7. You make changes to your implementation, documentation and requirements to deal with this 8. You verify it matches the design 9. You discover previously unknown acceptance requirements 10. You make changes to your implementation… and so on. ??. You release it and maintain it Even with skilled, competent developers and architects, no system ever turns out exactly as expected. The goal of agile development is to accept that and try to incorporate the concept of continuous delivery and adaptation into the core of the process – since it's required anyway!
- kuschku 11y ago
  And now imagine a big company develops a software interacting with yours at point 2, and finishes it at point 5. You’ll have to add backwards compatible wrappers that emulate an older API in 7 and later. Or you can actually test with proof-of-concepts, with mockups, with other tests, before you even write the design.
  - matthewmacleod 11y ago
    I think you missed my point there – I'm not describing an ideal agile process. It doesn't matter how many proof-of-concepts, mockups, tests and design documents you produce in advance. Change still happens.
jdbernard 11y ago
Matthew already highlighted the concerns. So, hypothetically, what happens when just after you finish step 3 it is found that one of the core security mechanisms that the security of your life-critical product depends on and that was part of your published API is suddenly found to be insecure due to some new breakthrough in a research lab somewhere? Do you throw it all away and start over from step 1? Or what happens when, again at step 3, you discover that one of he approaches advocated by the design, and tested by the mockup in the small is unacceptably non-performant when scaled to the real load? Or some other constraint that was not fully tested by the mockups? You can't say "well, we do a better job with the mockups." If the mockups covered 100% of the functionality and requirements of he system they wouldn't be mockups, they would be the product. And if your answer is, "well we do this kind of discovery in the testing and mockup phase, changing the mockups to reflect the issues we encounter," congratulations, you are doing Agile development.
- kuschku 11y ago
  Okay, then let’s think about it. You write your software, you deliver it, you discover that your software, running in pacemakers, is insecure. What do you do? How do you send out security updates? How do you expect to be able to constantly update that software with agile? There are many cases where updates are literally impossible.
  - matthewmacleod 11y ago
    I'm not sure how a 'waterfall'-style development lifecycle will help you here. Even if you front load all of your design, documentation and implementation, you will still find bugs and security flaws in your software. As an example, see every software product ever shipped! I think you're maybe labouring under a misapprehension of what agile development means. In particular, you don't have to 'constantly update' deployed software in order to be able to develop in an agile fashion. You're free to follow the guiding principles to make sure you are able to cope with changes when they inevitably happen.