3 ms·
"we were discussing today in one compsci class how agile is something that only works if you don’t care about consistent quality and only care about always havi
by parasubvert 11y ago
"we were discussing today in one compsci class how agile is something that only works if you don’t care about consistent quality and only care about always having the newest, shiniest, greatest."
My employer (Pivotal) uses XP across the company as a way of building consistently high quality software products at a sustainable pace. We have something of a reputation for doing this over the past 20 years with Pivotal Labs.
"And how, if you are working on software for ESA, or working for one of the largest internet retailers, or if you’re writing a control software for railway switches, waterfall is the only possible option."
This is partial nonsense.
Firstly, unmodified waterfall was never an explicit software development methodology, it was an example used by Winston Royce in 1970 about how NOT to run a software project. http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
You think Amazon delivers software in a waterfall? Amazon has dozens of teams building microservices in parallel with thousands of releases to production happening daily. http://joshuaseiden.com/blog/2013/12/amazon-deploys-to-production-every-11-6-seconds/ http://joshuaseiden.com/blog/2013/12/amazon-deploys-to-produ...
I was the General Manager of Operations for a Class 1 railway, and know something about how railways systems were design and built. Control software for railway switches is written around once every 25 years, so yes, one can do that in a more deliberately planned manner. Financial and billing software for railways is mostly Mainframe or packaged (SAP or Oracle), so that too, was built in a waterfall, which was by no means a guarantor of quality in practice, with many problems being discovered only after deployment.
Yard management systems and equipment tracking can be built in an agile manner, though mostly were built in the 80s and 90s so only add-ons and additions are being built in this way. Much of the surrounding demand management, BI, order management, and forecasting systems are built (at worst) in an ad hoc manner or (at best) in an agile manner, because the level of change required is too high to warrant the lead times of a waterfall-planned approach.
The point is that most companies that develop new products do not do so in a waterfall manner, they do it in a manner that allows for continuous feedback, because they've learned that quality in the face of uncertain requirements requires such feedback.
"Even if the target is moving, agile is never able to provide quality."
The most polite thing I can say to this is, "citation needed".
Agile methods are an attempt to use Lean product development principles in the realm of software. I think you may want to learn more about them before drawing such conclusions.
- kuschku 11y ago1. I was not talking about Amazon. 2. 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. 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. Agile is useful if you can always push the latest version to all users, as in web applications.
- parasubvert 11y ago"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.
- kuschku 11y agoAnd 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.