"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."
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.
Good grief.. this comments section is a disaster.
Agile is far from perfect but for software development it is FAR superior to waterfall. If you think differently then you either have zero experience delivering software over the last 10 years or you work for an organization that it is clearly in denial.
Except for the fact that almost everything we use was built with waterfall. From the CPU/GPU to the OS to my browser and most of my apps... almost all were likely built with waterfall.
Outside of a few websites, I don't think the full on TDD/Agile blitz has built much.
"you want a software that is backwards compatible so third parties interacting with you will never have to rewrite your software, you want a software that runs with minimal maintenance, but is easy to extends, etc. And Agile is ill suited for that."
I really think you need to build a lot more software before you can make a claim like that. You're being fed lines from your professors.
The vast majority of software, period, is not backward compatible, has to be rewritten all the time, and costs billions to maintain, and is hard to maintain.
Agile vs. Waterfall is only one factor among many in such as discussion. The difference with Agile is in its ability to deal with uncertain requirements, something Waterfall cannot handle by its nature.
I may have responded to the wrong person (or you've edited your post) as the post I meant to respond to was most definitely comparing waterfall to agile.
It's very common for agile proponents to push Waterfall as the necessary alternative to agile, but that's a logical fallacy.
I was an early adopter (1999-2000), and for years was excited. I was burnt out on programming and considering quitting the industry, but adopting XP made things so much saner that it turned things around for me. But circa 2007 I heard more and more horror stories about companies that were "doing Agile", by which they meant top-down imposition of some fraction of things, plus managers slapping shiny new labels on their same old bullshit.
It was heartbreaking to see something that helped me and my teams a great deal get so throughly misused. It became just another stick to beat developers with. I spent a lot of time apologizing for all the pain people endured.
It's hardly the first time, though. The original paper on Waterfall basically said, "This is a thing that is bad and does not work." But people went and did waterfall anyhow, because a) it conforms to a number of human biases, b) it reinforces the typical top-down corporate power structure, and c) provides endless opportunities for people to blame other people for problems. So in retrospect I'm not shocked at all that we've mostly turned the various Agile methods into meaningless pablum.
So you prefer waterfall ? Most of my gigs have been in big corporate environments where people are considered "resources" and agile has nothing but savior for me .
Bad agile is always better than even good waterfall .
Having worked on government projects, agile is definitely better than waterfall. The specs will change, better accept that early on and work with it, instead of trying to nail down the wrong thing.
In most cases what you need is management permission to move quicker. Everyone says they want to be agile, but doesn't want to invest in the tooling (unit and integration tests, build servers, etc) that would let you be agile, so you end up with agile overlaid over the waterfall methodology, which does absolutely nothing.
I work at a government agency, no scrum, no agile, no nothing. It's so bad I'd kill for waterfall.
I personally love Visual Studio. Using continuous integration was an eye opener to me, I'm still not sold on continuous deployment though (on call isn't a good option IMO for a developer).
This are CI/CD technologies, and perfectly fit into a waterfall deployment too.
reply