6 ms·

That's all just horribly inaccurate. There is no aspect of agile development that means that 'quality' (whatever that means!) cannot be delivered. Forget all

That's all just horribly inaccurate. There is no aspect of agile development that means that 'quality' (whatever that means!) cannot be delivered. Forget all of the fancy words and meetings and tools and techniques. At the core, agile development is about breaking work down into manageable, deliverable, testable parts, and being able to flexibly respond to changes in requirements when they inevitably happen – the goal being to ensure you are always building the correct thing. You're right that this might not be appropriate for some systems – particularly those where there are unavoidable complex, cross-system dependencies that define acceptance. That's fine – traditional engineering approaches are suitable for these cases. But the idea that agile development is anything to do with "without oversight and every employee was working on whatever they wanted." is a complete nonsense.

kuschku 11y ago
I’ve commented twice on this before, I don’t know if I should comment the same again, but: The type of development written down in the manifesto, and the type of development used by companies as Google or Facebook, is not in any way acceptable for critical systems. Or complex systems. The worst part is when that interpretation of agile [1] is used for complex systems, like it is by Google or Facebook and similar companies. Agile works for web services, for small apps, but that’s it. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring. It’s rare that you can build a system where you don’t have issues with concurrency (and need to do timing analyses) or with interactions between multiple different systems. I’ve seen these issues even when writing tiny projects like an Android app for an IRC bouncer. And in any serious development, where your code is going to run critical systems for decades, you can’t just work agile. ---------------- [1] "as long as it works, documentation doesn’t matter", or "always have the newest, shiniest, greatest – no matter about plan or software design" – paraphrased from http://www.agilemanifesto.org/ http://www.agilemanifesto.org/
- matthewmacleod 11y ago
  Agile works for web services, for small apps, but that’s it. That's plainly not true. Many large applications are written by agile teams. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring. Yes – none of these things are banned by agile development. Refactoring is positively encouraged! It’s rare that you can build a system where you don’t have issues with concurrency (and need to do timing analyses) or with interactions between multiple different systems. Absolutely. This has no relation to the development process used to build those systems.
  - kuschku 11y ago
    > Absolutely. This has no relation to the development process used to build those systems. Yes, it has. Agile encourages people adding features without previously planning every single interaction of the feature with every other piece of software. Which means, Agile encourages writing code without being sure it will interact safely with other parts.
    - dustinleblanc 11y ago
      No, it doesn't, you are making things up. There are plenty of agile/scrum teams who run continuous integration that won't allow code that breaks a build to even be in production. They write integration tests and acceptance tests and all of it is done with sprints and iteration. Agile does no encouraging of adding features. It simply gives you the freedom to choose which ones get implemented based on the current knowledge rather than be forced to make those decisions based on 18 months ago knowledge.
      - kuschku 11y ago
        Sure? Because last I remember, Google is constantly shipping their Android Compat Libs with constant integration issues. You’d assume that at least Google gets it right.
- parasubvert 11y ago
  "Agile works for web services, for small apps, but that’s it. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring." I hope you discover the flaw in this logic sooner in your career than later. I'll start with a hint: You are misreading the Agile manifesto. All successful teams and companies - Agile or not - do planning, thought, design. And the Agile community (which came out of the Smalltalk community) also invented refactoring (in the disciplined sense, along with the first Refactoring IDE). Here's another hint: very few actively run systems in financial markets/brokerages were written with a waterfall method since the mid 90s. Not all were developed with great agile either, but let's just say they were "incremental and iterative". These are complex systems. They're not designed for 8 months on paper. "And in any serious development, where your code is going to run critical systems for decades, you can’t just work agile." This is somewhat true, assuming you have stable requirements. But almost no software, even for complex systems, runs for decades without an update. It just doesn't happen anymore except in the most constrained environments (space exploration, signal/control systems in dark territory, etc.) If your career trajectory is working for the military building weapons guidance systems, or an FDA manufacturer building blood pressure monitors, you also may come close to this ideal. But note even companies in mission critical healthcare, like Philips, are adopting cloud, open source, and agile in their next-generation health management systems that integrate with their MRIs and CT scanners.
  - kuschku 11y ago
    And I can tell you that even some cloud software, like the Elektronische Gesundheitskarte was developed with Waterfall. Often you have to design software interacting with dozens of other entities, all who are going to write software interacting with your system. And your system is supposed to be able to run for years or decades with minimal maintenance. Agile is far more suited for web apps, or small mobile apps, which can be constantly updated.
    - rjspotter 11y ago
      Healthcare.gov was also a healthcare application developed waterfall style and was an enormous failure on launch day because of it's interactions with 3rd party systems.

kuschku 11y ago

I’ve commented twice on this before, I don’t know if I should comment the same again, but: The type of development written down in the manifesto, and the type of development used by companies as Google or Facebook, is not in any way acceptable for critical systems. Or complex systems. The worst part is when that interpretation of agile [1] is used for complex systems, like it is by Google or Facebook and similar companies. Agile works for web services, for small apps, but that’s it. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring. It’s rare that you can build a system where you don’t have issues with concurrency (and need to do timing analyses) or with interactions between multiple different systems. I’ve seen these issues even when writing tiny projects like an Android app for an IRC bouncer. And in any serious development, where your code is going to run critical systems for decades, you can’t just work agile. ---------------- [1] "as long as it works, documentation doesn’t matter", or "always have the newest, shiniest, greatest – no matter about plan or software design" – paraphrased from http://www.agilemanifesto.org/ http://www.agilemanifesto.org/

matthewmacleod 11y ago
Agile works for web services, for small apps, but that’s it. That's plainly not true. Many large applications are written by agile teams. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring. Yes – none of these things are banned by agile development. Refactoring is positively encouraged! It’s rare that you can build a system where you don’t have issues with concurrency (and need to do timing analyses) or with interactions between multiple different systems. Absolutely. This has no relation to the development process used to build those systems.
- kuschku 11y ago
  > Absolutely. This has no relation to the development process used to build those systems. Yes, it has. Agile encourages people adding features without previously planning every single interaction of the feature with every other piece of software. Which means, Agile encourages writing code without being sure it will interact safely with other parts.
  - dustinleblanc 11y ago
    No, it doesn't, you are making things up. There are plenty of agile/scrum teams who run continuous integration that won't allow code that breaks a build to even be in production. They write integration tests and acceptance tests and all of it is done with sprints and iteration. Agile does no encouraging of adding features. It simply gives you the freedom to choose which ones get implemented based on the current knowledge rather than be forced to make those decisions based on 18 months ago knowledge.
    - kuschku 11y ago
      Sure? Because last I remember, Google is constantly shipping their Android Compat Libs with constant integration issues. You’d assume that at least Google gets it right.
parasubvert 11y ago
"Agile works for web services, for small apps, but that’s it. Anything larger, or more complex, needs planning, thought, and design. And often needs refactoring." I hope you discover the flaw in this logic sooner in your career than later. I'll start with a hint: You are misreading the Agile manifesto. All successful teams and companies - Agile or not - do planning, thought, design. And the Agile community (which came out of the Smalltalk community) also invented refactoring (in the disciplined sense, along with the first Refactoring IDE). Here's another hint: very few actively run systems in financial markets/brokerages were written with a waterfall method since the mid 90s. Not all were developed with great agile either, but let's just say they were "incremental and iterative". These are complex systems. They're not designed for 8 months on paper. "And in any serious development, where your code is going to run critical systems for decades, you can’t just work agile." This is somewhat true, assuming you have stable requirements. But almost no software, even for complex systems, runs for decades without an update. It just doesn't happen anymore except in the most constrained environments (space exploration, signal/control systems in dark territory, etc.) If your career trajectory is working for the military building weapons guidance systems, or an FDA manufacturer building blood pressure monitors, you also may come close to this ideal. But note even companies in mission critical healthcare, like Philips, are adopting cloud, open source, and agile in their next-generation health management systems that integrate with their MRIs and CT scanners.
- kuschku 11y ago
  And I can tell you that even some cloud software, like the Elektronische Gesundheitskarte was developed with Waterfall. Often you have to design software interacting with dozens of other entities, all who are going to write software interacting with your system. And your system is supposed to be able to run for years or decades with minimal maintenance. Agile is far more suited for web apps, or small mobile apps, which can be constantly updated.
  - rjspotter 11y ago
    Healthcare.gov was also a healthcare application developed waterfall style and was an enormous failure on launch day because of it's interactions with 3rd party systems.