[ home / rules / faq ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]

/tech/ - Technology

"Technology reveals the active relation of man to nature" - Karl Marx
Name
Options
Subject
Comment
Flag
File
Embed
Password(For file deletion.)

Not reporting is bourgeois


File: 1726779646328.jpeg (10.38 KB, 284x177, images.jpeg)

 

Is AGILE a meme?
>Agile software development is an umbrella term for approaches to developing software that reflect the values and principles agreed upon by The Agile Alliance, a group of 17 software practitioners in 2001.

I think agile is overrated and has become a way for consultants to grift and every response to the failure of an agile project is "it wasn't AGILE enough, it didn't truly have managerial buy in" rather than admitting something is wrong with it.

<When “Extreme Programming (XP)” was developed prior to the Agile movement, it was defined in the fourth year of a five-year projected development timeline for the Chrysler C3 Payroll system, a system that was to be developed to replace the existing payroll processes. The people that developed the XP development paradigm thought they had found a “silver bullet” to software development with their dilution of planning and analytical design coupled with the new idea of “paired programming” mixed with a “Code First” strategy. One would think that after working with such development concepts over the four years of their project, they would have been actually on to something. Not waiting for the final results in the form of a completed and delivered project into production, the “Extreme Programming” creators went out on tour around the US to popularize what they believed they had developed as the answer for speeding up software development in a time when technical management was coming under increasing pressures to get their deliverables in to production faster. These promoters elicited a lot of interest and the basis for a new software development paradigm was born. Unfortunately, in the 5th and final year of the project, the entire thing collapsed under the weight of these newly derived concepts proving that they were erroneous from the beginning.
>Nonetheless, a new software industry “meme” had been born as a result of the popularization efforts by the creators of XP. This new meme would have found its way into extinction had it not been for the efforts of a new set of developers (with probably the same people who created XP) who came up with the “Agile Manifesto” promoting a more refined methodology where the best tenets (as they believed them to be) of XP development could be incorporated, while adding alternative and\or refined concepts to the “Agile” paradigm, which were seen as corrections to the original XP model. So with “Agile”, paired programming was an option and not a requirement but nonetheless still promoted. The “Code First” strategy was still followed while planning and design were diluted with the idea of collaborative development with the user community; another concept that has proven to have mixed results since many users really don’t care how their systems get built. In fairness to the developers of both the XP and “Agile” techniques, there were two major, external forces that lent their influence to these developments. First was the excited frenzy that surrounded the rise of the Internet as a commercial medium for transactional processing, which in turn gave rise to the “DotCom Bubble, where clueless venture capitalists and to some extent organized crime invested millions if not billions in an outrageous number of new start-up companies all organized around bringing new forms of consumerism to the Internet. Such start-ups were under heavy pressures to develop new applications that would allow everyone to buy literally anything on the Internet from credit to physical goods. The “meme” born from XP made its way into these small firms who were all under the impression that they had found something completely new and unique with this new form of rapid application development paradigm. Combined with the inexperience of the new youth oriented culture of these new start-ups, the development techniques they employed against frivolous plans and goals that in many cases made little sense, all came together in the first software development business “bubble”, which eventually blew up in their faces pushing the newly minted “DotCom Era” into a sudden free-fall it never recovered from.

it's just capitalism. you can squeeze more surplus value out of workers by either increasing the length of the working day (for salaried workers), decreasing wages per hour (for wage workers) or increasing the intensity of labor performed in a standard length day (this one is the most subtle). Agile is just a way to force coders to code faster. You end up with poorly documented projects with constantly shifting expectations, annoying daily "standup" meetings, and other bullshit that actually makes it harder for everyone involved. Yes, it's a meme.

t. work on a feature-bloated AI grift project for a medium sized engineering firm with a small team.

Oh so it's like scrum but honest and without the "if you did it according to the guideline it wouldn't suck" pretense to justify it.

>>26443
Have you ever worked in a non-agile environment?

File: 1726895639477.png (411.13 KB, 647x527, falcon.png)

>>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).

>>26444
scrum is just an opinionated type of agile

>>26448
It was a yes or no question.

File: 1727165408906.jpg (128.68 KB, 1059x1536, 20240809_111432.jpg)

>>26448
Argumentum ad logicam

>>26444
>>26443
Yes and yes. And also >>26448 yes for the parts I read (sorry, in a hurry)
Agile has some good principles. Capitalism or corporate life tends to take anything and turn it into it's opposite lol. It becomes a rigid way of working that makes things move slow.

>>26448
There is always a vehement agile-hater present, and they are always correct. (If you didn't post, I would have.)
All of these methodologies become antipatterns when misapplied anyway. There is no one-size-fits-all.

Agile is just micromanagement

<the daily meeting is to get you to say that you will finish something asap and when it isn't finished in the time "WE committed to" to humiliate you in public for being a slacker

<the "sprint" structure is to get you to commit to releasing a pre-determined (feature is urgent, has to be released asap, business growth depends on it) amount of work in 2 weeks max.
<since agile is about "empowering developers", you are now empowered to commit to releasing what is needed in 2 weeks and if you can't business fails because of you. You committed to release in 2 weeks, why isn't it there?
<how fast or slow you do the work is represented by the "velocty" of the "burndown chart" or something which if it doesn't look as expected, is hard data indicating that you aren't working hard enough.
<bug-fixing is simply not a thing because why are there bugs? the requirement was explained to you in endless hours long planning, grooming, stand-up, retrospective, governance, compliance, review, etc. meetings. if there are bugs it means that you aren't doing the job properly. how hard can it be when AI can produce the same code in minutes.
<if the changes made in the sprint do not produce the intended business gains in the next month/quarter, was the change really needed? who authorized it?

>but le waterfall!! my aGiLe tRaNsFoRmAtIoN "empowered developers" to "deliver value" and "scale up" to "unicorn status"

sure you did, agile coach/scrum master/digital transformation jedi

>it's better than any other approach

no it's not. here is something miles better
<bug board with prioritized tickets
<people pick ticket and push fix
<CI/CD auto builds and releases to testing and notifies testers
<tester checks and approves or updates same ticket with feedback
<dev pushes another fix which is again auto released to testing
<back and forth until approved by testers
<approval automatically pushes change to production release which goes out whenever

>oh yeah? how do I know how far along an implementation is without my daily meeting???

just try to use the feature on the testing env and see how far along it is instead of trying to look busy by bothering people.

>yeah? how do i know how long it will take?

see the progress on the testing env, it's coming along, you can guess by the progress how far away it is.

>NO! I want it NOW!

then go to chatgpt.com and make it, according to the likes of you it's that easy, so just do it.


Unique IPs: 9

[Return][Go to top] [Catalog] | [Home][Post a Reply]
Delete Post [ ]
[ home / rules / faq ] [ overboard / sfw / alt ] [ leftypol / edu / labor / siberia / lgbt / latam / hobby / tech / games / anime / music / draw / AKM ] [ meta ] [ wiki / shop / tv / tiktok / twitter / patreon ] [ GET / ref / marx / booru ]