Can you do rraction video where you talk about that, as you watch this video?? You watching him watching you.. it would be absolutely hilarious to just keep going back-and-forth and make an infinite chain of reaction videos to each other
@@systemlocLOL. Maybe someday. Right now, my channel is too new (~5 weeks old and only 11 videos), so I need to keep a consistent format for another couple of months at least so that the algorithm doesn't get confused about what kind of content I'm posting.
They try to do agile at my job. I'm in fucking hardware. I fix CCAs/ harnesses that fail when we test the F18/C130 generators we make. The only roadblocks are a failure of management. They don't ever implement solutions because I'm just a dumb ass solder specialist in their eyes. A year later, they fixed the problem the way I suggested in the first place. We're so agile.
Your code can never be that bad. I would say those refusing to work on that project are idiots. If those refusing aren’t willing to help out and fill the gaps where your knowledge is lacking then they aren’t in a place to complain either. Working together and sharing ideas about how to solve problems is the only way.
@12:12 - OF COURSE SCRUM FITS INTO CONSULTING! The agile manifesto was written by folks who were consultants, and they wrote it from the point of view of consultants. It was a response to consulting jobs where after 3 months it was obvious the thing being built was not wanted, and then after 6 months the obviously wrong thing was shipped. In these consulting jobs, the original deliverable was never revised nor discussed periodically. The manifesto basically said, "instead of this, work with customers to develop their ideas and give them a little bit at the time frequently, so that they can help decide the next direction (which might be redoing the thing that was just done)." This is a model that can keep a consulting company around for an indefinite duration. The trade-off was supposedly that value is continuously delivered, so if you want to keep that value stream - you keep the contract open. Contrast that with being 3 months into a project and knowing already that it should be cancelled, and the whole thing is thrown away with zero value delivered.
It's strange how agile is always used as a synonym for Scrum. I tried the agile (not Scrum) approach last year. We (two senior devs) were asked to build a web app that 3 companies already failed to develop for the customer. The customer had a business idea, but no idea how to properly define it. They tried to describe it in a technical manner to us, but we stopped them in their tracks and asked for the actual goals they want to reach instead. Then we basically threw their software concepts away and we showed them our first prototype after a few weeks. They were completely blown and they told us that we had made way more progress in less than a month than the others in more than a year. Of course it wasn't perfect, but they gave us their feedback what was most important to them and we asked them to schedule a short meeting whenever we were close to running out of work. We got the contact information for their "specialists" which we contacted whenever we've had specific questions, but there were no daylies or anything like that. We did most of the work in pair programming and did code reviews for anything else. In the beginning I documented most of the stuff using Obsidian, but we started to use Notion after a while. The project is live by now and the customer is still very happy. Since the customer sometimes asked for fixed prices, we calculated how much the same would have cost if we would have built this in a fixed price scenario instead, and we came to a factor of four for both the costs and the estimated time. So whenever someone says "agile bad", and then talks about Scrum, it makes me sad. Scrum is usually just waterfall in small increments with stupid ceremonies on top. And why was Scrum invented? Easy. Just look what Scrum certificates cost.
This. We, as technical people and devs have been fooled. It doesn't empower us, it isn't by us for us. Not even close. We are fools repeating ceremonies blindly like a cargo cult
@@errrzarrr there's a lot of that, but there's even more "we the devs haven't been fooled, but we're forced into a stupid system by the higher-ups who got suckered and swindled by some Agile Coach." One thing I really hate (which should be part of the video I'm working on now about tech interviewing) is when buying into the ridiculous Agile fad of the day is a Requirement for even getting an interview. (I turned down a project recently when in learned the company in question was planning a SAFe rollout in the coming months)
Ok but wait, the idea of going back and forth with the customers is a good one, right? It's like hiring people to do work around your house and going to a vacation for a month -- it's not going to end well :)
This is something I've been saying. Management wants engineers like Devin. But good software isn't made by engineers like Devin. But "good enough" software is.
Not quite. Because of the indeterminism of LLMs (statistical model fed with data) you do not even know if the code generated will meet the status of being "good enough". And when the customers change their mind like others change their socks the codebase might not even converge to maintainable anymore. But churning out documentation with at least some doxygen-hints... this is doable for a LLM.
LLMs can't reason, and can't create anything novel, so they'll never replace even the most junior programmer. They'll just make all programmers more productive (and valuable).
@@SimonWoodburyForget you've missed the point. Producing software is not only about churning the code. I would say that coding is one of the last steps. And increasing productivity doesn't mean that ppl would write more code in the same time Software is like puzzles - it's about solving problems. The customer may want "something to generate invoices based on the orders list from online retail, and to automatically send these invoices by email". And it gives you at least few weeks of work - you need to find a way of auto-exporting data from sales, process this data, generate invoice in proper format, validate output and send emails No LLM could do this - they struggle with solving of elementary school exercises. It may be helpful in summarizing docs for every step and/or in providing a boilerplate code for needed functions, and maybe some testing. But it's still a human who would need to do 90% of the work. It will never replace humans. At most it will change some 1X programmers into 2X. But ppl will keep their jobs
@@SimonWoodburyForget I'm not using Vim and didn't write anything about it, and I don't work at corpo AI will not decrease value of programming. There's just too much work. It may hurt some junior positions, but there is still shortage of seniors in every area. I think you don't understand how software works. If my team had finished "twice as fast" (I guess that would mean delivery in 6 months instead of 12), then we would start maintenance, adding new features, refactoring and cleaning the code, addressing tickets, and many more stuff - if we were paid hourly wages If we weren't paid hourly wages - we would still get the same amount of money, because we got paid for the completion of contract. This situation is even more beneficial for workers, because we could get more work done in the same time, and thus complete more contracts Following your logic you can say that spending half of the workday in the toilet or at useless meetings would mean that my work gets twice as valuable, since I work 4 hours, but got paid for 8, thus doubling my income.
I started programming in the 80's. Agile is just a mini waterfall, with more status meetings. Customers are usually managers (or worse bean counters) and rarely end-users, that is, always was, and always will be the disconnect.
I'd just like to interject for a moment. What you're referring to as Agile, is in fact, Scrum/Agile, or as I've recently taken to calling it, Scrum plus Agile. Agile is not a methodology unto itself, but rather another iterative approach of a fully functioning Scrum framework made effective by the Scrum core practices, ceremonies, and vital roles comprising a full Agile project management system.
I'm with you that the terminology is messed up. I would clarify it as this: agile project management and agile development are different things. Scrum is an implementation of agile project management. Whether the development in practice is agile or not, is independent of the project management. My 2 cents, the place to focus on is agile development, once that is in place, the project management part becomes almost trivial (at that point the Scrum Master, Product Owner & Project Manager roles are no longer full time jobs; instead, those should be roles, as-in, our PO is the person that is going to use this system the most, vs some business analyst with a fancy title that knows nothing about the subject domain).
No, crunch was normal under waterfall. Scope of work and delivery date were both set in stone. Agile has its problems, but, as usual, the new problems are less bad than the old ones.
19:50 onward. This is right on the money! Thank you Primagen. Great advice too. I'm the end-user of 7-figure software packages and I've been witnessing this first hand. The founders are in the Bahamas and the H-1B's are busy driving the company into the ground
Games Publisher I used to work for but somebody from QA/CS in charge of Agile/Scrum ,Sprint planning and morning stand-ups for the IT Teams. They had no experience in IT Admin, Dev or Architecture. But since they were also an unoffical PA for the CTO and did all his slides and reports we had to argue with them to get realist time-lines on issues/projects. It too 2 years to get "root cause analysis" on outages but since the web dev team has their sprint planned out they would refuse to even look into issues we found and needed fixed ASAP.
It's like these Agile lords, 99% of the time non-technical people, are a burden and delay to the technical team instead of empowering and making things better
@@errrzarrr Exactly. The best managers were the ones that were able to take those distractions away and allow their engineers to focus on the work. Flow is really important when you want productivity. So is writing tools, which can 10x productivity but never gets prioritized on sprints like features do. And people forget that software development is also a very creative process in addition to technical. You learn a lot on the way and need the flexibility to pause, reinforce, refine and iterate in addition to building if you want to make something truly special.
The problem is that software is so soft and so explicit that the software IS the documentation. Really the only way to verify that it does what it should do correctly is through tests. So tests document the requirements. So, all documentation from software is derivable. The problem comes from non-software engineers getting into the mix. Software doesn’t have a person in the C-suite with specific software engineering training and experience (which it should), and product managers and UX teams who don’t have software engineering training have gotten into the software engineering pipeline. I’ve seen software engineers being pushed down to basically factory worker level. The lowest rung on the organisation hierarchy. It makes no sense. No other professions do this. You don’t have a non-engineer managing engineers building airplanes. You don’t have non-doctors managing teams of doctors. You don’t have non-academics leading teams of academics.
You’re right- it’s rare to find software engineers who become business people. And that’s what it takes to sit in the C-suite. How many great developers would rather be networking and meeting with customers and salespeople and investors. Because that’s what it takes. And the tech industry needs more technical business people, not MBAs
I 100% get the hate for Agile. I'd like to add some personal experience here. For about a year, I was the Scrum Master on a web development team, and this was one of the happiest, most productive teams at the company for the entire duration I was on there. Word is they're still very happy and productive. And I think the reason we were in such a good place was when we formed the team and were told to "do Agile because everyone else is doing Agile," myself and the PM nodded, smiled, and then immediately threw out 90% of the Agile bullshit everyone else was doing. Story points? Gone. Fibonacci shit? Gone. Everyone spending half their fucking day in JIRA? Gone. We capped our morning standup at 5 minutes, and if you didn't get to say your part, you'd just give your update in our group chat. The PM and I did a lot of the backlog grooming ourselves without wasting the rest of the team's time. We made sure to capture everyone's feedback and input so the backlog was usable and accurate, but people provided that data on their own time and not during a super-expensive meeting where everyone would sit in a room full of highly paid engineers for two hours so they could give a 10-minute update. For the sprint review meetings with our stakeholders, our PM did the lion's share of converting our work data into the kind of metrics leadership wanted to see. That PM was our MVP, no doubt about it. On the flipside, we had a sister team that was "doing Agile the right way," and they were MISERABLE. Standups that lasted 45 minutes. Backlog grooming that took an entire afternoon every 3 weeks. Those folks learned to hate JIRA like I've seen few people since hate JIRA. And even though they did everything "right," they were constantly behind on everything. Traditional Agile, in my experience, is a cargo cult. But there's nothing that should stop you from changing Agile into something completely different that works for your team, say it's Agile to make management happy, and call it a day.
I really appreciate this comment. It sounds to me like the team you lead were doing "agile development" with a thin layer of "agile project management" on top. The other team was doing a thick layer of "agile project management" and the development was not agile at all. I would recommend this podcast to you: ruclips.net/video/9N4ZgNaWvI0/видео.html "Product management theater | Marty Cagan (Silicon Valley Product Group)", really gets into the distinction of agile development and agile project management. The thesis of the podcast is largely that agile project management & agile development are different, agile project management requires agile development to work well (the inverse is not true), and when agile development is implemented, most of the project management stuff becomes moot and no longer a full time job.
A typical Scrum master; thinking Scrum equals Agile. That said, I do agree with what your team did throwing out a lot of the Scrum process, it was actually Agile ("people over processes").
@Tailmonsterfriend So you had JIRA items but didn't use points, and the discussions were taken offline? That makes a lot of sense. But technically (it might sound like "no true Scotsman" now lol), daily _standups_ are meant to be short (hence "standups"). Unless you also did away with 2-week sprints? How about retrospectives? I find those rather useful to address things that got ignored during the sprints.
I'll tell you right away that the things you threw out were neither Agile nor Scrum. Except for cutting 10 minutes from the daily timebox, and that is a change I definitively approve of. I don't see the point in those meetings. All in all, great mindset. One thing I used to do when I was a PO back in the days was that I would plan refinement of future sprint goals into the sprint itself. This resulted in exactly what you describe: "The PM and I did a lot of the backlog grooming ourselves without wasting the rest of the team's time. We made sure to capture everyone's feedback and input so the backlog was usable and accurate, but people provided that data on their own time and not during a super-expensive meeting where everyone would sit in a room full of highly paid engineers for two hours so they could give a 10-minute update." I do have to ask, however, how was work data coverted into metrics? Reviews are for qualitative analysis, not a quantitative. Meaning you show what you've delivered, and then get feedback on if it is good or not, and then present your plan on what is coming next letting them give their opinion. I don't see the part where the metrics come in.
I loved the idea of "scale your project until it fails". There's something beautiful to this idea. You stress both your abilities and the technical capabilities of a piece of engineering so that you can learn to better maneuver the ship. I've failed 6 times over 2 years of trying to create a compiler for my own programming language, and I am really amazed at how much I've learned from it
2:25 sums up Agile and especially Scrum. Never-ending "sprints" (how is it a sprint if you just did another sprint right beforehand?) and nobody *ever* finishes everything in a sprint, so the team gets to talk about it at every single retrospective. The ones that worked were Extreme Programming at a startup in 2006, then Kanban in the mid/late 2010s before some Scrum consultant arrived and fucked it up.
Waterfall means you have to do each phase of what you would consider part of an engineering process. Saw a project fail so hard because they spent so long making diagrams and tweaking power points that by the time the got to deployment the licenses and support for the project were expiring, and during the few months where the system was both deployed and supported it had tons of layered bugs because everything was unstable with no know good state. Worse yet, that release and forget process meant everyone that worked on it were put onto the next project rather than getting to just fix the last projects bugs and get it to stable. I'm a big DevOps fan myself, the tighter the loop between the devs of an app and production the happier I've been, and keep their scope tight and clearly delineated from other teams.
Waterfall is the first attempt to industrialize engineering. Agile addresses the bureaucracy of waterfall (most of the products produced by waterfall are to give management warm fuzzies not make things). DevOps address the fact that without running systems stakeholders don't actually get what they want. Platform engineering address that giving teams flexibility or being too prescriptive because a nightmare to support. We are getting better at industrializing engineering, finally, so automation tools can really start to have a place in it. CI/CD, and now LLMs can start to make sense depending on where you fit on this spectrum.
> Worse yet, that release and forget process meant everyone that worked on it were put onto the next project rather than getting to just fix the last projects bugs and get it to stable. I've seen this a lot in scrum teams. I think that 'release-and-forget' is just bad management. Speaks to a feature factory, being 'story-completion' driven instead of outcome-driven.
@@AndrewMorris-wz1vqAgile "replaced the bureaucracy" of Waterfall with unecessary ceremonies and kid games like poker planing 😂😂😂😂. Interesting tasks divided into tiny not interesting tasks that will need refactoring cause the goal is just to remove your sticker....
Then you you have crap code review and poor structure as "getting rid of your sticker" means you e done it and if you think that means you're creating code that n eds refactoring that means you haven't created standards, enforced them and have very little mentoring from seniors. Writing code is not just whipping out some if else crap. Agile is a methodology that's more than pointing. Obviously you're not a senior and if so, not a well developed one. @@souleymaneba9272
For me calling "ceremonies" the meetings and other weird things proposed initially with the intent of making it standard across programming its just another example of purposely mystifying an already niche profession so the normies would freak out on what that niche of people is doing, to harvest division eventually for political purposes. Happens a lot.
As someone about to graduate an engineering degree gannt charts were required far too often in projects. Almost everyone I know just completed them all retrospectively once the project was done.
Makes sense. Software engineering is usually more akin to writing a fiction novel than it is to (for example) building a road. Being a software manager is more like being the chief editor at a newspaper than it is the foreman at a construction site. You can gannt out what it takes to deliver tomorrows newspaper, and maybe that might help somewhat, but it doesn't make a lot of sense to gannt out every newspaper for the rest of the month in advance.
I didn't finish the video yet, but I need to say that you are on fire. One pun after another. Your creativity fluids are flowing like mad after being unshackled by a classical employment :D
The advice in the last few minutes are golden. Sometimes you won't see things coming off the rails for 2-4 years, but it totally happens. Thinking about the long term is important, but it's also important to remember that what you write will eventually become someone's legacy product at some point. That's why my slack bio at work says "writing tomorrow's legacy software, today!"
Healthy Sofware Development has a great series of what agile and scrum actually means. I'm the current scrum master in our group. We have never been agile nor is my role meaningful. My first action was to shorten and cut out meetings. Not erase to please managememt, but got 2 - 3 more hours a week for everyone to actually code instead of waiting to report what they do.
1:58 "Agile is just Waterfall"... Nope, this is "Rapid Development". The part most people miss is the definition of "rapid" meaning "a series of small waterfalls".
Stand up meetings are the worst. They're there for two kinds of people: 1- the clueless manager 2- the clueless developer We stop production and get our staff out of "the zone" for clueless people who can't figure out what's being worked on by looking at the backlogs.
About Agile being waterfall but with a Kayak singlehandedly trying to safe your life: absolutely true... Except when we had Waterfall they were honest about it and didn't pretend it wasn't. Management did their work of managing, while in Agile the developers have the burden of doing technical work and manager's work. A double burden without the benefits. Back in Waterfall, yes management got the credit when things succeed but at least they did their job. Now is the Scrum Master and PO taking the credit. Last but not least, I think this is the most important one: when things went south management took the responsibility. Now with Agile they blame technical team for not being managers and *"Not being good enough to do Agile correctly."* This last one I think is why the industry adopted Agile so fast without resistance. Not because it _empowers_ devs, but because managers can keep their seat without being blamed.
My first job out of college had a release every few weeks to a month on average. We used some agile like stuff, but definitely loosy goosy with it The language was vb6 for the code base This was like 10 years ago, at that point vb6 didn't have an officially supported development environment (the IDE was no longer supported as of 2008) I still find it wild I coded a monthly released project in vb6
Our project may have had some 3rd party 16 bit plug ins Getting that to work for the dev environment was 'fun' Before I left I think there was multiple versions of my virtual machine on like 5 employees computers because no one wanted to get it working again
I love Internet of Bugs. He's had the most real talk about "AI". Something he'll probably be discussing at length for a while in an attempt to quell the hype/fear/fearhype. I'd like to hear what he says about other things as well though, so I guess I'll have to wait a bit.
The core part about agile vs non agile for me is: You work on an MVP. The "old" way (the GANTT chart) is: you spend days / weeks planing the next 2-5 years and then you stick to it. Yell at people for not meeting the deadline you set 18 months ago. No Flexiblity, no "spin-off", no MVP. Just get "it" done. Sure you have a burndown chart now (which is GANTT minus the excact dates). Yes you are expected to say how long it roughly takes. But noone in their right mind would take all the items in the backlog and build strings out of them and then tell you what the critical path is. This for me is the "classic" way of doing it. I don't really understand the hate on agile, sure it can be taken too far. But at it's core I think it makes a lot of sense.
> Yes you are expected to say how long it roughly takes. I think this one of the most mis-understood parts of scrum. The point of estimation is *only* so you can pull in a reasonable amount for the *next* spring, NOTHING more. The estimate is not so we can say: "gee, we do 30 points a month, we have 90 points in the backlog - ergo 3 months to finish." That is *not* the point. In 'scrum', you should also ask, "in the next 3 months, how many times will we change directions?" If you ask that, then it's pretty clear that "3 months to finish" estimate is worthless. Agile/Scrum is a whole tool to make delivery *less* predictable, but bias towards delivering actual value and building on that. It's not a way to make a project more predictable, and I think so many people lose this & forget that you can change direction as soon as you figure out that the backlog is "wrong." In a way, Scrum/Agile are more a method to validate that you are working on the correct thing, and to provide feedback loops to help ensure that you get eventual consistency around value delivery. "agile project management" usually bastardizes this greatly.. to the extent where nothing is more important than predictability. Agile development on the other hand is little more than the idea: "unless you talked to your user recently, you are probably now building the wrong thing - did you talk to the users recently? Go talk to them and show them what you have & ask them, what they think - and do that frequently."
I worked in consultancy, and our sales guy sold scrum teams for x sprints to customers xD Sometimes even giving away a scrum team for a sprint or two as a sample.
I think rituals comes from psychology. It is a type of human interaction that is less rational but more collective. I bet they took it from the Transactional Analysis theory by Eric Berne. It is widely used in management.
Thank you for pointing out Agile is just waterfall...Its also "just" a buzzword! And project managers and owners love buzzwords. EVERYTHING is waterfall...just in varied sizes of iterations. Everything is Analyse, Design, Implement, Test...Agile just means the goal posts are moving and you need to listen to what someone else working on completely unrelated features to your work for an hour every morning. :)
I actually lol'd when you said if you write code that's still good in 6 months... A company I worked for years ago still has some of the exact same code I wrote back then, and still use it in marketing images/docs
I knew Prime had zero clue on agile, but I did not expect him to have 0 clue on what an engineer is. If you really believe engineers are replaceable and somehow developers aren’t, I simply don’t understand your worldview Prime.
When the conclusion of the video is the exact same conclusion that Uncle Bob was coming to with Clean Code, you realize that this is yet another thing that people are going to look back on in 5-10 years and realize it was nonsense.
Agile becomes waterfall when leaders are cowards. Agile is keeping cost and time constant and adjusting scope as necessary. But it's time for MVP launch and scope had to shrink a little. OH THE HUMANITY. All the leaders faint and the only way to wake them back up is promise the original scope will be restored and make time and cost the flexible variables. Waterfall achieved.
I love too how the XP document discussed "only one team should integrate at a time", "there should be a dedicated machine for integration." The software industry seems to have forgotten that "integration testing" was the testing you did after merging back to trunk/master/main to ensure that your changes merged well with everyone elses and everything still worked. Those concepts seem to now be completely foreign to a developer that started after 2010, they don't even understand why the integration test would be needed, or why 'integration' was a major thing at all, let alone it being continuous or not. (back in the day, a merge conflict in CVS was horrible, it was non-trivial to resolve, and people were holding onto features for months at a time and then finally merging and integrating that with everyone elses month-long branch & eventually a release was created out of that).
Agile is great if its actually done and with enough customization to not be theoretical. The main problem with it is that its very unnatural to business people, so it can very easily be done as an anti-pattern.
Agile is great *_IF..._* Yeah, that's the problem. There's always a big IF in Agile. When you have a great thing that actually works there's no IFs all over the place. On the contrary, Moving Goalposts and No True Scotsman needs lots of IFs to be patched
In a somewhat twisted way, AI will eventually be better at Agile, as per the Manifesto's goals, than we ever could. Because it will have no ego and will be able to see how something is "more optimal" to the end goal. Agile by humans will always be mired in the "i want this this way and i have the leverage to make it so no matter how deleterious it is overall". p.s. obviously it won't work until business is an AI too...
Software Engineering, like any other engineering had that in place well before Agile and Scrum existed. That and a good manager with actual leadership skills is all you need.
Parts of the code are standard patterns and parts contain useful business logic; but the parts that are standard patterns do not contain business logic and the parts that contain business logic is not standard patterns.
The advantage of overcoming teenage addictions is prime has a good excuse for not knowing what a protractor,compass and gantt chart is, while still eventually acing his calc and diffeq classes.
Today at work I had a meeting. I'm in this senior promotion program and for that they want me to show initiative, open mind and all that corpo crap. So we have to present some project we get a week payed at the end of the year. They suggested I could make something with AI, nearly walked out of the room.
I always am for not overestimating LLMs. But at the same time, every time someone describes LLMs as any variant of the words "stochastic parrot", I have to take a step back. LLMs aren't creative by any means, they work within the boundaries of the concepts they learned about, but one should still be aware that just like any deep learning model, they generalize during training. Devin is still bs, tho.
Oh, come on, Devon is a Software Engineer Extraordinaire! Devon is so good that it is too good to program itself. And twitter is good for something else, a command and control server for botnets.
For those that think agile is bad, which values or principles of the manifesto do you disagree with? Do you agree with most of them? Do you disagree with enough of them for it to as a whole be bad?
Devin failed to help me with Unity + WebSocketSharp + WebRTC Qs, even failed to help me with my Hugo + Github workflow action thingy when the solution was in Hugo docs. It felt like it was trying its best to point me in the wrong direction and never the solution. I had hopes but im just disappointed.
Honestly, I like standup, but maybe that's because the teams I've been on have terrible communication and task delegation and time management so I'm blocked a lot of the day and standups are when there's actual availability for communication.
I think it's good Agile makes people talk, even when they don't want to... That's the real difference between waterfall and Agile, it's an attempt to prevent people from hiding problems, which helps some very good managers transfer some of the responsibility for failure to the stake holder, protecting the image of the engineers, and all the people putting the hard work... It's a very good social mechanism. The problem happens when the manager is not aware that the purpose is to transfer responsibility to the stake holder, which turns the whole process into a toxic attitude incubator...
if people don't want to talk, that's either a soft skill issue, or bad management (punishing people who speak up). It's completely unrelated to either waterfall or agile
@@lifelover69 Very related, clearly forcing people to all these meetings at least increases a manager chances of finding out issues before a developer with mommy issues has the stones to speak up otherwise.. But yes, it's a problem of the manager to actually make something useful of the opportunity....
Uh... You know... People don't need Agile to talk. In fact, people lose communication skills and are pushed to apathy because of Dailys structure: "What I did yesterday, what I'll do today, No blockers" Is not communicating at all, that's robotic and mind-numbing. Having to listen to that for 25min day after day makes you dull and apathetic, less interested in communicating.
You have *NO* idea how surreal it is to watch you watching me.
Loving the videos!
Love your video!! As a current computer science student you really put some sense in me amidst all the AI hype
Can you do rraction video where you talk about that, as you watch this video?? You watching him watching you.. it would be absolutely hilarious to just keep going back-and-forth and make an infinite chain of reaction videos to each other
Enjoyed your recent vids, glad you are getting wider exposure to an audience of less experienced devs.
@@systemlocLOL.
Maybe someday.
Right now, my channel is too new (~5 weeks old and only 11 videos), so I need to keep a consistent format for another couple of months at least so that the algorithm doesn't get confused about what kind of content I'm posting.
HR while interview "we use agile"
me "Please you don't know agile, nobody knows agile, lets just not enter that discussion"
But what do they say when you ask for clarification? The usual bs?
"It's a good agile, sir"
They try to do agile at my job. I'm in fucking hardware. I fix CCAs/ harnesses that fail when we test the F18/C130 generators we make. The only roadblocks are a failure of management. They don't ever implement solutions because I'm just a dumb ass solder specialist in their eyes. A year later, they fixed the problem the way I suggested in the first place. We're so agile.
If my code is so bad that no one wants to work on the project, the code is never changed.
you better don't share your address with anyone working after you
Your code can never be that bad. I would say those refusing to work on that project are idiots.
If those refusing aren’t willing to help out and fill the gaps where your knowledge is lacking then they aren’t in a place to complain either. Working together and sharing ideas about how to solve problems is the only way.
@@swedishguy83 I would put an exception on terrible codebases made by offshore devs. Horrors beyond human comprehension.
Be prepared to throw away your 50th version
You’ll likely be the permanent owner of the code until you die or otherwise leave the company anyway.
@12:12 - OF COURSE SCRUM FITS INTO CONSULTING! The agile manifesto was written by folks who were consultants, and they wrote it from the point of view of consultants. It was a response to consulting jobs where after 3 months it was obvious the thing being built was not wanted, and then after 6 months the obviously wrong thing was shipped. In these consulting jobs, the original deliverable was never revised nor discussed periodically. The manifesto basically said, "instead of this, work with customers to develop their ideas and give them a little bit at the time frequently, so that they can help decide the next direction (which might be redoing the thing that was just done)." This is a model that can keep a consulting company around for an indefinite duration. The trade-off was supposedly that value is continuously delivered, so if you want to keep that value stream - you keep the contract open. Contrast that with being 3 months into a project and knowing already that it should be cancelled, and the whole thing is thrown away with zero value delivered.
Exactly. It's insidious.
It's strange how agile is always used as a synonym for Scrum.
I tried the agile (not Scrum) approach last year.
We (two senior devs) were asked to build a web app that 3 companies already failed to develop for the customer.
The customer had a business idea, but no idea how to properly define it.
They tried to describe it in a technical manner to us, but we stopped them in their tracks and asked for the actual goals they want to reach instead.
Then we basically threw their software concepts away and we showed them our first prototype after a few weeks.
They were completely blown and they told us that we had made way more progress in less than a month than the others in more than a year.
Of course it wasn't perfect, but they gave us their feedback what was most important to them and we asked them to schedule a short meeting whenever we were close to running out of work.
We got the contact information for their "specialists" which we contacted whenever we've had specific questions, but there were no daylies or anything like that.
We did most of the work in pair programming and did code reviews for anything else. In the beginning I documented most of the stuff using Obsidian, but we started to use Notion after a while.
The project is live by now and the customer is still very happy.
Since the customer sometimes asked for fixed prices, we calculated how much the same would have cost if we would have built this in a fixed price scenario instead, and we came to a factor of four for both the costs and the estimated time.
So whenever someone says "agile bad", and then talks about Scrum, it makes me sad. Scrum is usually just waterfall in small increments with stupid ceremonies on top.
And why was Scrum invented?
Easy. Just look what Scrum certificates cost.
This. We, as technical people and devs have been fooled. It doesn't empower us, it isn't by us for us. Not even close. We are fools repeating ceremonies blindly like a cargo cult
@@errrzarrr there's a lot of that, but there's even more "we the devs haven't been fooled, but we're forced into a stupid system by the higher-ups who got suckered and swindled by some Agile Coach."
One thing I really hate (which should be part of the video I'm working on now about tech interviewing) is when buying into the ridiculous Agile fad of the day is a
Requirement for even getting an interview. (I turned down a project recently when in learned the company in question was planning a SAFe rollout in the coming months)
Ok but wait, the idea of going back and forth with the customers is a good one, right? It's like hiring people to do work around your house and going to a vacation for a month -- it's not going to end well :)
A spectre is haunting software development, it's the spectre of agile.
- Agile Manifesto
Agile can be done only worldwide simultaneously.
I thought it was the autism spectrum
The software development and its consequences have been a disaster for the human race.
@@Turalcar No, not even a little. Its the most positively impactful thing we've done since the printing press.
@@Novascrub it's the same joke. Just google "a disaster for the human race"
This is something I've been saying. Management wants engineers like Devin. But good software isn't made by engineers like Devin. But "good enough" software is.
Well said. As software industry grows away from it's origins into more business, the push for mediocrity grows with it.
Not quite. Because of the indeterminism of LLMs (statistical model fed with data) you do not even know if the code generated will meet the status of being "good enough". And when the customers change their mind like others change their socks the codebase might not even converge to maintainable anymore. But churning out documentation with at least some doxygen-hints... this is doable for a LLM.
LLMs can't reason, and can't create anything novel, so they'll never replace even the most junior programmer. They'll just make all programmers more productive (and valuable).
@@SimonWoodburyForget you've missed the point. Producing software is not only about churning the code. I would say that coding is one of the last steps. And increasing productivity doesn't mean that ppl would write more code in the same time
Software is like puzzles - it's about solving problems. The customer may want "something to generate invoices based on the orders list from online retail, and to automatically send these invoices by email". And it gives you at least few weeks of work - you need to find a way of auto-exporting data from sales, process this data, generate invoice in proper format, validate output and send emails
No LLM could do this - they struggle with solving of elementary school exercises. It may be helpful in summarizing docs for every step and/or in providing a boilerplate code for needed functions, and maybe some testing. But it's still a human who would need to do 90% of the work.
It will never replace humans. At most it will change some 1X programmers into 2X. But ppl will keep their jobs
@@SimonWoodburyForget I'm not using Vim and didn't write anything about it, and I don't work at corpo
AI will not decrease value of programming. There's just too much work. It may hurt some junior positions, but there is still shortage of seniors in every area.
I think you don't understand how software works. If my team had finished "twice as fast" (I guess that would mean delivery in 6 months instead of 12), then we would start maintenance, adding new features, refactoring and cleaning the code, addressing tickets, and many more stuff - if we were paid hourly wages
If we weren't paid hourly wages - we would still get the same amount of money, because we got paid for the completion of contract. This situation is even more beneficial for workers, because we could get more work done in the same time, and thus complete more contracts
Following your logic you can say that spending half of the workday in the toilet or at useless meetings would mean that my work gets twice as valuable, since I work 4 hours, but got paid for 8, thus doubling my income.
I started programming in the 80's. Agile is just a mini waterfall, with more status meetings. Customers are usually managers (or worse bean counters) and rarely end-users, that is, always was, and always will be the disconnect.
I'd just like to interject for a moment. What you're referring to as Agile, is in fact, Scrum/Agile, or as I've recently taken to calling it, Scrum plus Agile. Agile is not a methodology unto itself, but rather another iterative approach of a fully functioning Scrum framework made effective by the Scrum core practices, ceremonies, and vital roles comprising a full Agile project management system.
I'm with you that the terminology is messed up. I would clarify it as this: agile project management and agile development are different things. Scrum is an implementation of agile project management. Whether the development in practice is agile or not, is independent of the project management. My 2 cents, the place to focus on is agile development, once that is in place, the project management part becomes almost trivial (at that point the Scrum Master, Product Owner & Project Manager roles are no longer full time jobs; instead, those should be roles, as-in, our PO is the person that is going to use this system the most, vs some business analyst with a fancy title that knows nothing about the subject domain).
@@SeaBike007 it's a stallman meme, look up GNU/Linux copypasta
LOL
Scrum is not, nor can it be made, agile.
No True Scotsman favorite again? This one, along with Moving Goalposts fallacy, is the Agilists favorite one
Damn this guy has a lot of books, plus they're not arranged neatly so you know he's actually read them
Little shocked you didn't know Gantt. That's like the standard outside of software
"Extreme Programming" was management's attempt to normalize crunch mode.
I will gladly crunch my own project. The company that pays me though are just pay pigs until they fire me.
Pour one out for our brothers and sisters in game dev.
@@XDarkGreyXterrible jobs producing awesome things😢
Have you actually read the book, or are you just going by the name of it?
No, crunch was normal under waterfall. Scope of work and delivery date were both set in stone. Agile has its problems, but, as usual, the new problems are less bad than the old ones.
19:50 onward. This is right on the money! Thank you Primagen. Great advice too. I'm the end-user of 7-figure software packages and I've been witnessing this first hand. The founders are in the Bahamas and the H-1B's are busy driving the company into the ground
Games Publisher I used to work for but somebody from QA/CS in charge of Agile/Scrum ,Sprint planning and morning stand-ups for the IT Teams.
They had no experience in IT Admin, Dev or Architecture. But since they were also an unoffical PA for the CTO and did all his slides and reports we had to argue with them to get realist time-lines on issues/projects.
It too 2 years to get "root cause analysis" on outages but since the web dev team has their sprint planned out they would refuse to even look into issues we found and needed fixed ASAP.
It's like these Agile lords, 99% of the time non-technical people, are a burden and delay to the technical team instead of empowering and making things better
@@errrzarrr Exactly. The best managers were the ones that were able to take those distractions away and allow their engineers to focus on the work. Flow is really important when you want productivity. So is writing tools, which can 10x productivity but never gets prioritized on sprints like features do. And people forget that software development is also a very creative process in addition to technical. You learn a lot on the way and need the flexibility to pause, reinforce, refine and iterate in addition to building if you want to make something truly special.
The problem is that software is so soft and so explicit that the software IS the documentation. Really the only way to verify that it does what it should do correctly is through tests. So tests document the requirements. So, all documentation from software is derivable. The problem comes from non-software engineers getting into the mix. Software doesn’t have a person in the C-suite with specific software engineering training and experience (which it should), and product managers and UX teams who don’t have software engineering training have gotten into the software engineering pipeline. I’ve seen software engineers being pushed down to basically factory worker level. The lowest rung on the organisation hierarchy. It makes no sense. No other professions do this. You don’t have a non-engineer managing engineers building airplanes. You don’t have non-doctors managing teams of doctors. You don’t have non-academics leading teams of academics.
You’re right- it’s rare to find software engineers who become business people. And that’s what it takes to sit in the C-suite.
How many great developers would rather be networking and meeting with customers and salespeople and investors. Because that’s what it takes. And the tech industry needs more technical business people, not MBAs
I 100% get the hate for Agile. I'd like to add some personal experience here. For about a year, I was the Scrum Master on a web development team, and this was one of the happiest, most productive teams at the company for the entire duration I was on there. Word is they're still very happy and productive. And I think the reason we were in such a good place was when we formed the team and were told to "do Agile because everyone else is doing Agile," myself and the PM nodded, smiled, and then immediately threw out 90% of the Agile bullshit everyone else was doing. Story points? Gone. Fibonacci shit? Gone. Everyone spending half their fucking day in JIRA? Gone. We capped our morning standup at 5 minutes, and if you didn't get to say your part, you'd just give your update in our group chat. The PM and I did a lot of the backlog grooming ourselves without wasting the rest of the team's time. We made sure to capture everyone's feedback and input so the backlog was usable and accurate, but people provided that data on their own time and not during a super-expensive meeting where everyone would sit in a room full of highly paid engineers for two hours so they could give a 10-minute update. For the sprint review meetings with our stakeholders, our PM did the lion's share of converting our work data into the kind of metrics leadership wanted to see. That PM was our MVP, no doubt about it.
On the flipside, we had a sister team that was "doing Agile the right way," and they were MISERABLE. Standups that lasted 45 minutes. Backlog grooming that took an entire afternoon every 3 weeks. Those folks learned to hate JIRA like I've seen few people since hate JIRA. And even though they did everything "right," they were constantly behind on everything.
Traditional Agile, in my experience, is a cargo cult. But there's nothing that should stop you from changing Agile into something completely different that works for your team, say it's Agile to make management happy, and call it a day.
I really appreciate this comment. It sounds to me like the team you lead were doing "agile development" with a thin layer of "agile project management" on top. The other team was doing a thick layer of "agile project management" and the development was not agile at all.
I would recommend this podcast to you: ruclips.net/video/9N4ZgNaWvI0/видео.html "Product management theater | Marty Cagan (Silicon Valley Product Group)", really gets into the distinction of agile development and agile project management. The thesis of the podcast is largely that agile project management & agile development are different, agile project management requires agile development to work well (the inverse is not true), and when agile development is implemented, most of the project management stuff becomes moot and no longer a full time job.
A typical Scrum master; thinking Scrum equals Agile. That said, I do agree with what your team did throwing out a lot of the Scrum process, it was actually Agile ("people over processes").
Scrum is not agile and JIRA is hated so much, it is a meme.
@Tailmonsterfriend So you had JIRA items but didn't use points, and the discussions were taken offline? That makes a lot of sense. But technically (it might sound like "no true Scotsman" now lol), daily _standups_ are meant to be short (hence "standups"). Unless you also did away with 2-week sprints? How about retrospectives? I find those rather useful to address things that got ignored during the sprints.
I'll tell you right away that the things you threw out were neither Agile nor Scrum. Except for cutting 10 minutes from the daily timebox, and that is a change I definitively approve of. I don't see the point in those meetings. All in all, great mindset. One thing I used to do when I was a PO back in the days was that I would plan refinement of future sprint goals into the sprint itself. This resulted in exactly what you describe: "The PM and I did a lot of the backlog grooming ourselves without wasting the rest of the team's time. We made sure to capture everyone's feedback and input so the backlog was usable and accurate, but people provided that data on their own time and not during a super-expensive meeting where everyone would sit in a room full of highly paid engineers for two hours so they could give a 10-minute update."
I do have to ask, however, how was work data coverted into metrics? Reviews are for qualitative analysis, not a quantitative. Meaning you show what you've delivered, and then get feedback on if it is good or not, and then present your plan on what is coming next letting them give their opinion. I don't see the part where the metrics come in.
I loved the idea of "scale your project until it fails". There's something beautiful to this idea. You stress both your abilities and the technical capabilities of a piece of engineering so that you can learn to better maneuver the ship. I've failed 6 times over 2 years of trying to create a compiler for my own programming language, and I am really amazed at how much I've learned from it
We NEEEED to make our own methodology,SIDD, Skill Issue Driven Development
Ah, the methodology where SKIP (SKill Issue Programming) is a part of?
@@stzi7691 I think you just have expressed my idea with a better name, let's pick yours
2:25 sums up Agile and especially Scrum. Never-ending "sprints" (how is it a sprint if you just did another sprint right beforehand?) and nobody *ever* finishes everything in a sprint, so the team gets to talk about it at every single retrospective. The ones that worked were Extreme Programming at a startup in 2006, then Kanban in the mid/late 2010s before some Scrum consultant arrived and fucked it up.
Waterfall means you have to do each phase of what you would consider part of an engineering process. Saw a project fail so hard because they spent so long making diagrams and tweaking power points that by the time the got to deployment the licenses and support for the project were expiring, and during the few months where the system was both deployed and supported it had tons of layered bugs because everything was unstable with no know good state. Worse yet, that release and forget process meant everyone that worked on it were put onto the next project rather than getting to just fix the last projects bugs and get it to stable.
I'm a big DevOps fan myself, the tighter the loop between the devs of an app and production the happier I've been, and keep their scope tight and clearly delineated from other teams.
Waterfall is the first attempt to industrialize engineering. Agile addresses the bureaucracy of waterfall (most of the products produced by waterfall are to give management warm fuzzies not make things). DevOps address the fact that without running systems stakeholders don't actually get what they want. Platform engineering address that giving teams flexibility or being too prescriptive because a nightmare to support.
We are getting better at industrializing engineering, finally, so automation tools can really start to have a place in it. CI/CD, and now LLMs can start to make sense depending on where you fit on this spectrum.
> Worse yet, that release and forget process meant everyone that worked on it were put onto the next project rather than getting to just fix the last projects bugs and get it to stable.
I've seen this a lot in scrum teams. I think that 'release-and-forget' is just bad management. Speaks to a feature factory, being 'story-completion' driven instead of outcome-driven.
@@AndrewMorris-wz1vqAgile "replaced the bureaucracy" of Waterfall with unecessary ceremonies and kid games like poker planing 😂😂😂😂.
Interesting tasks divided into tiny not interesting tasks that will need refactoring cause the goal is just to remove your sticker....
Then you you have crap code review and poor structure as "getting rid of your sticker" means you e done it and if you think that means you're creating code that n eds refactoring that means you haven't created standards, enforced them and have very little mentoring from seniors. Writing code is not just whipping out some if else crap. Agile is a methodology that's more than pointing. Obviously you're not a senior and if so, not a well developed one. @@souleymaneba9272
For me calling "ceremonies" the meetings and other weird things proposed initially with the intent of making it standard across programming its just another example of purposely mystifying an already niche profession so the normies would freak out on what that niche of people is doing, to harvest division eventually for political purposes. Happens a lot.
As someone about to graduate an engineering degree gannt charts were required far too often in projects. Almost everyone I know just completed them all retrospectively once the project was done.
Makes sense. Software engineering is usually more akin to writing a fiction novel than it is to (for example) building a road. Being a software manager is more like being the chief editor at a newspaper than it is the foreman at a construction site. You can gannt out what it takes to deliver tomorrows newspaper, and maybe that might help somewhat, but it doesn't make a lot of sense to gannt out every newspaper for the rest of the month in advance.
Primagen: It's Java.
Me, a java hater from the swing->awt days: _I KNEW IT._
Manifesto - in most senses just means to make something public. That's coming from Latin. So, to make something manifest. Also, fuck agile.
Agile+daily standup(everyday pressure cooker)=productivity killer 🧨
0:15 My name is Carl and today we’re gonna talk about Devin-AGEN
OMG the Gantt chart gave me Vietnam flashbacks to university. Same whiteboard circlejerk as UML.
She agile on my java till i scrum?
I didn't finish the video yet, but I need to say that you are on fire. One pun after another. Your creativity fluids are flowing like mad after being unshackled by a classical employment :D
that was a pair of compasses, not a protractor
Glad someone else noticed, thank you sir.
The advice in the last few minutes are golden. Sometimes you won't see things coming off the rails for 2-4 years, but it totally happens.
Thinking about the long term is important, but it's also important to remember that what you write will eventually become someone's legacy product at some point.
That's why my slack bio at work says "writing tomorrow's legacy software, today!"
I need a books list from this guy.
The Tom Sellick of Programming
Sam Sulek mentioned?
Healthy Sofware Development has a great series of what agile and scrum actually means. I'm the current scrum master in our group. We have never been agile nor is my role meaningful. My first action was to shorten and cut out meetings. Not erase to please managememt, but got 2 - 3 more hours a week for everyone to actually code instead of waiting to report what they do.
If Agile made Devin AI possible, we don't have to worry about a potential AI takeover, because it's gonna be shit anyways.
Don't confuse Agile with Scrum
1:58 "Agile is just Waterfall"... Nope, this is "Rapid Development". The part most people miss is the definition of "rapid" meaning "a series of small waterfalls".
Dude Prime's rant at the end is mind-blowing, this whole video is gold.
Stand up meetings are the worst.
They're there for two kinds of people:
1- the clueless manager
2- the clueless developer
We stop production and get our staff out of "the zone" for clueless people who can't figure out what's being worked on by looking at the backlogs.
It’s ok man, you aren’t alone.
It's not VIM vs the World, unless you aknowledge that the World is emacs xD
Does emacs do VBCode now? /s
The headlines for Agile trying to hitch their wagon to AI is 📈📈📈
About Agile being waterfall but with a Kayak singlehandedly trying to safe your life: absolutely true...
Except when we had Waterfall they were honest about it and didn't pretend it wasn't. Management did their work of managing, while in Agile the developers have the burden of doing technical work and manager's work. A double burden without the benefits.
Back in Waterfall, yes management got the credit when things succeed but at least they did their job. Now is the Scrum Master and PO taking the credit.
Last but not least, I think this is the most important one: when things went south management took the responsibility. Now with Agile they blame technical team for not being managers and *"Not being good enough to do Agile correctly."*
This last one I think is why the industry adopted Agile so fast without resistance. Not because it _empowers_ devs, but because managers can keep their seat without being blamed.
OOP lends its into Agile. You fit the hard problems inside the same effort bucket as easy ones and increase productivity.
My first job out of college had a release every few weeks to a month on average. We used some agile like stuff, but definitely loosy goosy with it
The language was vb6 for the code base
This was like 10 years ago, at that point vb6 didn't have an officially supported development environment (the IDE was no longer supported as of 2008)
I still find it wild I coded a monthly released project in vb6
Our project may have had some 3rd party 16 bit plug ins
Getting that to work for the dev environment was 'fun'
Before I left I think there was multiple versions of my virtual machine on like 5 employees computers because no one wanted to get it working again
I love Internet of Bugs. He's had the most real talk about "AI". Something he'll probably be discussing at length for a while in an attempt to quell the hype/fear/fearhype. I'd like to hear what he says about other things as well though, so I guess I'll have to wait a bit.
The core part about agile vs non agile for me is: You work on an MVP. The "old" way (the GANTT chart) is: you spend days / weeks planing the next 2-5 years and then you stick to it. Yell at people for not meeting the deadline you set 18 months ago. No Flexiblity, no "spin-off", no MVP. Just get "it" done.
Sure you have a burndown chart now (which is GANTT minus the excact dates). Yes you are expected to say how long it roughly takes. But noone in their right mind would take all the items in the backlog and build strings out of them and then tell you what the critical path is. This for me is the "classic" way of doing it.
I don't really understand the hate on agile, sure it can be taken too far. But at it's core I think it makes a lot of sense.
> Yes you are expected to say how long it roughly takes.
I think this one of the most mis-understood parts of scrum. The point of estimation is *only* so you can pull in a reasonable amount for the *next* spring, NOTHING more. The estimate is not so we can say: "gee, we do 30 points a month, we have 90 points in the backlog - ergo 3 months to finish." That is *not* the point. In 'scrum', you should also ask, "in the next 3 months, how many times will we change directions?" If you ask that, then it's pretty clear that "3 months to finish" estimate is worthless. Agile/Scrum is a whole tool to make delivery *less* predictable, but bias towards delivering actual value and building on that. It's not a way to make a project more predictable, and I think so many people lose this & forget that you can change direction as soon as you figure out that the backlog is "wrong."
In a way, Scrum/Agile are more a method to validate that you are working on the correct thing, and to provide feedback loops to help ensure that you get eventual consistency around value delivery. "agile project management" usually bastardizes this greatly.. to the extent where nothing is more important than predictability. Agile development on the other hand is little more than the idea: "unless you talked to your user recently, you are probably now building the wrong thing - did you talk to the users recently? Go talk to them and show them what you have & ask them, what they think - and do that frequently."
2:23 everything is waterfall because everything is subject to the relentless passage of time
I love standups all the getting together and talking about yesterday and today even maybe tomorrow. Hahahahahahaa
I worked in consultancy, and our sales guy sold scrum teams for x sprints to customers xD Sometimes even giving away a scrum team for a sprint or two as a sample.
Not gonna lie, kind of a solid idea
I think rituals comes from psychology. It is a type of human interaction that is less rational but more collective. I bet they took it from the Transactional Analysis theory by Eric Berne. It is widely used in management.
Extreme programming… haven’t heard that term since Uni… what a throwback
It's a compass
The circles give perfect ratios: 2:1, 3:4 etc
Certainly, the content was so engaging and informative. Can't wait to see more from this channel. Keep up the great work, fellow human youtuber.
Java! is the answer to most ... "Why did we do this stupid thing" questions.
Most of y'all haven't watched Dave Thomas' "Agile is Dead" talk from 2015 and it shows.
Ah-gee-lay, must be Italian
Lying ass chat Yeremy's.
2:12 That made me laugh so hard
Thank you for pointing out Agile is just waterfall...Its also "just" a buzzword! And project managers and owners love buzzwords. EVERYTHING is waterfall...just in varied sizes of iterations. Everything is Analyse, Design, Implement, Test...Agile just means the goal posts are moving and you need to listen to what someone else working on completely unrelated features to your work for an hour every morning. :)
Anybody else drawn to Halliday & Resnick like a moth to a flame.
I actually lol'd when you said if you write code that's still good in 6 months...
A company I worked for years ago still has some of the exact same code I wrote back then, and still use it in marketing images/docs
When you have a roadmap with release dates for every features 2 years into the future, but use MURCS to be "agile", because it's the "in" thing...
15:27 These are Pentominos, the actual inspiration for Tetris.
And as Andrei Alexandrescu proved in one of his talks, even quicksort can be improved.
I knew Prime had zero clue on agile, but I did not expect him to have 0 clue on what an engineer is.
If you really believe engineers are replaceable and somehow developers aren’t, I simply don’t understand your worldview Prime.
the word manifesto makes me think guy in basement reading the Anarchists Cookbook.... also HI NSA! sorry you had to waste your time reading this.
Oh man, I'm fluctuating between hard agree and hard disagree every couple of seconds with this one xD
When the conclusion of the video is the exact same conclusion that Uncle Bob was coming to with Clean Code, you realize that this is yet another thing that people are going to look back on in 5-10 years and realize it was nonsense.
RADICALLL PROGRAMMING!!!!!!!!: a gentle intruwuduction :3
Political parties have manifestos. So yea, your thinking on the right tracks.
Edit* This guys B roll is A roll.
Agile is the devil, so I believe it.
4:05 yeah Kent Beck's book setting up what XP should be was anything but gentle
Agile becomes waterfall when leaders are cowards. Agile is keeping cost and time constant and adjusting scope as necessary.
But it's time for MVP launch and scope had to shrink a little. OH THE HUMANITY. All the leaders faint and the only way to wake them back up is promise the original scope will be restored and make time and cost the flexible variables. Waterfall achieved.
Yup. 90's/00's programming was not about CI/CD. You still needed to worry about desktop images and standard installs.
I love too how the XP document discussed "only one team should integrate at a time", "there should be a dedicated machine for integration." The software industry seems to have forgotten that "integration testing" was the testing you did after merging back to trunk/master/main to ensure that your changes merged well with everyone elses and everything still worked. Those concepts seem to now be completely foreign to a developer that started after 2010, they don't even understand why the integration test would be needed, or why 'integration' was a major thing at all, let alone it being continuous or not. (back in the day, a merge conflict in CVS was horrible, it was non-trivial to resolve, and people were holding onto features for months at a time and then finally merging and integrating that with everyone elses month-long branch & eventually a release was created out of that).
@@SeaBike007 One of my early jobs had merge engineers, developers just full time employed to merge changes into trunk. Good times.
Take 19:45-21:00, clip that it’s gold. Throw the rest in the trash.
As a software engineer who's name is Devin I am genuinely considering changing my name.
Agile is great if its actually done and with enough customization to not be theoretical. The main problem with it is that its very unnatural to business people, so it can very easily be done as an anti-pattern.
Agile is great *_IF..._*
Yeah, that's the problem. There's always a big IF in Agile. When you have a great thing that actually works there's no IFs all over the place. On the contrary, Moving Goalposts and No True Scotsman needs lots of IFs to be patched
@@errrzarrr No. There is always IFs. Programming is always about trade-offs. Also not like a know anyone who thinks waterfall is great.
In a somewhat twisted way, AI will eventually be better at Agile, as per the Manifesto's goals, than we ever could. Because it will have no ego and will be able to see how something is "more optimal" to the end goal. Agile by humans will always be mired in the "i want this this way and i have the leverage to make it so no matter how deleterious it is overall".
p.s. obviously it won't work until business is an AI too...
Seriously now I have subscribed because I became a fan of prime, fook ya!
18:34 that's what she said 😂
Radical programming sounds kinda rad
8:20 Bro was using a compass. A protractor is the half circle thing with the angles. They usually come as a set. Ya wrong
You should actually create your own PM methodology. It could change the world! 😄
Software Engineering, like any other engineering had that in place well before Agile and Scrum existed. That and a good manager with actual leadership skills is all you need.
Parts of the code are standard patterns and parts contain useful business logic; but the parts that are standard patterns do not contain business logic and the parts that contain business logic is not standard patterns.
The advantage of overcoming teenage addictions is prime has a good excuse for not knowing what a protractor,compass and gantt chart is, while still eventually acing his calc and diffeq classes.
Keep it up my the full time content creator
I could consume this as a podcast
Today at work I had a meeting. I'm in this senior promotion program and for that they want me to show initiative, open mind and all that corpo crap. So we have to present some project we get a week payed at the end of the year.
They suggested I could make something with AI, nearly walked out of the room.
Devin mentioned.
12:26 point where prime has the epiphany.
I always am for not overestimating LLMs. But at the same time, every time someone describes LLMs as any variant of the words "stochastic parrot", I have to take a step back. LLMs aren't creative by any means, they work within the boundaries of the concepts they learned about, but one should still be aware that just like any deep learning model, they generalize during training.
Devin is still bs, tho.
Oh, come on, Devon is a Software Engineer Extraordinaire! Devon is so good that it is too good to program itself.
And twitter is good for something else, a command and control server for botnets.
For those that think agile is bad, which values or principles of the manifesto do you disagree with? Do you agree with most of them? Do you disagree with enough of them for it to as a whole be bad?
Hey, Question
Why are your Twitch VODs locked behind being a sub?
Devin failed to help me with Unity + WebSocketSharp + WebRTC Qs, even failed to help me with my Hugo + Github workflow action thingy when the solution was in Hugo docs. It felt like it was trying its best to point me in the wrong direction and never the solution. I had hopes but im just disappointed.
Okay that guy has clearly only seen the very top of the backlog😄 Most of the time u end up researching what was intended and if it is still needed.
Honestly, I like standup, but maybe that's because the teams I've been on have terrible communication and task delegation and time management so I'm blocked a lot of the day and standups are when there's actual availability for communication.
Ice wants radical programming!
here for the software kayaking
I think it's good Agile makes people talk, even when they don't want to... That's the real difference between waterfall and Agile, it's an attempt to prevent people from hiding problems, which helps some very good managers transfer some of the responsibility for failure to the stake holder, protecting the image of the engineers, and all the people putting the hard work... It's a very good social mechanism. The problem happens when the manager is not aware that the purpose is to transfer responsibility to the stake holder, which turns the whole process into a toxic attitude incubator...
if people don't want to talk, that's either a soft skill issue, or bad management (punishing people who speak up). It's completely unrelated to either waterfall or agile
@@lifelover69 Very related, clearly forcing people to all these meetings at least increases a manager chances of finding out issues before a developer with mommy issues has the stones to speak up otherwise.. But yes, it's a problem of the manager to actually make something useful of the opportunity....
Agile doesn't really have anything to say about talking, Scrum does
Uh... You know... People don't need Agile to talk.
In fact, people lose communication skills and are pushed to apathy because of Dailys structure: "What I did yesterday, what I'll do today, No blockers" Is not communicating at all, that's robotic and mind-numbing.
Having to listen to that for 25min day after day makes you dull and apathetic, less interested in communicating.
Devin is very impressive. What it is not though is a software engineer.
Golden take on stand-ups.