7 ms·

That's not true. Quality and agile process are almost orthogonal. It is entirely possible to develop extremely high quality software within an agile environment

That's not true. Quality and agile process are almost orthogonal. It is entirely possible to develop extremely high quality software within an agile environment and very possible to develop extremely poor software using waterfall. Agile doesn't mean "every engineer working on whatever they wanted." Ultimately quality software results when developers place a priority on writing correct software and when management is truly committed to creating high quality software and all of the expense that includes.

kuschku 11y ago
> Working software over comprehensive documentation > Responding to change over following a plan These statements from the agile manifesto are directly opposite to any kind of quality software. Documentation and Code Quality are some of the most important features. Your software is not working if it doesn’t exactly match its documentation. You can live with that in web software, but you’d end in jail if you tried to write security critical systems like that.
- jdbernard 11y ago
  > That is, while there is value in the items on the right, we value the items on the left more. Agile does not say that documentation is not important, nor does it say that a plan is bad. Documentation is worthless if the software doesn't work. The plan is crap if it no longer addresses the actual real-world requirements of the product.
  - kuschku 11y ago
    A software without perfect documentation is worthless. Without documentation, you have to assume things. Does the train, if the signal is broken, stop or continue running? Does the radiation treatment machine, if you have a race condition, and two commands are executed at the same time, block, or just execute the last command? Software without documentation kills.
- matthewmacleod 11y ago
  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!
- braythwayt 11y ago
  Whenever the manifesto says “X over Y,” it does not suggest this is a strict dichotomy. I have worked in an agile manner on software that had extremely well-documented behaviour and all sorts of documented, objective requirements. The expression "Working software over comprehensive documentation” simply emphasizes what matters at the end of the day: Working software. If you need a certain amount of comprehensive documentation to prove that the software works, you incorporate that documentation into your process. It’s the same as emphasizing collaboration over contracts. I worked for a decade in consulting, I assure you there are contracts with clients even when you use Scrum. You don’t refuse to have any hard, contracted, binding commitments. It’s just that you prioritize collaborating with people over setting up solitudes that communicate by throwing contracts over a wall. As for responding to change over following a plan, if you can set up an environment where there are no changes allowed to interfere with the plan, by all means ignore change and follow the plan. But if you actually have changes that matter, you need to deal with them too. But that doesn’t mean don’t plan, or never follow any plan. It just means, respond to changes that matter. For example... What if you discover that the security for a piece of software need to be updated. You’d respond to that, wouldn’t you? You wouldn’t push on to finish what was originally planned with your fingers in your ears? These are guidelines. They’re motivating forces. You are supposed to do it in harmony with the hard requirements of your business and domain.
  - kuschku 11y ago
    Documentation can also be useful without working software. For example, when you have to interface with others. They can work on the software that depends on yours before you have even written a single line of code, and it will work. Software without documentation also can lead to serious issues – as in the "does the train continue running when the signal is broken" question I mentioned a dozen times now. In actual critical projects, Documentation over software. The best software is nothing without documentation. That’s the first point where I have to disagree with it. In many other points, agile leads to teams just carrying the technical debt with them.
    - jdbernard 11y ago
      Does the fact that you haven't read all the detailed technical specs for your car prevent you from using it? Do you know the detailed specs for the actually critical braking mechanism in your vehicle? Or is it impossible to use your car because you don't know the tolerances of every nut and bolt in the system?
- rjspotter 11y ago
  How many lines of code have you written that are in production with actual users right now?
  - kuschku 11y ago
    I’ve worked on some agile projects from others that I picked up and had to "fix", where we, now, after 2 years of trying to work with them, have decided to completely rewrite them from scratch. Every agile project I’ve seen yet was just a huge ball of technical debt. It worked, it had few user-facing bugs, but adding features was impossible, and the documentation was "whatever the software does". Completely matched the agile manifesto "working software over documentation" and "change over plan".
    - jdbernard 11y ago
      As compared to the waterfall projects I've witnessed, most of which never made it to completion, the rest of which were far away from what the client actually wanted once delivered. Unfortunately, outside of a small percentage of companies, most software written today is just bad.
      - kuschku 11y ago
        Well, except most government-scale projects that work out well are Waterfall or V-XT.
    - rjspotter 11y ago
      That isn't an answer to the question. Your response is selection bias. Every project that you've seen is a ball of technical debt. There is no argument to how documentation alleviates technical debt. If you document a poorly designed and scoped piece of software it doesn't make it any easier to change. If the software was impossible to change and that change was a requirement then the code bases you were working with did not represent "working software" The agile manifesto says, "working software over documentation." It does not say "working software and an absence of documentation." The fact that you needed to add features is exactly the reason agile exists. If the creators had a complete feature plan in the beginning and faithfully executed it without deviation from the plan then there would be no need to ever add features and the quality of the code in terms of "changability" would be moot.
- s73v3r 11y ago
  "Your software is not working if it doesn’t exactly match its documentation." Not true. Documentation is not always updated. And many times, if not every time, the requirements documents the clients give are often flat out wrong. So you could build the software to the requirements, and end up with something that doesn't meet the client's needs. "Documentation and Code Quality are some of the most important features." However, these take a backseat to working software.
  - kuschku 11y ago
    Your software is not working if all the third party services that depend on the API you provide are broken because you changed your API, or because your documentation is wrong. You can work without documentation or without stable implementations if you control all the endpoints and ensure they always have the latest version (like mobile apps, web apps, etc). But if you can’t, you have to remember that every API version you’ll ever provide will have software using it, and you won’t be able to EOL the support for that version.
- dragonwriter 11y ago
  > Documentation and Code Quality are some of the most important features. Code quality is an important attribute, sure, but those don't say anything about it. Comprehensive documentation of the bureaucratic sort of process documentation that I think motivated that line is not a deliverable, its an artifact of process; when it becomes understood as an end to its own rather than as something that should be used to the extent it is useful to achieve value in the end product, it becomes extremely problematic (I've experienced the kind of bureaucratic software development that this reacts to, and I can assure you that it does not contribute positively to quality, it contributes to management -- and staff -- spending lots of time worrying about and measuring and optimizing metrics that are unrelated to quality.) > Your software is not working if it doesn’t exactly match its documentation. Your software is not working if it doesn't deliver the expected behavior. Documentation of requirements is important to provide a consistent method of communicating between people (and across time and space) what those expectations are. And to the extent that it is necessary for that purpose documentation is a good thing. But its important to keep the purpose in mind. Otherwise, you end up with excessive effort going into polishing documentation rather than building software. > you’d end in jail if you tried to write security critical systems like that. Sure, bureaucratically comprehensive documentation is extremely useful (and sometimes essential) for demonstrating compliance with process mandates. Such mandates, and the incentives they create, are also very often not helpful to the actual quality of software, including the aspects of software quality which motivate the mandates.
PythonicAlpha 11y ago
> Agile doesn't mean "every engineer working on whatever they wanted." I totally agree. In my experience, it is very dependent on the group. When you are unlucky, you are in a group where for example one person always grabs the interesting parts. Because the group decides, it is very much about group pressure and clashing interests. A bad agile group can be similar harmful as a bad project manager. One of the worst project managers, I experienced, insisted to divide the work "evenly" to the people in the group -- totally disregarding experience and abilities of the people. In a bad agile group, similar effects can happen. In non-agile projects, there are dysfunctional groups and in agile projects there can be -- but in the later case, the problems can be worsened.

kuschku 11y ago

> Working software over comprehensive documentation > Responding to change over following a plan These statements from the agile manifesto are directly opposite to any kind of quality software. Documentation and Code Quality are some of the most important features. Your software is not working if it doesn’t exactly match its documentation. You can live with that in web software, but you’d end in jail if you tried to write security critical systems like that.

jdbernard 11y ago
> That is, while there is value in the items on the right, we value the items on the left more. Agile does not say that documentation is not important, nor does it say that a plan is bad. Documentation is worthless if the software doesn't work. The plan is crap if it no longer addresses the actual real-world requirements of the product.
- kuschku 11y ago
  A software without perfect documentation is worthless. Without documentation, you have to assume things. Does the train, if the signal is broken, stop or continue running? Does the radiation treatment machine, if you have a race condition, and two commands are executed at the same time, block, or just execute the last command? Software without documentation kills.
matthewmacleod 11y ago
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!
braythwayt 11y ago
Whenever the manifesto says “X over Y,” it does not suggest this is a strict dichotomy. I have worked in an agile manner on software that had extremely well-documented behaviour and all sorts of documented, objective requirements. The expression "Working software over comprehensive documentation” simply emphasizes what matters at the end of the day: Working software. If you need a certain amount of comprehensive documentation to prove that the software works, you incorporate that documentation into your process. It’s the same as emphasizing collaboration over contracts. I worked for a decade in consulting, I assure you there are contracts with clients even when you use Scrum. You don’t refuse to have any hard, contracted, binding commitments. It’s just that you prioritize collaborating with people over setting up solitudes that communicate by throwing contracts over a wall. As for responding to change over following a plan, if you can set up an environment where there are no changes allowed to interfere with the plan, by all means ignore change and follow the plan. But if you actually have changes that matter, you need to deal with them too. But that doesn’t mean don’t plan, or never follow any plan. It just means, respond to changes that matter. For example... What if you discover that the security for a piece of software need to be updated. You’d respond to that, wouldn’t you? You wouldn’t push on to finish what was originally planned with your fingers in your ears? These are guidelines. They’re motivating forces. You are supposed to do it in harmony with the hard requirements of your business and domain.
- kuschku 11y ago
  Documentation can also be useful without working software. For example, when you have to interface with others. They can work on the software that depends on yours before you have even written a single line of code, and it will work. Software without documentation also can lead to serious issues – as in the "does the train continue running when the signal is broken" question I mentioned a dozen times now. In actual critical projects, Documentation over software. The best software is nothing without documentation. That’s the first point where I have to disagree with it. In many other points, agile leads to teams just carrying the technical debt with them.
  - jdbernard 11y ago
    Does the fact that you haven't read all the detailed technical specs for your car prevent you from using it? Do you know the detailed specs for the actually critical braking mechanism in your vehicle? Or is it impossible to use your car because you don't know the tolerances of every nut and bolt in the system?
rjspotter 11y ago
How many lines of code have you written that are in production with actual users right now?
- kuschku 11y ago
  I’ve worked on some agile projects from others that I picked up and had to "fix", where we, now, after 2 years of trying to work with them, have decided to completely rewrite them from scratch. Every agile project I’ve seen yet was just a huge ball of technical debt. It worked, it had few user-facing bugs, but adding features was impossible, and the documentation was "whatever the software does". Completely matched the agile manifesto "working software over documentation" and "change over plan".
  - jdbernard 11y ago
    As compared to the waterfall projects I've witnessed, most of which never made it to completion, the rest of which were far away from what the client actually wanted once delivered. Unfortunately, outside of a small percentage of companies, most software written today is just bad.
    - kuschku 11y ago
      Well, except most government-scale projects that work out well are Waterfall or V-XT.
  - rjspotter 11y ago
    That isn't an answer to the question. Your response is selection bias. Every project that you've seen is a ball of technical debt. There is no argument to how documentation alleviates technical debt. If you document a poorly designed and scoped piece of software it doesn't make it any easier to change. If the software was impossible to change and that change was a requirement then the code bases you were working with did not represent "working software" The agile manifesto says, "working software over documentation." It does not say "working software and an absence of documentation." The fact that you needed to add features is exactly the reason agile exists. If the creators had a complete feature plan in the beginning and faithfully executed it without deviation from the plan then there would be no need to ever add features and the quality of the code in terms of "changability" would be moot.
s73v3r 11y ago
"Your software is not working if it doesn’t exactly match its documentation." Not true. Documentation is not always updated. And many times, if not every time, the requirements documents the clients give are often flat out wrong. So you could build the software to the requirements, and end up with something that doesn't meet the client's needs. "Documentation and Code Quality are some of the most important features." However, these take a backseat to working software.
- kuschku 11y ago
  Your software is not working if all the third party services that depend on the API you provide are broken because you changed your API, or because your documentation is wrong. You can work without documentation or without stable implementations if you control all the endpoints and ensure they always have the latest version (like mobile apps, web apps, etc). But if you can’t, you have to remember that every API version you’ll ever provide will have software using it, and you won’t be able to EOL the support for that version.
dragonwriter 11y ago
> Documentation and Code Quality are some of the most important features. Code quality is an important attribute, sure, but those don't say anything about it. Comprehensive documentation of the bureaucratic sort of process documentation that I think motivated that line is not a deliverable, its an artifact of process; when it becomes understood as an end to its own rather than as something that should be used to the extent it is useful to achieve value in the end product, it becomes extremely problematic (I've experienced the kind of bureaucratic software development that this reacts to, and I can assure you that it does not contribute positively to quality, it contributes to management -- and staff -- spending lots of time worrying about and measuring and optimizing metrics that are unrelated to quality.) > Your software is not working if it doesn’t exactly match its documentation. Your software is not working if it doesn't deliver the expected behavior. Documentation of requirements is important to provide a consistent method of communicating between people (and across time and space) what those expectations are. And to the extent that it is necessary for that purpose documentation is a good thing. But its important to keep the purpose in mind. Otherwise, you end up with excessive effort going into polishing documentation rather than building software. > you’d end in jail if you tried to write security critical systems like that. Sure, bureaucratically comprehensive documentation is extremely useful (and sometimes essential) for demonstrating compliance with process mandates. Such mandates, and the incentives they create, are also very often not helpful to the actual quality of software, including the aspects of software quality which motivate the mandates.

PythonicAlpha 11y ago

> Agile doesn't mean "every engineer working on whatever they wanted." I totally agree. In my experience, it is very dependent on the group. When you are unlucky, you are in a group where for example one person always grabs the interesting parts. Because the group decides, it is very much about group pressure and clashing interests. A bad agile group can be similar harmful as a bad project manager. One of the worst project managers, I experienced, insisted to divide the work "evenly" to the people in the group -- totally disregarding experience and abilities of the people. In a bad agile group, similar effects can happen. In non-agile projects, there are dysfunctional groups and in agile projects there can be -- but in the later case, the problems can be worsened.