Agile cult is ruining software

Agile is a sick joke. If the whole point is to release half-baked products it does it's job pretty well. There are just way too many teams, way too many people, way too many things that don't matter to software. There were 5 teams working on a service with different branches because we are so Agile, now we have to merge this thing. Can't wait for that, we're being so fast and Agile!!!! How can the industry change to avoid this garbage? I miss the days where I would be approached by someone to write a perl script to solve a problem because people knew how to use computers. Now no one knows anything and I have to build soykaf garbage all day because muh end user can't decide if he likes blue or red buttons. This industry is a fuarrrking joke. Hey wagie, it's time for standup!

>>34019 The only people that care about the state of the software they are working on are programmers. Everyone else don't. Sadly, the people who decides things are not programmers.

I know very little about what these terms mean. The waterfall style seems reasonable to me, so long as proper planning takes place. This, of course, can fail when no one knows what's being built, but that's hardly a reasonable position to take in many cases. >There were 5 teams working on a service with different branches because we are so Agile, now we have to merge this thing. Anyway, the proper way to do this is to split the program into as many independent libraries as is reasonable. This shouldn't be hard.

>>34019 >I miss the days where I would be approached by someone to write a perl script to solve a problem because people knew how to use computers. Now no one knows anything and I have to build soykaf garbage all day because muh end user can't decide if he likes blue or red buttons. This industry is a fuarrrking joke. How is this at Agile's feet? If anything, I'd say things are the other way around. The market's changed now that more than just other tech firms want code, and Agile is, if not a solution, at least an industry response to keep things running. Figuring out how to make MBA customers literate won't be easy, but if they leave instead the industry just shrinks instead. >>34023 "Waterfall development" was a near-parody process Royce made up as an illustration of why naive or lax planning often fails on large projects. It only became famous because the "Waterfall" figure was on the cover sheet of some versions of the paper, and a naive and lax DoD official who clearly stopped there wrote the labels into the Department's requirements for software contractors. You might find it interesting to read the paper and see both specifically how Royce described waterfall and what he actually had on his mind: https://dl.acm.org/doi/10.5555/41765.41801

>>34019 Software is the way it is because the people in charge don't know anything about actually making a computer program and don't care to learn. It's been like this for a long time (see COBOL), but now that computers are used by civilians rather than just governments, universities, and corporations, the demand by retarded bosses for tons of code written yesterday has increased significantly. It's why things like Rust and Go exist. When you're working within an overly demanding yet also highly inefficient pipeline, the best way to deal with the sort of problems that come with it is to go with a bike-helmet and kneecaps "safety first" approach try to prevent them to begin with.

>>34019 There isn't anything wrong with “true” agile in my opinion, it's just a concept where you give developers full autonomy, make decisions democratically and have emphasis on communication. >muh end user can't decide if he likes blue or red buttons Would you not have this problem anyway, regardless of agile? >There are just way too many teams, way too many people, way too many things that don't matter to software. I've been on a team where agile worked very well. Until management decided that we should use SAFe. The issue with agile is that you don't need managers or POs at all. And naturally, people in those positions want to hold on their positions, so they come up with systems that require them. You then end up with a system that isn't agile, but claims to be. Now higher-ups can tell you what you are required to do and what meeting you have to attend, but if something doesn't go according to plan it's your problem, because you are agile, right? RIGHT?

>>34056 >Would you not have this probl regardless? Oh I'm sure I would, but it wouldn't be taken as some serious issue anywhere outside of agile.

Scrum made my previous job miserable, followed by SAFe which drove me to quit. The only "agile" methodology that isn't terrible is Kanban, which is basically a fancy queue without all the pointless BS.

Your complaints are good signs that your company is not doing "real" Agile and are definitely not adhering to the Agile principles. I've enjoyed working in Agile environments when it's done right, but there are way too many companies who think using JIRA and designating the oldest dev on a team the scrum master is all it takes. >There were 5 teams working on a service with different branches because we are so Agile, now we have to merge this thing. Why were they doing that? There's nothing Agile about that. >>34066 >>34056 Put another coin in the "SAFe is a cancer" fountain from me. >The issue with agile is that you don't need managers or POs at all. And naturally, people in those positions want to hold on their positions, so they come up with systems that require them. POs have their place. It's nice to have someone with expertise in the client's industry who takes on the role so I can just focus on programming and get quick answers to any questions I need answered. But too often, people who have no business being PO are assigned to the role. The problem with managers is, like you said, they cling to their role and adapt the system to them, instead of adapting to the system. I actually like my manager, but that's because they've adapted, so they're fairly hands-off with respect to development work. >Now higher-ups can tell you what you are required to do and what meeting you have to attend, but if something doesn't go according to plan it's your problem, because you are agile, right? RIGHT? My favorite is the higher-ups who disregard the warning of "Don't let management use story points for their metrics and do not compare different teams' story points" that is in every piece of agile literature. Bonus points if management requires you to standardize your story points across the entire organization in a way that makes the estimation valueless (and gamed by every team).

>>34019 learn devops if you want to write scripts. Seems you dont really know what software engineering encompass

>>34070 >Why were they doing that? That's what the business needed. MicroServices touch other MicroServices you end up stepping on a lot of toes. I hate it.

>We are a community of motherfucking programmers who have been humiliated by software development methodologies for years. >We are tired of XP, Scrum, Kanban, Waterfall, Software Craftsmanship (aka XP-Lite) and anything else getting in the way of...Programming, Motherfucker. >We are tired of being told we're socialy awkward idiots who need to be manipulated to work in a Forced Pair Programming chain gang without any time to be creative because none of the 10 managers on the project can do... Programming, Motherfucker. >We must destroy these methodologies that get in the way of...Programming, Motherfucker. http://programming-motherfucker.com/

i feel lucky that my company doesn't care about this stuff. if i am assigned a project, i am the only person working on it, from start to finish. i do UI/UX design, requirements gathering, implementation, and testing.. which is how it should be sometimes the customer has an idea of what they want, so they give me vague requirements.. i hack something together quickly, we get into a meeting and i ask "is this what you're looking for?" at big companies, they segment all these roles. but i love the creative freedom this affords me. the most agile thing we do is standup meetings

>>34070 From my experience, agile methodology has always been bad because it does not enforce limits or contracts. If my PO swoops in a day before we push a release to UAT because "this button doesn't animate on click", there's no contract or enforcement for the development team to tell them to fuarrrk off. Even at the good agile shops where the POs stay our of our hair, then it's just the executives descending upon us to drop soykaf. That said, by my own metric there are no good software methodologies unless they explicit mandate contracts between management and development, which I stand by.

>>34157 That is probably the best take I have heard on software, thanks Lain. It is really frustrating, on the first iteration of a product to be worrying about minute details like button animations, and colors, PO's are the worst, and execs even worse. Why did we let them into the software cycle?

>>34019 Agile was not meant to be so crappy, but nowadays is a synonym of being bad at project management and software engineering. But any tool on the hands of an idiot is worthless, keep this in mind. Agile has serious problems, but would be 90% less chaotic if people doing things where not that stupid. The current state would be that bad no matter what software process is being used.

>>34070 >your company is not doing "real" Agile Perhaps if so many companies get it wrong, then it's not good system for human beings... >>34157 >From my experience, agile methodology has always been bad because it does not enforce limits or contracts. I have never really done agile, but can't you, like, tell the PM to write you a ticket and that you will do it in the next sprint?

> There are just way too many teams, way too many people, way too many things that don't matter to software. >There were 5 teams working on a service with different branches because we are so Agile, now we have to merge this thing. Can't wait for that, we're being so fast and Agile!!!! Your teams doesn't know how to do Agile. This post has the same smell as the "OOP sux" posts. Very few people give it a genuine try, and most just complain about how it is like kicking dead whales down the beach when they half-ass it.

>>34277 It's all corporate soykaf, OOP, Agile, MicroServices, Cloud, etc. If the goal was to spend our time solving real problems, we've surely missed the mark.

>>34279 Corporations solve real problems.

>>34302 >Real problems >The button should be blue instead of red Ok.

i'm agile… but not that agile.

>>34277 If that's the case then OOP is as bad as communism, because apparently it's never done right. How to "correctly" do OOP changes every second week first it's interface segregation and "clean code", then it's inheritance, and now it's DI flavored encapsulation. Meanwhile functional languages have been doing the same thing since day one and it's still the most optimal approach. Oop sux.

>>35088 Communism's never been done right because doing it right requires a set of conditions that don't and will probably never exist, such as a world government that isn't a government. OOP,, on the other hand, has been done right many times, it's just usually done wrong. The utility of OO is that it lets you define your own data types. When you start running into trouble is when you start abusing it to do non type-related things.

>>35088 None of these terms have a real definition, its about giving off the appearance or mood of something rather than something concrete. Its a costume people put on to signal they are special or their organization is special, or to signal they're conforming to the group. People get offended when you point out practical problems or ambiguities because its a fashion statement that they've internalized as part of their image.

>>35091 Yeah that sums it up pretty well. This is especially apparent in most enterprise jobs, where any slight deviation from their image of how they think code should look will result in a blocked patch. It's funny because I'm neither a functional or OOP zealot, I'm simply interested in writing code that makes sense practically, which often times is a fusion of both styles. Despite this I often get bad looks or judged because I don't pick a side. It's almost as deranged as Agile [spoiler][/spoiler]

There is a certain irreducible or unchanging set of characteristics of software development- things like iteratively reaching a solution, adapting to changing requirements, communicating system concepts amongst the team, and deploying and operating the software. Using an agile approach just means acknowledging this as the core of the software development task and organising efforts towards performing that core work efficiently. Anything else still has to arrive at the core but does so in an ad hoc and inefficient way, delivering late, low quality, buggy, unmaintainable etc. software.

>>34019 while its true that agile is just some fad bullsh1t like keto vegan gluten free, before agile things werent any better it was still incompetent, bureaucratic corpos incapable of understanding how to into electronics / software you still had some fagget come up to you saying "i want a blue LED on the product", "i want a web interface", etc

>>34253 >Perhaps if so many tribes get aviation wrong, then it's not good system for human beings... Seriously, though. Pretty much everyone involved in founding xp and agile have been trying to tell you that your company's scrum consultant doesn't know what they're talking about for about a decade now (ie https://youtu.be/a-BOSpxYJ9M ). Managers are the waste "literally just toyota production for programming" was meant to remove since the beginning, and it's on you at this point if you don't point it out when your pm says "Agile means more meetings with me so I can micromanage things I don't understand more". If you missed that opportunity because you let your enemy tell you how you should want to work, our only hope is to read the primary sources and language lawyer them out of credibility. They're not even making money, so they don't deserve to tell you what to do. >>34132 >sometimes the customer has an idea of what they want, so they give me vague requirements.. i hack something together quickly, we get into a meeting and i ask "is this what you're looking for? >the most agile thing we do is standup meetings See? If you refer to the most agile thing you do as "not agile" and the most hijacked as "the most agile" you're following the rest of the herd into the elephant trap. If you're not ready they're going to take your freedom from you sooner or later, and you might not even notice.

I think you're just tired of modern corporate culture, OP. You might associate that with Agile since it's a buzzword retards like "evangelists" who don't know tech love to spout to seem cool but really you can find that cancerous culture in other fields as well. I wasn't working back then but I'll take a guess that in the 70s, for example, wagies weren't forced to do bullshit like "team-building exercises" and to model their entire online presence outside work hours (could be "social presence" back then) on what's trendy on Linkedin, and it's things like that which ultimately result in stuff like a MBA or HR retard taking up useless positions in "scrum rituals" and the like.

>>36868 All of Agile and it's flavors force wagies to go through wagie Olympics. That's what I really have a problem with. I'd prefer to just be talked to like a human by the people who I'm making software for, then solve the problems they have. That's it that's all.

>>36869 Strictly untrue: >Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. With all due respect, read the fuarrrking manifesto. It'll do you a great good.

>>36875 The manifesto is a bunch of garbage. Hurr durr people before tools blah blah, the problem with the manifesto is it assumes every developer is the same. Its as if 10 dudes who wrote banking software in Java attempted to formalize software, development oh wait that's exactly what it is. It's seriously set back this industry so fuarrrking much, and if you can't see that you should probably stick to writing Java banking software.

>>36882 Facts not in evidence. If you've got a specific issue, point to its source. If you can't complain without hand-waving, you're just wasting bits on spilling your soykaf.

>>36890 >Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. That sentence alone is hand waving. Hmm give people the things they need to succeed. Wow, really took a genius to come up with that one. The manifesto is so vague that it is DESTINED to result in miss-use, but just like Communism, it has the "utopian" vision where people can completely ignore any criticism via saying: "Well that's not real Agile. Read the manifesto!" If you've actually bought into any of this you're too far gone. Agile has contributed the most out of anything to the babyfication of developers. Developers aren't seen as professional, they're seen as lackeys who solve problems for the smart business folks. You don't see Mathematicians, and Doctors doing a 15 minute stand-up everyday before they can do their fuarrrking job.

>>36894 To be fair, infantilization is pretty common place in nearly every facet of society. (Yes, yes, the funny meme word that, when said, you're just being "edgy" and "funny" and not to be taken seriously because we say so.) We have people who actually utilize babytalk and negrofied english, or I guess "African American Vernacular". It's no surprise that companies utilize things like agile to keep everyone playing in the correct sandbox. You're right, for what it's worth. The manifesto is smiley-glad hands talk. It's like saying "Just do it" - This has no real meaning, you apply the meaning yourself. That's why it works so well, these used to be called "watchwords", by the way. >>36875 I was forced to take a class for this and I did read the manual. It trains you to be a cultist. The first thing they teach relies on circular logic which is basically a sales pitch on "why its good" (pro-tip: It ain't), then they put in the happy nice glad words, then you get a framework. Grats, this framework is the basis (you tell yourself) but it isn't. The basis is being brainwashed into defending a framework that exists to create a role that was never necessary in the first place because boomers literally buy whatever shiny bullshit thing they see. See: six sigma. Be careful, you might notice a crazy resemblance and I know that cultists get violent when you start to shake the foundations of their worldview.

>>34056 >>34066 >SAFe OP here, my company recently went to SAFe as well. It's fuarrrking over and I'm looking for a new job. Somehow, someway, they made Agile even worse. When we were on Scrum at least it was just standups and the usual "rituals" not a cult BTW. But now we have to come together for PI events every X months, where we sit and talk about NOTHING. We need feature Y here's everyone who might be involved in it, plan the next 3 months of work with these people who have 0 fuarrrking clue on what is going on. This soykaf is disgusting.

>>36896 >We need feature Y here's everyone who might be involved in it, plan the next 3 months of work with these people who have 0 fuarrrking clue on what is going on. 3 months later, work is behind schedule because management threw a bunch of new tasks at everyone in the middle of the PI, because some of the no clue people at your PI planning insisted you reduce your story point estimations just to squeeze everything they wanted done into your PI, and because some of your team's stories relied on people outside of your team but cross-team collaboration has gone to soykaf because every team is obsessed with proving Goodhart's law correct.

>>36904 Yeah. I really wish I could go back to a world without analysts and all the other soykaf roles. I remember the days when I would get emails from the business asking for the ability to do X on our Unix machine and I would slap up something in C, Bash, Perl or Awk along with a man page, and people would happily teach them selves to use it. I sure miss those days.

>>37249 I dream of finding a job that still operates like this, or at the very least is a role where I am the sole/primary tech lead and can direct the company towards something like that. But as you said, those times are gone now, and I truly doubt they will ever return.

>>34019 This compounded with the Clean Code movement, has been an absolute detriment to software quality. I have nothing against OOP (except for Java), I think C++ and Ruby are examples of OOP that can be done correctly. But the idea that you should follow patterns in all of your code blindly is absolutely retarded. The only one that makes sense is DRY. Then when you combine "Agile" with this Clean Code cult you get such a mess. Just look at all enterprise software, its slow, hard to work on, and an absolute nightmare to debug. Agile is part of it because of its use of force when it comes to constant refinement of a single idea, rather than looking around, and the Clean Code is just the double whammy.

>>37493 Ruby nor C++ really do OO correctly. See Cook's argument here: https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf Note that smalltalk, does OO quite well, and would give you a good feeling what OO feels like quite well. Shoutout to CL's MOP as well, which has a lot of the tradeoffs nicely mapped and moslty does follow cook's argument properly (though multi dispatch does go against the central thesis in a way).

>>34019 You seem to be confused on what agile actually is, which isn't surprising as most things that are "agile" are labelled wrong

>>37499 Have you read the thread? Agile is just a bad idea, its a Utopian idea that never can be executed properly. I don't care whats labelled what, or the ideas behind it, or how good it "could" be. It obviously can't be practically executed by humans, because according to Agile purists "this isn't agile", and "that isn't agile" no matter what. So it shouldn't exist.

>>37500 >"Agile's inventors always said it was X; you can't blame it for Y or Z causing your problems." >First agile isn't Y, and now it's not Z either? You must be utopians with no definitions. You're a waste of time. How does zero seconds of time qualify as waste? >>37493 >I think C++ and Ruby are examples of OOP that can be done correctly. "If this were physics you would all be dismissed from the field, because physicists would not tolerate somebody being in physics and not knowing quite intimately what the pioneers and developers of physics actually did. It's not an optional idea. But in computing, people seem to think that it is, so part of my thing to get you to ponder is I don't think computing is a real field. It acts like a pop culture. It deals in fads, and it doesn't even know its own roots, and worse than that it does not know about the really good things that were done in the past." -Alan Kay >>36896 >We all stopped trying long ago, so now management's followed our example and is no longer pretending we're doing agile either. You do it to yourself, you do And that's what really hurts

>>37500 Not them, but agile really isn't some unobtainable utopian idea. I've been on teams that were "doing agile right" and it was great. I remember one team in particular was fantastic. Most days were just a 5 minute stand up meeting, then programming the rest of the day. Once a week we'd spend an 15-60min refining the backlog. User stories were always well written and almost always all we needed to write the code. When we had questions, we'd send a message to our PO who usually responded within a few minutes. Once every two weeks we had a retro, which lasted 30-60min and a 30min demo. Sprint planning was usually 10 to 20 minutes. our ceremonies took up maybe 4 hours out of the 80 work hours and it always felt like time well spent. The best part was management stayed out of our hair and actually went through our scrum master whenever they needed us to do something. I miss that team.

>>37503 OOP in smalltalk is just dynamic dispatch/ virtual functions. C++ like most big languages has this, so they can do smalltalk OOP fine. The issue is just that the languages are booby trapped with horrendous "features" that only appear useful, some of which the modern OOP cult is obsessed with.

>>37522 > OOP in smalltalk is just dynamic dispatch/ virtual functions. Not that lainon. But it seems you don't know what you're talking about. Smalltalk and and class based style OO, has meta classes, which CPP lacks. You should probably get more familiar with smalltalk and the surrounding family (self, beta, even the MOP for CL is fairly solid). Also read cook's argument: https://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf

>>37523 I should probably add, even Java has reflection, which along with metaclasses lets smalltalk heavily modify it's own environment and build up a consistent system to present to the programmers. This sort of environmental controls allows some very nice patterns, even you letting you write static checks over your OO code. Really a lot more is done when working with a truly OO system

>>37523 >>37524 I have never heard anyone say before that reflection and metaprogramming with the capability to create and modify classes is a key part of OOP. Sure, if that's what people mean when they say C++ & corporate Java are not "real smalltalk OOP", then you're right C++ doesn't support that. (And it would be hugely useful to have reflection and real metaprogramming in c++.) But I'm unconvinced that's what they really mean as it would be easy to say so yet I've never heard that before, instead hearing things like "real OOP is about message passing not objects".

>>37526 OO is about objects. Messages are objects thus if you say it's about messages then you are saying it's about objects. I was pointing out metaclasses and reflection as these details are apart of a properly thought out OO system. The lack of these systems is why the languages need a lot more primitives, as the system doesn't compose itself from objects themselves. People go as far as to say Smalltalk isn't a programming language but an object system unto itself. You really should read cook's argument, it covers how Java isn't really object oriented in practice nor too much in theory either and what the difference between Objects and abstract data types. Arguments by girad brancha also reinforce this by arguing that static typing allows languages like Java to be less principled (fields are an example, in a dynamic system it has to be a message send, as one does not statically know if it can even be a slot access) You should play with pharo: https://pharo.org/ It's a smalltalk.

>>37527 I'm really not sure how you took away the idea that the paper "covers how Java isn't really object oriented in practice nor too much in theory". In fact, there is half a page dedicated to how you can accomplish object-oriented programming in Java that satisfies the contract laid out by the paper. Not to mention that the essay openly admits that there are multiple valid definitions of OOP, and this essay only describes one of them. The essay does not describe Java in such blunt terms, and instead takes issue with the fact it combines ADTs and Objects into the same syntax, operates with primitives which expose representation, and provides tools to break the encapsulation of objects. Hence it does not follow the essays contract, but it never makes the assertion that it is "not really object-oriented". Furthermore, the essay openly states that reflection can be a means to break encapsulation, thereby not abiding by its object-oriented contract. Which that can be a separate debate on the merits and detriments of reflection, as I agree it is a near fundamental pillar of any sufficiently robust OO system. I must admit, your description of Cooks argument nearly set me off reading it outright, as it sounded like it would mostly be disparaging drivel to accommodate and promote the style he liked more. That said, thank you for linking the essay nonetheless, it was a very pleasant read that shed much needed light on the distinction between ADTs and Objects, and put forward a contract that I find rather enjoyable. It was also the push I needed to finally give Smalltalk a proper try.

>>37531 > In fact, there is half a page dedicated to how you can accomplish object-oriented programming in Java that satisfies the contract laid out by the paper. Yes however this is quite strained for Java code. In theory there are a lot of additions that move away from the spirit of OO, and make writing OO code much less natural. When one grocks the style and ideas, one can apply it to most languages, with statically typed languages being the biggest barrier in actually doing this due to the potentially odd constrained had by the type system. > Not to mention that the essay openly admits that there are multiple valid definitions of OOP It's been a few months since I've last read the paper, however the biggest issue with most other definitions of OO, is that there are typically not good distinctions from other forms of programming. This often leads to me making a satirical argument that Haskell is a good object oriented language due to the poorly throughout nature of most approaches. The few other interesting approach to a definition align much more closely to Cook's definition (you can read about μcalculus in TAPL in the OO chapter). The overall thrust of my argument is that it is improper to judge OO languages by Java, C++, etc. Much like how it is improper to judge FP languages by JS. These are the paradigms in very weird and twisted ways that don't really show the throughline of the ideas. After going through smalltalk I've had a better appreciation for Java and Scala, even if I never want to touch them. I will add a small aside, in that Erlang is oddly rather OO in how genservers and the message passing works even if "objects" don't exist in the language. > I must admit, your description of Cooks argument nearly set me off reading it outright, as it sounded like it would mostly be disparaging drivel to accommodate and promote the style he liked more. Most of the arguments about OO from my view is from more proper considered OO systems. A more considered language could be used, however when responding in haste, it is far more effective to point out parts as to why the OO systems mentioned in this thread as subpar and not fully considered/fleshed out. If you want a more high brow debate between different factions in principled OO systems, there is a good article in [2] that describes the shift in computer science languages and what is and is not allowed at conferences, how attitudes have shifted, etc etc etc. Further I would like to link [3] which has the argumentation about fields. It also pushes forward a rather interesting type theory idea that should be accepted. Something big you'll see in this is that Smalltalk guys sort of push past languages (this is ironic as [2] is arguing against the author of [3], however he is a systems and not a languages guy at the end of the day.), and wish for stronger computing environments. This is why big IDE's are a poorman's Smalltalk environment. Language design in general is second class compared to the system it is composed on either way. If you want even more discussions, I'm in #programming in the IRC. Just announce you are looking for the annoying guy and likely someone may point you to me or I may respond myself. [1] https://www.cis.upenn.edu/~bcpierce/tapl/ [2] https://dreamsongs.com/Files/Incommensurability.pdf [3] https://bracha.org/pluggableTypesPosition.pdf

>>37532 >Yes however this is quite strained for Java code. In theory... It absolutely is. Java provides far more to the user than OO systems alone, as you stated. I only really brought this point up to challenge the notion you stated earlier, as I found it too reductive to be of any real use. >The overall thrust of my argument is that it is improper to judge OO languages by Java, C++, etc. Much like how it is improper to judge FP languages by JS. I can certainly get behind this argument as well, as I would agree. It's improper to judge any paradigm by multi-paradigm languages as a generality in my opinion, as usually the priorities of the language designers are not to abide by any paradigm other than their own specifications. Some will argue that those end up being the more "useful" languages, but that is perfectly fine in my mind. Some people want the tool, others want the entire toolbox. >Most of the arguments about OO from my view is from more proper considered OO systems. A more considered language could be used, however when responding in haste, it is far more effective to point out parts as to why the OO systems mentioned in this thread as subpar and not fully considered/fleshed out. I certainly understand, but I will point out the downsides of the approach nonetheless. Especially on a board such as this, I generally avoid haste as it provides no real benefit in my mind. Of course to each their own as well, I hardly want this conversation to devolve into unwanted advice hurling. Thank you for the additional resources! I will certainly be reading them as I work on picking up Smalltalk. I am very curious to see how I feel about your mention of environments, as I will likely be using GNU Smalltalk during my journey for a myriad of reasons. But I have fallen a little too far down the GNU and POSIX well to be helped in that regard, so it is what it is. You will likely see me joining the IRC at some point in the future as well.

>>37504 >I worked on one team one time and somehow it worked great How is this argument even an argument? You got lucky and the people you worked with weren't retarded. I'd chock that up to being the reason it felt good more than Agile.

>>37536 It's just a counterexample to the claim that agile is some utopian idea that never can be executed properly. Clearly that claim is false since I've seen agile executed properly multiple times.

>>37539 Yes you've seen it executed multiple times. But you don't give any context. Which makes me 1. not believe you, and 2. consider the fact that you got lucky.

agile is an empty platitude, it's just saying "do well", then taking credit for success and saying failure wasn't true agile. agile doesn't deserve credit for success or failure.

>>37540 What context do you want? There is nothing I can provide for you beyond "I'm a developer who's worked on multiple agile teams, some of which had implemented agile effectively" without uselessly doxing myself.

>>37565 Create Jira stories next sprint for each member of your team to come to this thread and testify that they’re doing agile properly and never contemplate prostitution, waste management, or suicide as valid alternatives to showing up for morning scrum.

>I miss the days where I would be approached by someone to write a perl script to solve a problem because people knew how to use computers >i miss the days where i could add an RCE vuln to my product and dildo myself thinking im superior to real programmers because they had to spend an extra 5 minutes adding imports to their source code i dont miss that at all, and agile is a dead meme from 2010, the real problem is that in any company the boss will just be a braindead retard monkey and cant even delegate properly. which doesnt matter since you still are surrounded by retards who think perl is a thing and an entire architecture designed by the misconceptions of such losers.

>>34027 Interesting paper. It's not a "parody" but a starting point for what he describes in the rest of the paper. I think OP is right though because what Royce describes directly opposes Agile. He puts so much more emphasis on documentation versus Agile's "code is documentation" mantra. He also emphasizes a rather large and arduous process to finalize the design, while Agile is ready to accept requirements changes at any point. Now that I re-read it, the Agile manifesto says more about how to manage software teams than the process of designing and building software. A lot of the points are about how to do meetings or who to delegate decisions to.