4 ms·

Ill reply to the root of all your comments, but this comment by you below sums up the problem: > If your software has clear requirements, has a point when it i

by cechner 11y ago

Ill reply to the root of all your comments, but this comment by you below sums up the problem: > If your software has clear requirements, has a point when it is done, and only requires minimum maintenance after that, you aren’t writing agile. This is simply not true. All 'agile' projects Ive worked on have had a complete-as-possbile analysis phase where we figured out the scope and the domain up front. This is not anti-agile at all, but is necessary on any project anywhere you are working on. (Agile is largely about avoiding 'big design up front', not 'big analysis up front'. There is a massive difference between analysis and design.) Agile is about changing your plan when the _requirements_ change. Your API or whatever should change if your requirements change no matter what methodology you are using. But with waterfall you will not be able to and you will end up with a useless API.

kuschku 11y ago
The issue is that there are projects where changing your API is impossible, which means that using Agile is often a hopeless concept. Because if huge insurances already depend on your API, no matter how Agile you are, you can’t change it anymore. And there are many cases where your code will be frozen at one point. Even if the requirements change. Especially for Internet-of-Thing devices this can be very problematic, as no one is going to ever update them.
- cechner 11y ago
  I dont really understand this. "NF_REQ_00: API must not change" Add verification tests to ensure API remains as documented. Every time someone checks in code your tests are run, break if something changes. Every project has functional and non functional requirements, you write tests for them, your project is in a failure state if the tests are not passing.
  - kuschku 11y ago
    How do you update the code on a Smart Washing Machine? A Smart Pacemaker? In the world where everything is digital, we’ll have a huge technical debt of un-updatable software.
    - cechner 11y ago
      you mean firmware updates? What is the problem you are talking about? Plus its a regular problem ensuring that an API is stable. People do it all the time - aren't you wondering why you are the only person arguing this point? Many people in this thread deal with these problems on a daily basis...
      - kuschku 11y ago
        The problem is that no one is going to do firmware updates on their smart washing machine. Your software can’t be updated. You have one try to do it right. It’s what next to all of the modern startups don’t get right. They build fancy software, but then in a few years your smart house doesn’t work anymore because the services it connected to have changed APIs and the house itself encountered a few bugs? The lifetime for a washing machine is 30 years. Your software on that will last 30 years. Using a development method designed to make quickly changing requirements easy is stupid when your code will be "write once, never change".
        douche 11y ago
        You are buying much higher quality washing machines than I am, apparently. If you get 8-10 years out of most brands now, you're doing quite well. Planned obsolescence is just the best...
        kuschku 11y ago
        Mostly quality Miele machines. They have 10 years warranty from the manufacturer, so most actually survive for 20 years. Not what they used to make – they used to survive a lifetime – but it’s okay. Same with stoves or fridges. We already see how hard it is to keep mobile devices updated. Android is the nightmare example, but even Apple drops devices after 4 years. In 20 years, your smart fridge will have tons of malware on it if it’s connected to the internet. If it isn’t connected, you won’t be able to get updates, so the software has to be perfect. And the point we made in Uni was that agile is suited for situations where your requirements change after deploying. In all other cases you can do waterfall – provided you actually find out what you’re supposed to do – better.
- dustinleblanc 11y ago
  If you are writing integrations for API features that are fantasy at this point, you are digging your own grave. You have extended your risk and when you find out six months from now that you bet the farm on a useless feature, oh well; thems the breaks.

by cechner 11y ago

kuschku 11y ago

The issue is that there are projects where changing your API is impossible, which means that using Agile is often a hopeless concept. Because if huge insurances already depend on your API, no matter how Agile you are, you can’t change it anymore. And there are many cases where your code will be frozen at one point. Even if the requirements change. Especially for Internet-of-Thing devices this can be very problematic, as no one is going to ever update them.

cechner 11y ago
I dont really understand this. "NF_REQ_00: API must not change" Add verification tests to ensure API remains as documented. Every time someone checks in code your tests are run, break if something changes. Every project has functional and non functional requirements, you write tests for them, your project is in a failure state if the tests are not passing.
- kuschku 11y ago
  How do you update the code on a Smart Washing Machine? A Smart Pacemaker? In the world where everything is digital, we’ll have a huge technical debt of un-updatable software.
  - cechner 11y ago
    you mean firmware updates? What is the problem you are talking about? Plus its a regular problem ensuring that an API is stable. People do it all the time - aren't you wondering why you are the only person arguing this point? Many people in this thread deal with these problems on a daily basis...
    - kuschku 11y ago
      The problem is that no one is going to do firmware updates on their smart washing machine. Your software can’t be updated. You have one try to do it right. It’s what next to all of the modern startups don’t get right. They build fancy software, but then in a few years your smart house doesn’t work anymore because the services it connected to have changed APIs and the house itself encountered a few bugs? The lifetime for a washing machine is 30 years. Your software on that will last 30 years. Using a development method designed to make quickly changing requirements easy is stupid when your code will be "write once, never change".
      - douche 11y ago
        You are buying much higher quality washing machines than I am, apparently. If you get 8-10 years out of most brands now, you're doing quite well. Planned obsolescence is just the best...
        kuschku 11y ago
        Mostly quality Miele machines. They have 10 years warranty from the manufacturer, so most actually survive for 20 years. Not what they used to make – they used to survive a lifetime – but it’s okay. Same with stoves or fridges. We already see how hard it is to keep mobile devices updated. Android is the nightmare example, but even Apple drops devices after 4 years. In 20 years, your smart fridge will have tons of malware on it if it’s connected to the internet. If it isn’t connected, you won’t be able to get updates, so the software has to be perfect. And the point we made in Uni was that agile is suited for situations where your requirements change after deploying. In all other cases you can do waterfall – provided you actually find out what you’re supposed to do – better.
dustinleblanc 11y ago
If you are writing integrations for API features that are fantasy at this point, you are digging your own grave. You have extended your risk and when you find out six months from now that you bet the farm on a useless feature, oh well; thems the breaks.