[cechner]

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]

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]

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]

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]

> 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".

If the requirements change, you must update your software. How does waterfall handle changing requirements? It doesnt.

To repeat: agile _handles_ changing requirements. It doesnt _provoke_ changing requirements.

As someone who spent the first 6 years of my career doing waterfall, the only way to combat this is by treating the functional requirements as an immutable contract between you and the customer. When the requirements change you blame them, and refuse to change your software. Then your software never gets used.

[kuschku]

> If the requirements change, you must update your software. How does waterfall handle changing requirements? It doesnt.

How does agile handle change? By assuming everyone will update and has no issue with all third-party accessories constantly breaking.

If you can’t ever change your code after you’ve written it once, then Agile isn’t useful to you.

[douche]

You seem really hung up on this idea of clients having to update code that is already out in the wild when requirements change.

Maybe I've had a twisted experience of Agile, but it seems like its most useful when you are working on a greenfield project, with a customer that maybe doesn't even know what they want, but they know they want something. So you get some requirements, and build a prototype. Then you show it off, and they make some comments, (generally like: "Can it run in the Cloud? Is it Social?", "Could that icon be more of a cornflower-blue?"). Sometimes you get useful feedback also... Then you go back and refine the prototype. Rinse and repeat, and eventually it does enough that they are happy.

Even when you do know "exactly" what you are building, I would still prefer starting from a bare-bones version, and building out from there. Unless you've built this exact thing before, planning it all out beforehand will invariably miss some Rumsfeldian unknown-unknown technical detail, which might tip up the whole apple-cart of the carefully, laboriously, expensively, laid-out plan.

It's not like its 1995, and releasing a software version involved burning thousands of CDs, printing manuals, boxing it up, and distributing the boxes to retail stores. And most of us are not launching the software we write out beyond low-earth orbit.

[cechner]

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]

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]

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...

[dustinleblanc]

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.