5 ms·

Why? What that is written in the Agile Manifesto precludes quality?

kuschku 11y ago
> Responding to change over following a plan Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. But often refactoring the system, rewriting subsystems, etc is necessary. > Working software over comprehensive documentation If your software is working, but there is no documentation, this might work well for a website, but as soon as you go into control systems for the heating of the ISS, or go into railway control systems, or systems that measure the optimum way of packaging a package at an internet retailer, documentation is everything. ---------------- The agile manifesto works kinda, but, to quote a professor, especially the "as long as it works, we don’t need to know what we are doing or have documentation, leads to you carrying all that technical debt around with you all the time". One of the largest european internet retailers fixed their code quality problems by forcing teams to release all code shared between two teams to be released under Apache License on GitHub. Suddenly developers started caring about code quality, reusability, and maintainability.
- matthewmacleod 11y ago
  Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. No, it doesn't. Bad management and process leads to that. But often refactoring the system, rewriting subsystems, etc is necessary. Totally acceptable and something that can easily be included in agile development. If your software is working, but there is no documentation This is not a prerequisite of agile development.
  - kuschku 11y ago
    > > If your software is working, but there is no documentation > This is not a prerequisite of agile development. No, but agile says that software is still quality software, even when documentation doesn’t work. http://www.agilemanifesto.org/ http://www.agilemanifesto.org/ It’s pretty clearly written down.
    - matthewmacleod 11y ago
      You are ignoring what I am saying – these are guidelines and principles to follow in development processes, not absolute requirements. If a requirement for the system you are delivering is comprehensive, complete documentation, then you can deliver that. The point is that "comprehensive documentation" without "working software" is useless.
      - kuschku 11y ago
        No, it is not. Your software might be working later on – and at the same time, someone else can write software depending on yours, based on just the documentation. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.
        matthewmacleod 11y ago
        No, it is not. Your software might be working later on It might be, but it almost certainly won't be. See the errata to any set of documentation. But this is a digression – if the acceptance of your product or feature requires documentation of interfaces in advance, then that's a requirement that can be met regardless of the development process that you use. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones. No, that's what incorrectly designed, implemented or tested software leads to. But again – if documentation is required, using an agile process in no way restricts your ability to meet that requirement
        kuschku 11y ago
        But when you have to document and plan everything you write before you do so, isn’t that again waterfall? Are you just telling me that waterfall is also agile?
        matthewmacleod 11y ago
  - rbanffy 11y ago
    >> If your software is working, but there is no documentation > This is not a prerequisite of agile development. What I often see in "waterfail" projects is documentation that's inaccurate and reflects what once was the plan someone wanted to build.
    - matthewmacleod 11y ago
      This is so often the case, I agree. I can't count the number of times I've received a design document that details to the level of database field names – and of course, never bears any relation to the final product.
    - Joof 11y ago
      As an aside; I've been playing with rust and it's built-in documentation solution has an interesting quality to it. Code snippets in documentation are compiled and can be tested at compile time. It's one excellent way to ensure that updates that necessitate a change in documentation actually get documented.
      - rbanffy 11y ago
        I love using doctests in my Python code. They can't replace proper tests, but its great to be able to guarantee your docstrings are correct.
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- deleted 11y ago
  [deleted]
- rbanffy 11y ago
  Never allow your school to interfere with your education. > in reality, leads to everyone working on random things, No. It's just that we acknowledge plans need to change and draw new plans. If we feel something need refactoring, we refactor. If it needs a complete rewrite, we do it. We can do it because we have tests for everything. The tests define what the parts do. They are part of the documentation, one you can run and be 100% sure it is correct. When we acknowledge something needs to be redone, we plan for it. > If your software is working, but there is no documentation, See above. > to quote a professor Judge the argument, not the person making it. > Apache License on GitHub. Suddenly developers started caring about code quality A GPLv3 variation could have been a smarter move, but yes. Having people able to look over your shoulder is a fairly decent quality driver. All my recent work is open source and, when I cut a corner, I always document the corner, why I cut it and when and how I will fix it.
  - kuschku 11y ago
    I added in the first comment my definition of quality. And in projects like "ISS heating control", or "railway control system", or "electronical ID card for 82 million people", you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc. And Agile is ill suited for that. Agile is well suited for cases where no one ever depends on a your software providing a specific interface and where your target moves quickly and where you can ensure everyone always runs the latest version. In other words, small applications and web apps.
    - parasubvert 11y ago
      "you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc. And Agile is ill suited for that." I really think you need to build a lot more software before you can make a claim like that. You're being fed lines from your professors. The vast majority of software, period, is not backward compatible, has to be rewritten all the time, and costs billions to maintain, and is hard to maintain. Agile vs. Waterfall is only one factor among many in such as discussion. The difference with Agile is in its ability to deal with uncertain requirements, something Waterfall cannot handle by its nature.
- simons 11y ago
  "Working software over comprehensive documentation" over != instead of: "That is, while there is value in the items on the right, we value the items on the left more." And no, you probably wouldn't use agile to manage the project of heating the ISS. That is a very static problem space with unique requirements. Using the same framework to plan and build anything related to heating the ISS to build an HR system would be overkill. Right tool for the job, etc. I've worked on both good and bad agile projects - all have involved managing change. The good ones didn't involve throwing a plan out & doing what you want. They merely accepted that when you start building a solution, you lift rocks and uncover requirements that you never envisaged having. In an agile environment, you can deal with that - bring those things onboard, reprioritise and rescope, giving an accurate idea of when a product is going to be delivered. In a traditional waterfall environment, these same requirements get left until the now-woefully inadequate product is built, and useless to anyone.
  - kuschku 11y ago
    Well, that’s why you start testing what you can do, what the issues will be, etc while still working on the plan. You don’t decide to build a bridge out of a specific steel without testing in models which kind of steel is ideal for your case, or if you might have to change the shape of the bridge. But in the moment that others will build projects depending on your implementation being stable – in the bridge example, this would be others building the pillars for the bridge or the bridge deck – you have to keep the implementation stable. (In software, this is usually third parties basing software on your interface)
    - simons 11y ago
      But it's not just simply the "correctness" of a solution that changes, that 3rd party API you're having to interface with might not return data in the same way you were expecting, the other company who were going to deliver the grid component can't do it in time anymore, half the dev team have fallen ill and are out for 3 weeks. No amount of planning up front can ever be sufficient, agile gives us devices to manage all of this that the traditional waterfall strawman lacks. And then there's the solution itself not being suitable. Have you ever shown a solution built completely to spec in a waterfall-esque environment, only for them to say "oh, but it doesn't solve x"? or for them to start using it and suddenly realise there's some fundamental flaw in it? This is where agile comes in - you can regularly demo the software and make adjustments and reprioritisations as it comes together. It enables that conversation to be had and the change to be made when it's cheapest - early on, rather than when a huge app has been built on top of it. Also - agile doesn't preclude stability. You can manage this with test suites (the top layer of the current project I'm working on's test suite is built against our documentation), we know if and when we've broken something because we're constantly emulating the third parties in your example using our software and asserting that it remains correct.
- deleted 11y ago
  [deleted]

> Responding to change over following a plan Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. But often refactoring the system, rewriting subsystems, etc is necessary. > Working software over comprehensive documentation If your software is working, but there is no documentation, this might work well for a website, but as soon as you go into control systems for the heating of the ISS, or go into railway control systems, or systems that measure the optimum way of packaging a package at an internet retailer, documentation is everything. ---------------- The agile manifesto works kinda, but, to quote a professor, especially the "as long as it works, we don’t need to know what we are doing or have documentation, leads to you carrying all that technical debt around with you all the time". One of the largest european internet retailers fixed their code quality problems by forcing teams to release all code shared between two teams to be released under Apache License on GitHub. Suddenly developers started caring about code quality, reusability, and maintainability.

matthewmacleod 11y ago
Which, in reality, leads to everyone working on random things, just adding features and somehow patching bugs. No, it doesn't. Bad management and process leads to that. But often refactoring the system, rewriting subsystems, etc is necessary. Totally acceptable and something that can easily be included in agile development. If your software is working, but there is no documentation This is not a prerequisite of agile development.
- kuschku 11y ago
  > > If your software is working, but there is no documentation > This is not a prerequisite of agile development. No, but agile says that software is still quality software, even when documentation doesn’t work. http://www.agilemanifesto.org/ http://www.agilemanifesto.org/ It’s pretty clearly written down.
  - matthewmacleod 11y ago
    You are ignoring what I am saying – these are guidelines and principles to follow in development processes, not absolute requirements. If a requirement for the system you are delivering is comprehensive, complete documentation, then you can deliver that. The point is that "comprehensive documentation" without "working software" is useless.
    - kuschku 11y ago
      No, it is not. Your software might be working later on – and at the same time, someone else can write software depending on yours, based on just the documentation. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones.
      - matthewmacleod 11y ago
        No, it is not. Your software might be working later on It might be, but it almost certainly won't be. See the errata to any set of documentation. But this is a digression – if the acceptance of your product or feature requires documentation of interfaces in advance, then that's a requirement that can be met regardless of the development process that you use. Additionally, software without documentation leads to issues like "does the train continue running when the signal is broken?", and similar ones. No, that's what incorrectly designed, implemented or tested software leads to. But again – if documentation is required, using an agile process in no way restricts your ability to meet that requirement
        kuschku 11y ago
        But when you have to document and plan everything you write before you do so, isn’t that again waterfall? Are you just telling me that waterfall is also agile?
        matthewmacleod 11y ago
- rbanffy 11y ago
  >> If your software is working, but there is no documentation > This is not a prerequisite of agile development. What I often see in "waterfail" projects is documentation that's inaccurate and reflects what once was the plan someone wanted to build.
  - matthewmacleod 11y ago
    This is so often the case, I agree. I can't count the number of times I've received a design document that details to the level of database field names – and of course, never bears any relation to the final product.
  - Joof 11y ago
    As an aside; I've been playing with rust and it's built-in documentation solution has an interesting quality to it. Code snippets in documentation are compiled and can be tested at compile time. It's one excellent way to ensure that updates that necessitate a change in documentation actually get documented.
    - rbanffy 11y ago
      I love using doctests in my Python code. They can't replace proper tests, but its great to be able to guarantee your docstrings are correct.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
rbanffy 11y ago
Never allow your school to interfere with your education. > in reality, leads to everyone working on random things, No. It's just that we acknowledge plans need to change and draw new plans. If we feel something need refactoring, we refactor. If it needs a complete rewrite, we do it. We can do it because we have tests for everything. The tests define what the parts do. They are part of the documentation, one you can run and be 100% sure it is correct. When we acknowledge something needs to be redone, we plan for it. > If your software is working, but there is no documentation, See above. > to quote a professor Judge the argument, not the person making it. > Apache License on GitHub. Suddenly developers started caring about code quality A GPLv3 variation could have been a smarter move, but yes. Having people able to look over your shoulder is a fairly decent quality driver. All my recent work is open source and, when I cut a corner, I always document the corner, why I cut it and when and how I will fix it.
- kuschku 11y ago
  I added in the first comment my definition of quality. And in projects like "ISS heating control", or "railway control system", or "electronical ID card for 82 million people", you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc. And Agile is ill suited for that. Agile is well suited for cases where no one ever depends on a your software providing a specific interface and where your target moves quickly and where you can ensure everyone always runs the latest version. In other words, small applications and web apps.
  - parasubvert 11y ago
    "you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc. And Agile is ill suited for that." I really think you need to build a lot more software before you can make a claim like that. You're being fed lines from your professors. The vast majority of software, period, is not backward compatible, has to be rewritten all the time, and costs billions to maintain, and is hard to maintain. Agile vs. Waterfall is only one factor among many in such as discussion. The difference with Agile is in its ability to deal with uncertain requirements, something Waterfall cannot handle by its nature.
simons 11y ago
"Working software over comprehensive documentation" over != instead of: "That is, while there is value in the items on the right, we value the items on the left more." And no, you probably wouldn't use agile to manage the project of heating the ISS. That is a very static problem space with unique requirements. Using the same framework to plan and build anything related to heating the ISS to build an HR system would be overkill. Right tool for the job, etc. I've worked on both good and bad agile projects - all have involved managing change. The good ones didn't involve throwing a plan out & doing what you want. They merely accepted that when you start building a solution, you lift rocks and uncover requirements that you never envisaged having. In an agile environment, you can deal with that - bring those things onboard, reprioritise and rescope, giving an accurate idea of when a product is going to be delivered. In a traditional waterfall environment, these same requirements get left until the now-woefully inadequate product is built, and useless to anyone.
- kuschku 11y ago
  Well, that’s why you start testing what you can do, what the issues will be, etc while still working on the plan. You don’t decide to build a bridge out of a specific steel without testing in models which kind of steel is ideal for your case, or if you might have to change the shape of the bridge. But in the moment that others will build projects depending on your implementation being stable – in the bridge example, this would be others building the pillars for the bridge or the bridge deck – you have to keep the implementation stable. (In software, this is usually third parties basing software on your interface)
  - simons 11y ago
    But it's not just simply the "correctness" of a solution that changes, that 3rd party API you're having to interface with might not return data in the same way you were expecting, the other company who were going to deliver the grid component can't do it in time anymore, half the dev team have fallen ill and are out for 3 weeks. No amount of planning up front can ever be sufficient, agile gives us devices to manage all of this that the traditional waterfall strawman lacks. And then there's the solution itself not being suitable. Have you ever shown a solution built completely to spec in a waterfall-esque environment, only for them to say "oh, but it doesn't solve x"? or for them to start using it and suddenly realise there's some fundamental flaw in it? This is where agile comes in - you can regularly demo the software and make adjustments and reprioritisations as it comes together. It enables that conversation to be had and the change to be made when it's cheapest - early on, rather than when a huge app has been built on top of it. Also - agile doesn't preclude stability. You can manage this with test suites (the top layer of the current project I'm working on's test suite is built against our documentation), we know if and when we've broken something because we're constantly emulating the third parties in your example using our software and asserting that it remains correct.
deleted 11y ago
[deleted]