4 ms·

These statements from the agile manifesto are directly opposite to any kind of quality software No they are not. These statements are guidelines and principles

These statements from the agile manifesto are directly opposite to any kind of quality software No they are not. These statements are guidelines and principles to follow, and are not absolutes. If the requirements (i.e. acceptance criteria) for features you are working on include comprehensive documentation, then this can be delivered in the context of an agile framework.

kuschku 11y ago
The argument is: Agile is impossible. You have to document every feature before implementing it, because someone else will write software depending on it while you implement it. If you already document and plan every feature before implementing it, you aren’t doing agile, you’re doing waterfall. What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for every problem separately.
- jdbernard 11y ago
  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.
- matthewmacleod 11y ago
  What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for every problem separately. Well, isn't that the core of any software development process? We're ultimately delivering features, and they all require planning, documentation and testing. The development methodology used doesn't change that. 'Agile' is the key word – change will happen, and being agile helps you to respond to that.
  - kuschku 11y ago
    I responded to your sibling comment with the definition of Waterfall. And every single comment defending Agile here was just "well, you can still document stuff before implementing it, and then verify it, and then maintain it". Which, effectively, is: Even if you’re agile, you can still do waterfall. Great...
    - matthewmacleod 11y ago
      Obviously I'm not making a particularly convincing argument… At the end of the day, agile development is primarily about ensuring that you can respond to change quickly and with minimal disruption. Change occurs in all software projects, and agile tries to avoid some of the pitfalls that one can fall into by architecting an entire system in advance. "Even if you’re agile, you can still do waterfall." is not quite what i'm trying to get across. Rather, it's that agile doesn't mean you can't provide documentation in advance if that is a specific requirement. Bear in mind that external APIs that must be stable are quite distinct from the rest of the system; indeed, it's a horribly design failure if you can't completely swap out your implementation without changing those APIs!

kuschku 11y ago

The argument is: Agile is impossible. You have to document every feature before implementing it, because someone else will write software depending on it while you implement it. If you already document and plan every feature before implementing it, you aren’t doing agile, you’re doing waterfall. What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for every problem separately.

jdbernard 11y ago
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.
matthewmacleod 11y ago
What you are suggesting – to plan, document, implement and test every feature one after another – is just waterfall for every problem separately. Well, isn't that the core of any software development process? We're ultimately delivering features, and they all require planning, documentation and testing. The development methodology used doesn't change that. 'Agile' is the key word – change will happen, and being agile helps you to respond to that.
- kuschku 11y ago
  I responded to your sibling comment with the definition of Waterfall. And every single comment defending Agile here was just "well, you can still document stuff before implementing it, and then verify it, and then maintain it". Which, effectively, is: Even if you’re agile, you can still do waterfall. Great...
  - matthewmacleod 11y ago
    Obviously I'm not making a particularly convincing argument… At the end of the day, agile development is primarily about ensuring that you can respond to change quickly and with minimal disruption. Change occurs in all software projects, and agile tries to avoid some of the pitfalls that one can fall into by architecting an entire system in advance. "Even if you’re agile, you can still do waterfall." is not quite what i'm trying to get across. Rather, it's that agile doesn't mean you can't provide documentation in advance if that is a specific requirement. Bear in mind that external APIs that must be stable are quite distinct from the rest of the system; indeed, it's a horribly design failure if you can't completely swap out your implementation without changing those APIs!