>>26445- Agile creates/exacerbates the problem it says it solves (bad requirements engineering). "Requirements change !" becomes an excuse for not planning and management being more fickle than they otherwise would have been.
- No True Scotsman: agile practitioners and consultants (grifters) claim every failed implementation of Agile is a result of it not really being agile or not being agile enough. Counterexamples are dismissed – idealism.
- ‘Waterfall’ as a term is a pejorative neologism coined (or at least popularized) by the authors of the agile manifesto (2001) lumping together a bunch of different methodologies. Imagine if you started a new religion and got 90% of the worlds population to start calling all previous religions as “Previous-ism”. that's one heck of a marketing job. This is what has happened in SWE with a younger generation only being raised on agile and led to believe every software project methodology before 2001 or so was 'waterfall' and that its outdated and wrong. "Waterfall" is actually better understood as almost a parody of earlier 1970s methodologies like the ones presented by people like Winston Royce who had a background in embedded aerospace/spacecraft engineering and were applying more straightforward parts of systems engineering to software. Royce (and others in the same vein)
never called their methods 'Waterfall' and in fact the unilinear model on which 'waterfall' is based, is only the first one presented. By figure 10 Royce gives much more complex models with feedback loops. see:
https://web.archive.org/web/20190307012048/http://www-scf.usc.edu/~csci201/lectures/Lecture11/royce1970.pdf . 'Waterfall’ is a strawman in that most of the previously existing methodologies were far less rigid in practice than the conventional unilinear ‘waterfall’ diagram (analysis→ design→ implementation→ testing) would lead one to believe.
- Bad/no requirements engineering exacerbates scope creep. Scope creep leads to bad architectural decisions as system design decisions which are appropriate for one set of requirements become inappropriate or inadequate for another.
- Agile practitioners claim its not possible to know requirements in advance: often not true and certainly not necessarily true for all domains. Often non-functional/quality attribute requirements are the most well known in advance and also the most impactful on architecture.
- Classic V model (closest to the ‘waterfall’ platonic ideal that actually existed in reality) actually works. Think of a freshman student CS assignment to create a singly linked list. The requirements and timeline (due date) are well known in advance
- XP/Extreme Programming: literally shit on the first project it was used on but not before the creators of it took a premature victory lap to hype their book and XP in general:
https://en.wikipedia.org/wiki/Chrysler_Comprehensive_Compensation_System- In reality, agile is a tradeoff which trades architectural quality for rapid feedback and adjustment. Similar to conventional (requirements based) vs exploratory programming. Would it make sense for all programming to be exploratory (lisp/clojure/python hacking?). Agile has some planning, research spikes, etc.? Yes, but then again, “waterfall” had some feedback mechanisms. Comparing the (never actually existing) platonic ideal of “waterfall” to actually existing agile.
- If requirements and time to complete were known 100% in advance, then agile would never be right. Agile is a project management methodology solution to a requirements analysis problem.
- Traditional software engineering had well tested empirically based methods of estimating time requirements, they just weren’t utilized (ex: COCOMO, COCOMO2). Possible models could be even more improved, let alone with machine learning. More to do with lack of communication between academic research on software engineering and practice in industry, and lack of formal software engineering education leading to ignorance or homebrew methods (CS rather than SWE degrees, autodidacts).
- Agile claims to present to customers each iteration. But that implies that its required end users to be available to validate on an ongoing basis (preferably embedded in the team). High level of communication between client and dev assumed and needed.
- Conventional wisdom in industry is that waterfall is good for small projects while agile is good for large ones. Wrong! at least if architectural quality is to be maintained – waterfall better for large, complex systems which require more system design and architecture up front which means requirements must be more fleshed out. you can't have proper architecture without proper requirements verification, especially non functional requirements. Also for safety critical systems (embedded).
TLDR Agile is just capitalist get-er-done-itis marketed as devs having control of their own work. It's the worker's control of fools. Under socialism every software project will use fully IEEE 29148-compliant Software requirements specification documents and a classic Boehmian V model with verification and validation (or formal methods when needed).