DEV Community 👩‍💻👨‍💻

Discussion on: Mockery of agile

laughingraven profile image
Laughing Raven

I think that waterfall done right is far better than agile done right. You need to have an architectural design. You need to plan things. Agile is far too seat of the pants to be effective. Especially when it comes to long-lived legacy applications. Nowadays we write software and it's thrown away a few years later to be rewritten or refactored or some other BS and this just hasn't been the case in the past. there's been a lot of really good systems created with the waterfall methodology and as I said by and large I believe it is the better of the two paradigms

Thread Thread
codemouse92 profile image
Jason C. McDonald • Edited on

Well, no, I don't know that I can agree here. Agile and Waterfall are both vulnerable to the strange phenomena that plague software development. There are many effectively implemented Agile projects, whether fully or partially compliant with the standard. There are also a number of effective waterfall projects.

One must remember that Agile attempted to answer real problems with waterfall, and it partly succeeded. Managers have always been fairly obsessed with ROI, so they're not going to repeatedly sink time and money into Agile processes instead of the much cheaper waterfall processes if they're not getting something out of it.

Like I said originally...

I agree that Agile has its place.... It would be amazing, if it weren't for the fundamental problem that destroys every well-meaning methodology in this industry: software is weird. (emphasis added)

I think the bigger mistake is to believe that one methodology is inherently "better" than the other, or somehow less prone to failure. Own what works for you and your projects as your personal experience, but don't map that experience to the rest of the industry.

This is what I meant by "the manifest idealism of starry-eyed business majors"; they assumed that, because they could see it working in their minds, it could never fail. Does it work sometimes? Definitely. Does it work enough to warrant learning it and considering it a viable option? No doubt. Is it the answer to All Things, Even World Peace? Not by a longshot.

Thread Thread
jones1618 profile image
Stephen Jones • Edited on

Waterfall is never done right, though. It assumes infinite foresight and precision planning that must never fail or falter.

Who says Agile done right includes no planning? As an organization, you still need to do requirements analysis and prioritization, only Agile gives you permission to continually reassess and adapt to changing goals and market conditions without calling that a failure.

Finally, "Nowadays ... we write software and it's thrown away ... rewritten or refactored." Heck, yeah! That's a feature not a bug. Not only do requirements change and new technologies come along but the truest statement I know in software is "Good software is written. Great software is re-written." Once you've used software in production for a while, why wouldn't it make infinite sense to eventually rewrite parts that aren't working well and hone and expand parts that are proving indispensable? Best of all, Agile plus Continuous Integration lets you "improve in-place", A-B test and innovate in a way that Waterfall could never do without shutting down the whole assembly line and waiting for the organization to gear up for the next big push.

Thread Thread
codemouse92 profile image
Jason C. McDonald • Edited on

Waterfall is never done right, though.

Once again, I must disagree. If this were the case, we would have never shipped a single usable software project prior to the invention of Agile. In fact, not only was software shipped, but some of that same software is still in use, and sometimes is more stable and reliable than some of its modern equivalents. So, Waterfall cannot be unilaterally altogether incompatible with completing a project.

It assumes infinite foresight and precision planning that must never fail or falter.

The way it is usually done, yes. Waterfall has issues, many of which Agile attempted to address.

That said, I've seen many of the same assumptions and mistakes made with Agile.

In reality: both methods would theoretically work well, but for human folly. I've used both successfully, and (more often), I've cherry-picked from both techniques (and others besides) to tailor the exact methodology needed for a single project.

When it comes to methodologies, anytime anyone says "X always works" or "X never works", that demonstrates they have failed to understand the vast majority of components in the problem they're trying to solve. (That's not a personal attack; I just find that to be universally true.)