Hacker News new | past | comments | ask | show | jobs | submit login

"The issue with the ESA code, like with railway systems, is: You write the code one time. You get a review. If you try to change just a single line later on – for example, to fix an issue that leads to the heating system on the ISS overheating – it will cost millions."

I can guarantee you that 90% of the code in the Positive Train Control systems (the first real "new" control/sensor system in freight in decades) were not written with this methodology.

"Agile is a system that is not optimized for taking one version of software and running it for decades or centuries unchanged. Which is often a requirement."

"Almost never" a requirement, in my experience. And... centuries? Really?

"Agile is useful if you can always push the latest version to all users, as in web applications."

Yes, or you know, mobile applications, or sensor network applications, or... basically pretty much most software that isn't in highly constrained environments. The revenue of the former is in the trillions; in the latter is the billions.




And I can guarantee you that the software controlling the switches for the high speed rail and commuter rail networks in my state was written with waterfall.

The requirements were pretty clear, as there was a legacy system to be replaced and the changes to be made were not too hard to be found, the design was done in a DSL specifically written for the task of representing this project, the software was implemented, verified, and by now is under maintenance.

The requirements for a railway system rarely change, so agile is not really useful there.

Regarding "centuries": Some German companies stopped using the original Zuse pre-war computers in 2011. That’s over 70 years of software running constantly. Some banks still run code from the days before C. In the future, we’ll have more and more situations like that. And just like washing machines are sold with a lifetime guarantee, we’ll expect the same from the smart washing machine we’ll buy in 2025, too.


I believe you're fundamentally mistaken about the direction he future is taking: the world is not regressing to things that never change, it is progressing to continuous, perpetual change for most things in active use. There is plenty of evidence for this.

I empathize with a world view that prefers stable, planned, predictable, and long lasting. But I have rarely seen this work in practice.

I work with the banks (including in your state), and as far as I can see their aim is to move towards faster change in their IT systems, and disposability.


The banks do, but the people don’t.

No one wants to have to buy a new Smart Fridge every year because the manufacturer stopped updating the old one. Hell, people won’t even update at all.

We can’t even get updating software on Android correctly. And instead of releasing bugfixes for all releases, Google instantly abandons a version of Android. There are 0 maintenance branches of it.

Applying the Android "Agile" situation to the rest of Software and especially Hardware is the worst nightmare possible. If that is going mainstream, I’ll quit compsci and start teaching kids in a kindergarten instead.

Android is actually the perfect example: Always having the latest is more important than it being thought out well! Documentation is less important than it somehow working!

Android’s update situation is the exact outcome of applying Agile development not just internally, but also externally. And it’s a horrible nightmare.


I feel you, if the world is moving towards Android updates, it won't be a great world.

One can design systems for usable and even pleasant continuous operations AND updatability though - even in an agile manner - eg. erlang and Ericsson.


Sure, one can.

but almost always Agile leads to this issue. Even the previously linked NASA document says their spaceflight software should have a release and update schedule with feature updates similar to Google Chrome (aka, no support for old versions at all, always the newest, shiniest)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: