4 ms·

I've realized there's another thing about this proposal that bothers me: it's basically waterfall software development. Agile is by no means a panacea, but the

I've realized there's another thing about this proposal that bothers me: it's basically waterfall software development. Agile is by no means a panacea, but there's a reason it replaced the "specify in advance what everything will need to look like and how it will work together" method. Instead, you need to just start building pieces that move you towards your eventual goal, roughly envisioned, and know that you will need to iterate on that frequently to respond to what you learn along the way. The motivation of this proposal seems to be that we can know in advance what the impact of a new piece of technology is, and therefore we can just avoid ever developing the bad stuff, so we won't have to deal with the hard work of changing it later. But, we cannot, and it's dangerous to think we can. After we develop technology, we will be surprised at how it is used and what the impact is, and we will have to respond to that, sometimes with more technology and sometimes with legislation and sometimes with changes in social mores. Thinking that developers can just anticipate in advance what will happen, is at best delusional, like thinking that if we spend more time on the specifications part of our next waterfall project, we can do better. Moreover, if Tim Berners-Lee had specified in advance, "this world-wide web thing will probably eviscerate all advertising-supported media, from newspapers to magazines to radio and television", I don't know that we would have made wiser choices as a result of that.

wu-ikkyu 8y ago
Of course no one can predict the future perfectly, but we can at least think about it with some degree of accuracy based on tests and trials. As our technology is becoming so much more powerful and evolving at exponential rates, don't you think it might be a good idea to think a little harder about the how things could backfire?
- imnotlost 8y ago
  One shouldn't constrain development, once the genie is out of the bottle someone will develop it, whatever it is. These considerations should be taken into account when technology is used, sometimes by policy makers in government. There's no way industry will police itself, they've proven time and again that profit is far more important that humans.
  - dwiel 8y ago
    At the extreme, there are all kinds of evil ideas that are technically possible but not widely implemented. This can be seen by how easy terrorism is compared to how infrequently it is carried out. I'd rather not list out a bunch of evil ideas, but I think any engineer with a bit of thought can come up with plenty.
    - BoiledCabbage 8y ago
      > I think any engineer with a bit of thought can come up with plenty I think you're arguing the article's point. Many knowledgeable people can come up with dangerous things. Many people have bad intentions. Luckily for society, there often isn't much overlap of those two groups. This paper is saying "Hey people who have ideas, don't just think through the technical idea you have. Think of how someone with negative intent might be able to leverage this idea to easily do something they couldn't do before. Or even how it could unintentionally happen."
deleted 8y ago
[deleted]
BoiledCabbage 8y ago
What brother's me about this comment is the implicit assumption that waterfall is a universal bad and things that are less waterfall more agile are good/better. This is incredibly false. Agile (or non-waterfall) style development is useful in specific limited cases. Where you're creating something where the cost of failure discovery is small. You're writing a mobile app, or a b2b website, or some other common problem. It's cheap and easy, and the cost of a failure is so small that it's cheaper to just fail and go from there, then to spend anytime thinking about how something may fail. If you're doing something mission critical, space shuttle, something involving expensive parts, something high risk, you make sure you do thorough requirements analysis, well specified behavior, and well defined failure modes. You break the system down into individual small components (the more critical the failure the smaller the components) create well defined specifications for each component, test the he'll out of each one indicidually, ensure they work to spec and then combine them. You don't Agile your way through it. Agile, you'd just get something minimal working end to end and iterate. If the thing you're working on can explode you don't just iterate through a minimal user story. You define each item well and ensure it meets it's specs and you understand it's failure modes. Same thing for the topic at had on impact of technology. Understand the failure modes of the components you're creating - and write them in your paper.
- j-pb 8y ago
  I present you SpaceX as an amazing counterexample to "agile don't work for things that explode". I would much rather sit in a rocket that has blown up a 100 times on the launch pad but launched succesfully a thousand times more with each time being an opportunity to improve it, than one that has been engineered with waterfall and never flown... https://spacenews.com/pentagon-advisory-panel-dod-could-take-a-page-from-spacex-on-software-development/ https://spacenews.com/pentagon-advisory-panel-dod-could-take...

wu-ikkyu 8y ago

Of course no one can predict the future perfectly, but we can at least think about it with some degree of accuracy based on tests and trials. As our technology is becoming so much more powerful and evolving at exponential rates, don't you think it might be a good idea to think a little harder about the how things could backfire?

imnotlost 8y ago
One shouldn't constrain development, once the genie is out of the bottle someone will develop it, whatever it is. These considerations should be taken into account when technology is used, sometimes by policy makers in government. There's no way industry will police itself, they've proven time and again that profit is far more important that humans.
- dwiel 8y ago
  At the extreme, there are all kinds of evil ideas that are technically possible but not widely implemented. This can be seen by how easy terrorism is compared to how infrequently it is carried out. I'd rather not list out a bunch of evil ideas, but I think any engineer with a bit of thought can come up with plenty.
  - BoiledCabbage 8y ago
    > I think any engineer with a bit of thought can come up with plenty I think you're arguing the article's point. Many knowledgeable people can come up with dangerous things. Many people have bad intentions. Luckily for society, there often isn't much overlap of those two groups. This paper is saying "Hey people who have ideas, don't just think through the technical idea you have. Think of how someone with negative intent might be able to leverage this idea to easily do something they couldn't do before. Or even how it could unintentionally happen."

deleted 8y ago

[deleted]

BoiledCabbage 8y ago

What brother's me about this comment is the implicit assumption that waterfall is a universal bad and things that are less waterfall more agile are good/better. This is incredibly false. Agile (or non-waterfall) style development is useful in specific limited cases. Where you're creating something where the cost of failure discovery is small. You're writing a mobile app, or a b2b website, or some other common problem. It's cheap and easy, and the cost of a failure is so small that it's cheaper to just fail and go from there, then to spend anytime thinking about how something may fail. If you're doing something mission critical, space shuttle, something involving expensive parts, something high risk, you make sure you do thorough requirements analysis, well specified behavior, and well defined failure modes. You break the system down into individual small components (the more critical the failure the smaller the components) create well defined specifications for each component, test the he'll out of each one indicidually, ensure they work to spec and then combine them. You don't Agile your way through it. Agile, you'd just get something minimal working end to end and iterate. If the thing you're working on can explode you don't just iterate through a minimal user story. You define each item well and ensure it meets it's specs and you understand it's failure modes. Same thing for the topic at had on impact of technology. Understand the failure modes of the components you're creating - and write them in your paper.

j-pb 8y ago
I present you SpaceX as an amazing counterexample to "agile don't work for things that explode". I would much rather sit in a rocket that has blown up a 100 times on the launch pad but launched succesfully a thousand times more with each time being an opportunity to improve it, than one that has been engineered with waterfall and never flown... https://spacenews.com/pentagon-advisory-panel-dod-could-take-a-page-from-spacex-on-software-development/ https://spacenews.com/pentagon-advisory-panel-dod-could-take...