AGILE & Scrum Failures stuck us with 'AI' hype like Devin

How did we get to the point where so many people believe that an "AI" like Devin will completely replace the jobs of most, if not all, Software Engineers? Why is the work of Software Development so poorly valued?

The question here isn't "is it true Devin could replace Software Engineers?" Because it can't, and I already made a video on that.

The question here is: "Why is it so easy for people do believe it could?" and "What does that mean for the future employment of Software Developers in a pervasive-LLM world?"

I think I have an answer, and, just like much of the problems we've had in the last 20 years, it all starts with AGILE's failures.

00:00 Intro & Question
00:30 The 1990s and Gantt Charts
00:55 Extreme Programming
01:44 Branding FAIL
01:53 AGILE Manifesto
02:15 Scrum Alliance
03:14 Perception of term "Engineer"
03:55 Perception of term "Software Engineer"
04:34 What do people think Software Engineers do?
05:21 What can we start doing about it?

Links from the video:
Extreme Programming (XP):
AGILE Manifesto"
Scrum:
Stochastic Parrot:
LLMs helping to Document Software:

Engineer Sample Deliverables:

NOTE: (Not that anyone will read this, but) When this video uses the term "AI." it (like most of the current discourse these days) means current and near future "Generative AI" a.k.a. Large Language Models. If you're thinking about the Agents from the Matrix or the Robots from Terminator, that's DIFFERENT. That's the OTHER AI, the Human-Intelligence General AI, Sometimes called "AGI." That DOES NOT EXIST. For the time being it's PURE FICTION. It may get here soon, although I (and a lot of people smarter than me) seriously doubt it, but we'll see.

[KuzzatAltay]

The only technical YouTube channel with radical authenticity that I look forward to for the new videos.

[muhdiversity]

Meh. Let the cancel pigs come. You are so spot on. In my last firm Agile was basically the religion. They're so focused on the Agile process so that everything " looks " good to the incompetent management, they have Agile high priests what watch everyone's Jira's like hawks (that's all they do) and without consulting the developer make changes to them so that the end of sprint report looks perfect with burn down charts and other nonsense that also look perfect. Every other part of the software engineering process is tossed to the wind. Of course they mass laid off engineers in their future hope that the AI high priests they hired will wave their hands and all the software will be written by magic.

[cristiansprohnle]

I totally agree with you. I think that:

- AI, for now, can't do much regarding coding. It can only help us with simple tasks, similar to what StackOverflow does. We have to integrate those solutions into our project's architecture and business logic. I think in the future, AI will do much more, but I'm not sure if it will be able to handle business logic and code quality in the short term.
- Agile and Scrum are a cancer now. The only ones who think that the work of an engineer is just burning through backlog tickets are the PMs and SMs, usually because they don't know much about programming and software engineering. There is always extra work related to a ticket, such as refactoring a legacy view, creating a new one, creating a new API endpoint, or even starting a new project. But the PMs are often unaware of these technical points; they only see a big XXXXL shirt size.

I think AI will handle tasks like updating some API endpoints to expose an extra parameter or updating the i18n translation of an error case. However, for real tickets, human thinking and manipulation is required, at least with the current state of LLMs.

[Patronobrbuild]

Great video, keep creating content.

My thoughts:
1. In general, people don't know what the software engineering area actually is and what an engineer's responsibilities are. It is very ignorant to think that programming is the only thing an engineer can do. Perhaps this issue of nomenclatures such as Developer, programmer and engineer has helped with this confusion of responsibilities.


2. About the YouTuber or influencers: I don't know if they really believe that Devin will really replace them. I think in the end it's all marketing, they need to have controversial thumbnails, talk about controversial subjects in a controversial way and create, in some cases, alarmism. That's their job, they depend on engagement, and worrying about the consequences of their speeches and scaremongering doesn't seem to be part of that.

[HuangShengHong]

AI exists.
True artists keep drawing.
True programmers keep coding.
The others keep worrying.

[potatoTomato]

You read my mind. Most content about "AI" and software development have a certain outlook on what is currently happening, I thought I was so weird for not understanding it like most do. Today I came across your channel and you are the only one who says what I think. You made me feel heard even though I didn't say anything and you made me feel like I belong somewhere, thanks for that.

[jamessullenriot]

If you think Agile is bad at a tech company, try doing agile in a big corp as a developer where there are literally 2 - 3 devs on a project that are actually doing work and then anywhere from 5 - 10 people just asking for updates and booking meetings all day, because if they don't have meetings they don't really have anything to do. In my opinion, the reason for any of this is agile/scrum consultants. That, and the idea that every company that does any sort of tech, needs to operate like 204 Netflix, Spotify, etc. That is great when interest rates are low, and the economy is booming. Not so great when its 2023/24, interest rates are high, economies are stalled, and you broke your simple CRUD app into 47 mini repos that all now need to moved over from Openshift to GHA (because that will save money) and each repo has a different point of reference so they are each different I think even Devin would throw in the towel 😂

[fstttt]

Great video as always. I made a comment in other video where I specifically criticize agile without saying it's name, because I know agile can mean a lot of different things for different people.

The more I work in the software engineering job, the more I correlate Agile with problems. The usual is "sprint deliverable is more important than everything", leading to bugs, poorly performant code, etc. But you mande another important point about Agile transforming the Software engineer job from "thinking" to "doing".

I remember I time when everytime I switched tasks, I would spend 2 hours "doing nothing". I would literally stare at the screen, barely coding anything. I would start the task "for real" only in the next day. I used to feel so bad about it, like I was a bad developer. Then I realized that this time I was "doing nothing" my mind was racing trying to understand the problem, the best approaches, trying to predict limitations. It's work, but not a tangible one.

[darkarchon]

Alarmism sells well and gets a lot of clicks. I really hope that people will start to check out of this, because, frankly, doomscrolling is counterproductive. As for the topic, there is a lot of code-monkey jobs, and people do think about them when they are thinking about software engineering.

[oshriperetz]

First video I've seen from this channel, it's refreshing to see someone treating the software engineering role with respect.

[carlosgm]

That’s what I call COMMON SENSE. We need more voices spreading this!

[Wouldntyouliketoknow]

For the structural designs, I have found c4 diagrams invaluable.
Here are my rough thoughts at an approach

1. Requirements Gathering and Refinement
2. Promise gathering (what promises do we need to sustain to end users or other "actors" e.g around uptime, being able to process data by certain times or within certain times, reliability etc etc. I think spending time to focus on these specifically is valuable.
3. Architectural diagrams (C4)
4. Lower level supporting diagrams where greater clarity is required - for example, sequence diagrams or flow chart diagrams where we need to nail down complicated process flow or logic
5. ticket creation / milestone creation - now that we have a good idea of what we need to build and how we intend to build it, we can try to lay the work out in phases or logical building blocks. Capture these with the dependencies. A ticket can be technically started as soon as it doesnt have any unfinished dependency tickets. However here assigning a priority can also help ensure certain tickets are actioned before others all other things being equal.
5. progress visualisation - technically the structural diagram plus the requirements, represent the sum of the deliverable. So we should be able to measure which requirements are met, and which structure is done. However as we tend to represent this work as tickets, we should also be able to measure progress in terms of how fast we are completing tickets and whether that is broadly in line with estimates. The "sequence diagrams" or lower level documentation can be supporting design documentation against particular requirements / tickets that need that extra detail.

6. feedback: this is all sounding pretty waterfall so far. However depending on how you plan point 5 - its possible to prioritise delivery of an early MVP version which is incomplete, through to prod asap, knowing that other tickets are yet to be completed. Therefore with this approach you can allow for early feedback - however crucially that feedback needs to be incorporated as refinements to 1 or 2 above, so that number 3 and 4 diagrams can be revised, leading to modifications possibly to number 5 to accomodate the changes.. and thus the "iterations" repeat.

Basically the software project is "docs first" - prioritising requirements, structural docs (c4), plus lower level docs where necessitated, and as new feedback is given (or learned) during iterations; these docs are updated leading to a revision of ongoing ticket items.

[swaggitypigfig]

No one’s gonna cancel you mate. 😂 Cancel culture doesn’t apply to ideas on scrum, it applies to politics and hot button stuff that advertisers might have a problem with.

[borisstanar]

Calm, concise and straight to the point.

[jmunkki]

Mentioning documentation always makes me think of the "Inside Macintosh" article on the Mac folklore site. The most important point from that article is that if the developer finds it very difficult to explain how an API works to someone writing the documentation, then there's a good chance the API could be improved. Similarly, if the developer is responsible for documenting her own code, it's even possible to get this quality improvement even without a dedicated person writing the documentation. With language models, I suppose you could ask a language model to write the documentation and then check if it's correct. If it's incorrect, is it because the code is difficult to understand and should be improved or was it just the language model being dumb?

I have been programming since 1981 and I have a MSc in computer science. I haven't done any professional programming in about two years now. In my experience, managers tend to push programmers to move on to the next ticket insted of letting them document what they did (or even explain verbally to the team how they implemented the ticket - meetings seem to be all about "what" and "when" instead of "how"). I think human-AI collaboration will be good for software. Humans don't seem to have time for each other, but you can ask an AI what it thinks of your solution and how it would document it.

Here's a quote from the article: "Pretty soon, I figured out that if Caroline had trouble understanding something, it probably meant that the design was flawed. On a number of occasions, I told her to come back tomorrow after she asked a penetrating question, and revised the API to fix the flaw that she had pointed out. I began to imagine her questions when I was coding something new, which made me work harder to get things clearer before I went over them with her."

Anyway, read the full article: it's entertaining and not all that long. It may also offer a clue as to why the Macintosh was a success...

[wforbes]

Happy to see this video featured on Primeagen's stream recently - rooting for you Carl!

[madnessandescapism]

That is not perception of software engineering. The problem is broader - it is perception of IT in general and maybe even more. It started with printers. Because nobody expect them to print at the first request. Now we don't expect planes to fly at the first try. We don't see computers in general as something reliable but we can't live without them anymore. Hopefully this will be fixed before we have internet-connected certified and approved "secure" nuclear power plant with outdated php in it. Thanks for your point, really great video.

[hagenzwosta]

Agile is supposed to be a mindset. Not a bunch of tools and hard instructions. I have seen many "agile" projects, claiming they are agile because they are using "SCRUM". When in fact they did waterfall. Just with scrum tooling. Agile was invented to get the correct mindset into the project and to get rid of fixed rules and methods. Stop planning everything months in advance, that will not work anyway. And what are all the "agile gurus" doing? Forcing their rules and methods onto every problem. They are even worse than the "project managers" of the past.
And yes "we" also managed very huge software projects with Gant charts in the 90s. And they all worked out. But what we actually did: we worked over the complete project plan every single day. So it was not fixed, but agile. Of course this was not the right tool and a lot of unnecessary overhead. But as everyone had the right mindset, it still worked. And I also very much agree: people hide behind "scrum" to stretch out each little thing they do to a maximum duration. Each small task now has so much overhead that it is ridiculous. So instead of being agile they all became snails.

[HomeslicedVideos]

Thank you for not being another click baiting AI Doomer.

Every Doomer video title is the same these days: "It Begins...", "It's OVER for...", "We're DONE FOR!", "End of an Era...", "All X Jobs Will Be Gone Within Y Years!!!"

So tiring, but making people feel negative and outraged gets clicks and engagement, not balanced and rational analyses (note the obvious parallels to media, news, culture in general).

[vincei]

A good friend of mine contributed to the book "Extreme Programming Refactored: The case Against XP" by Matt Stephens and Doug Rosenberg in the early 2000. Unfortunately for us the zealotry and outright misdirection of Agile and Scrum has just made the industry worse as it is populated by so many charlatans spreading their religion.