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

[kuschku]

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]

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.