I remember he first posted 2+ years ago, back when people first realized ChatGPT might be useful for coding, that "90% of my skills are now worthless and the remaining 10% are worth 1000x"
I’m is the opinion that the test first XP style of development pays more dividends now than ever, simply because you can use it to validate the code that AI generates and importantly it makes it easier to generate code from these AI tools.
One of these "AI coding" things that come across as a code smell is the habit of littering outdated reports/guides in the repo. That seems to be happening here too.
This is clearly an AI-generated report based on the code at the time of the generation. I don't see the point of storing them in the history? Especially as this _updated_v2_from_2025 trail of debris.
I think that XP was the only true agile methodology. Agile just got more and more corrupted over the years through stupidity.
Clearly AI programming allows you to quickly close feedback loops. I don't think everything needs a comprehensive set of unit tests though.
But if people can go back and understand the core concept of XP (which again is about feedback loops to me) and take advantage of LLM-based agent systems to create those tight closed feedback loops, then that will be an advance for software engineering.
Starting with XP and in shops doing XP quite intensely has ruined me because I simply can't stomach working in "SCRUM" shops where a whole pile of stuff is taken as "agile" dogma which is mostly just ritualized meaningless bastardizations of things that XP pioneered, turned inside out.
I think the ideal scenario is usually two paired programmer using a shared set of AI agents on the same working branch together. It's an ideal feedback loop of paired planning, reviewing, building, and testing.
“Unit tests are small tests, each one exercising a little piece of functionality. The units tested are usually individual methods, but sometimes clusters of methods or even whole objects.”
Extreme Programming Explained: Embrace Change, 2nd Edition (2004) Kent Beck
You're agreeing with me there. "each one exercising a little piece of functionality". In Beck's approach the tests are added at each step for a simple functionality addition, which then gets implemented in the project to pass the test. These days unit tests are more commonly used as "every method is a unit to be tested completely", often after the implementation is already there.
I also wonder if this is written from a statically-typed perspective. In dynamic-typing land there are so many more stupid little things that can break that the compiler would otherwise catch for you
Either that or tracing/logging/debugging, but other than specific niches like parsing (of specific bug repros) I think integration tests are generally a lot more bang for the buck.
Anyway, if you want to go down a related-but-unrelated rabbit hole, J.R. Thompson's lecture on the Space Shuttle Main Engines is a good one. You can probably watch it at higher speed to smooth out the many, many "uh"s (believe me, it's bad):
I think a more accurate version of this is: unit tests were not only per-method but also per functionality. This was often called BDD (Behavior Driven Development), e.g. Ruby's cucumber. Your intuition here is correct though.
I disagree with the "not only". The idea in xp is to write the test first. http://www.extremeprogramming.org/rules/testfirst.html You don't know how many methods/functions (if any) you're going to add to make it pass, so they're explicitly per-functionality.
We're practically a 100% XP shop compiled of ex-Pivots and Thoughtworks. Pairing, TDD and client-on-site as our baseline. We've also been using AI as part of our IDEs full-time for 2+ years.
Yet, the most unexpected thing happened this year on my team of 4 senior/staff-level developers:
Instead of "splintering/pairing off with AI" individually even further, we wound up quadrupling (mobbing) full-time on our biggest project to date. That meant four developers, synchronously, plus Claude Code typing for us, working on one task at a time.
That was one of the most fun, laser-focused and weirdly effective way of combining our XP practice with people and AI.
Yeah, much of XP has just been integrated into modern workflows (for the better!), really getting this out there as a call to arms for folks to _think_ before they churn out 1000s of lines of code with an LLM and ship without thought!
From your perspective, which bits of XP would you consider weird?
Just in case: This is not a call for everyone to "pair program" with an AI.
If you pair program with someone else on your team, you both learn what the other is thinking. You both become more familiar with what the code is doing, and why it's doing it.
If you "pair program" with an AI, anything it learned, it forgets as soon as the prompt is closed.
So don't think that's what he's talking about here. He's talking about XP, with humans, just like in the 1990s. There may be some AI in there too, but that's not where the XP part comes from.
That's only if you don't preserve the results explicitly. If you're trying to delve into some new code without enough docs, I could imagine learning lots about the system along the LLM and then leaving that as documentation and/or agent files in the repo.
> Just in case: This is not a call for everyone to "pair program" with an AI.
If that's not what you're doing, you're likely doing it wrong.
> If you pair program with someone else on your team, you both learn what the other is thinking. You both become more familiar with what the code is doing, and why it's doing it.
Yes.
> If you "pair program" with an AI, anything it learned, it forgets as soon as the prompt is closed.
Same with humans, including your future self. So pair on docs.
TL;DR: You should absolutely be XP pair programming with your LLM.
Extreme Programming attempts to weave together several independently useful concepts into a single paradigm... For that to make sense, the amalgamation of ideas has to be greater than the sum of its parts individually, but it's not clear that this is the case.
TDD is useful in some situations, yep totally. Pair programming is useful in some situations, yes. Continuous integration; yes, much of the time. Frequent feedback; yes, sometimes, for some types of work which doesn't require deep focus...
It just doesn't work as a blanket 'XP' paradigm because you rarely need all these parts all the time, at the same time. IMO, this is why Extreme Programming lacks gumption as a concept. It feels like a bunch of good ideas thrown together. If there was some kind of synergy between those ideas and practices, the concept of XP would be more important.
As it stands today, everyone is implementing maybe 1 or 2 aspects of XP, but almost nobody is implementing ALL of XP... So nobody can claim that they're adhering to XP.
This is not the same as as 'Agile' because with Agile; the vast majority of big companies are implementing maybe 90% of agile practices, with 70% fidelity... This consistency is enough for companies to identify themselves as 'Agile'. I've worked for many companies which implemented ALL of the Agile practices but not one of them actually implemented them exactly as taught in the Agile Manifesto. I think the closest one I worked for was maybe 90% of the way there; they even followed the story point system exactly and used a packet of cards with numbers on them to allow people to vote during Sprint Planning meetings... but anyway, pretty much all the companies/projects I worked for identified themselves 'Agile' because all the practices fit into a single paradigm and there was value in adopting all of them. After a while, it became easier for project managers to just say "Let's switch to Agile" instead of saying "Let's time-box our development work into short increments, with a planning meeting, refinement meeting and retrospective meeting for each 2-week increment."
That's why the XP book arranges itself into values, principles, and practices. The best line in the book is about how practices without underlying values are dead, while values without practices are wishy-washy abstractions. What he's really advocating for at the highest level is skilled teams, who are given ownership, that are actively defining their own processes, and executing them with discipline to produce well-designed and reliable software. The book is a "grab bag" (very legitimate point) because those are the sorts of techniques that those kinds of teams use.
>TDD is useful in some situations, yep totally. Pair programming is useful in some situations, yes. Continuous integration; yes, much of the time. Frequent feedback; yes, sometimes
For production code I do pretty much all of these, always - at least insofar as it is possible (e.g. willing pairing partner).
Im curious to know under which scenarios you think im doing something wrong. Coz I dont think i am.
Agreed, we’ve come a long way since the dogmatic agile of the 90s, and maybe I could be more explicit that this is about introspecting how you’re delivering software (now AI-enabled workflows are everywhere) to decrease the probability of only increasing output (rather than increasing the probability of outcomes) for your users… XP is a good place to start (but not necessarily end).
What is Extreme Programming => XP is an agile methodology that keeps teams laser‑focused on delivering working software through short iterations, tight feedback loops, and simple design, using practices like pair programming, test‑driven development, and continuous integration to adapt quickly to changing needs. It optimizes for learning and quality over raw output: build the smallest thing, test it, ship it, and iterate with the customer.
~ GPT5 in perplexity
What do you mean? I suppose it depends on the company. Maybe big, conservative companies? Startups don't operate on waterfall. Most jobs I've had didn't do the ol' all requirements upfront -> design -> implement dance.
I would also point out that a lot of organizations think scrum ceremonies and sprint satisfy the requirement for ticking the agile checkbox, but in reality, practice waterfall.
Most companies I've seen recently, including a lot of startups, are operating in a waterfall that they then window-dress every 2 weeks in the form of SCRUM-ish rituals and ceremonies as if it's agile because it has iterations and story points or whatever.
Behind the scenes the PMs are making Gantt charts and deciding what's in and what's out and who is going to do it, without the team having any input or really getting to cost it out.
XP and agile generally was supposed to about shortening the communication and iteration gap between customer and maker. I almost never really see that.
Oh, I wasn't arguing that any companies actually do Agile (lower or upper case).
I meant in my experience, the methodology most companies I've worked in seems to follow is capital-C Chaotic. Requirements change at the whim of customers or leadership week to week, pivots are frequent and unpredictable, leadership gets fired/quits and the whole plan changes, lots of effort is wasted on stuff that then gets ignored, and customers are sold one thing but delivered another.
I don't believe organizations or companies follow either Agile (any brand of it) or Waterfall. I don't think what they do can be called a methodology at all.
I would guess "big conservative companies" with waterfall are by far the overwhelming number of programmers, even if agile startups may (may) win be market valuation.
Then there's the definition - like, is SAFE really agile plus so many other hybrid approaches that have veneer of agile as long as we get all requirements up front and have detailed plan.
Maybe! I stopped working for consulting companies early in my career, and that was the last time I saw anything resembling waterfall. After that I worked in product or service companies, and none did detailed requirements/planning prior to implementation, they mostly winged it (calling it "agile", but we know better). Maybe I'm biased.
Beyond consulting companies, there's also just so much back office / line of business software out there - procurement, human resources, payroll, enterprise performance management, etc. Most of it at high level is slow and onerous because it needs to be reliable and predictable. It cannot fail fast and stakeholders place premium on the feeling of certainty / forecasting.
I understand that, but didn't agile arise because that feeling of certainty/forecasting proved false? That is, experience showed that the end result ran over budget, underdelivered or simply wasn't needed anymore by the time it was done?
It's not that Agile is chaotic because it's cool, it simply (allegedly) surfaces the chaos and uncertainty that was already there. And in my limited experience in consulting, I did build one of these heavily specified LOB software that got canceled near finishing, with all of us laid off and all the effort wasted. This was some CRUD system for an insurance company, by the way; "boring" software by definition.
(To be clear: I'm not arguing Agile truly fixed this, just that what was before had serious enough problems to spark a paradigm change).
Oh, I agree, and we can probably sit for 3 hours over a drink (Orange Juice, preferably:) sharing sea stories of executives embracing illusion of predictability and its ultimate fallacy :). But that desire / delusion did not go away. I don't even need to go into politics to showcase that human kind, sadly, on average does not necessarily learn from past experiences and mistakes.
If waterfall didn’t exist then there wouldn’t be release dates and software being pushed out before being done. Waterfall is there; it’s just at the top of the project.
The ol all requirements up front -> design -> implement that people classically associate with waterfall came from an infographic on how not to do waterfall.
Actual waterfall looks very much like actual agile, in that it is designed around iteration loops. The primary difference is that waterfall prescribed steps in the iteration process, and agile is just a set of principles in a manifesto.
TLDR: the original impetus for waterfall is basically what we call agile today.
Someone copy-pasted a random chart from a paper (one the paper specifically said was too problematic) into a DOD process spec, that turned into a standard because the DOD loves to standardize everything, and big companies all adopted the fundamentally flawed approach and called it waterfall.
Most people know nothing about "Waterfall Model" which if you think about it, is just commonsense meta framework using which you can implement any SDLC methodology. Pair it with "Spiral Model" (https://en.wikipedia.org/wiki/Spiral_model) and you are golden.
This excellent writeup by David Olson gives both the history and the correct understanding; The Myth of the 'Waterfall' SDLC - http://www.bawiki.com/wiki/Waterfall.html
Reading this subthread is wild. I worked for NASA earlier in my career. We never used the term waterfall, but the process described by that term is epitomized by large government projects, and NASA engineering culture in particular.
Most of what people are describing here would be unrecognizable to any government program office.
> Actual waterfall looks very much like actual agile, in that it is designed around iteration loops. The primary difference is that waterfall prescribed steps in the iteration process, and agile is just a set of principles in a manifesto.
In that case, I don't believe companies follow either. I've never seen anything as principled (in any form) practiced anywhere.
Companies claiming to do Agile were usually doing some rituals and cosplaying as agile. I don't believe I've ever seen a company doing "waterfall" or anything resembling what your link describes either.
> Actual waterfall looks very much like actual agile, in that it is designed around iteration loops.
No, Waterfall was not agile, it was the diagram from Royce but not what he recommended from his paper (which tore down that diagram). What Royce added to that diagram (fundamentally, just common sense with feedback loops) was closer to agile, though. Royce himself never called anything Waterfall, but what was termed Waterfall was the bad process he tore apart.
Waterfall is suboptimal because it's optimistic and lacks feedback loops. Waterfall as codified was not the improved process Royce described, but the flawed process early in his paper.
It's optimistic because it carries an assumption that you can delineate your development into clear phases with a distinct start and finish. That doesn't work on large projects. You don't spend years designing your new system and then years building it and then years testing it. You commingle each of those, and once you do that, you're not doing Waterfall. You're doing something better, you're using your brain.
Iterative & Incremental, Spiral development, or most ideas out of the Agile movement are better. They incorporate feedback into the project and don't have strongly delineated phases. They don't make 10 year project commitments before they've even written a single requirement. Because these are methods that are realistic.
We didn't get to the moon by Waterfall. The Wright brothers didn't succeed in flight with Waterfall. Linux wasn't developed with Waterfall. Waterfall is a failure for large scale systems.
AI loves waterfall because every time you insert yourself in the agentic coding loop you reduce the velocity of the system, and if the system blocks on your input the reduction can be pretty epic. Beyond that, AI has myopia, and if you tell it to implement something without a larger framework it understands how to slot it into, it'll put it somewhere that makes no sense, duplicate code, make incompatible interfaces, etc. It's much more efficient to just have the system outlined clearly from the get-go, and this also helps because you can generate E2E tests for validation up front to ensure the features really are valid and working.
That is half of it. The other half is that AI is tireless about planning. Most waterfall implementations fail from lack of planning, or when done right (think well managed government programs) are significantly delayed compared with agile because the planning process itself takes forever.
AI will happily spend the human equivalent of months getting the planning details right before implementation. It won’t by default, to be sure, but if prompted right it will. So you can go into a waterfall implantation plan with significantly better and more thought out plans.
Yup, I actually force my agents to build a formally validated CUE spec for everything they build, I have a service that gives them a wizard for interacting with the cue to add/remove/update, then when everything we discuss is represented they can use it to sync a project, which will automatically generate missing unit/e2e tests, iac docs, folder stubs with README.md files, etc. It was a lot of work to get agents to interact with the service correctly, so many facepalm moments, but it's pretty magical when it works.
You can follow my development if you want, I'm developing a lot of stuff in public, https://sibylline.dev/products/ or https://github.org/sibyllinesoft/, I haven't done real releases on anything because it's all alpha and I'm iterating on it rapidly so I don't want to rug pull anyone, but if you want to try something out and hack on it I'm happy to have collaborators!
Interestingly Kent Beck (the originator of Extreme Programming) has been doing a lot with AI coding and figuring out how it could be useful:
https://tidyfirst.substack.com/p/augmented-coding-beyond-the...
I remember he first posted 2+ years ago, back when people first realized ChatGPT might be useful for coding, that "90% of my skills are now worthless and the remaining 10% are worth 1000x"
https://tidyfirst.substack.com/p/90-of-my-skills-are-now-wor...
I’m is the opinion that the test first XP style of development pays more dividends now than ever, simply because you can use it to validate the code that AI generates and importantly it makes it easier to generate code from these AI tools.
One of these "AI coding" things that come across as a code smell is the habit of littering outdated reports/guides in the repo. That seems to be happening here too.
This is clearly an AI-generated report based on the code at the time of the generation. I don't see the point of storing them in the history? Especially as this _updated_v2_from_2025 trail of debris.
https://github.com/KentBeck/BPlusTree3/blob/main/rust/docs/C...
https://github.com/KentBeck/BPlusTree3/blob/main/rust/docs/U...
I think that XP was the only true agile methodology. Agile just got more and more corrupted over the years through stupidity.
Clearly AI programming allows you to quickly close feedback loops. I don't think everything needs a comprehensive set of unit tests though.
But if people can go back and understand the core concept of XP (which again is about feedback loops to me) and take advantage of LLM-based agent systems to create those tight closed feedback loops, then that will be an advance for software engineering.
Starting with XP and in shops doing XP quite intensely has ruined me because I simply can't stomach working in "SCRUM" shops where a whole pile of stuff is taken as "agile" dogma which is mostly just ritualized meaningless bastardizations of things that XP pioneered, turned inside out.
I think the ideal scenario is usually two paired programmer using a shared set of AI agents on the same working branch together. It's an ideal feedback loop of paired planning, reviewing, building, and testing.
> I don't think everything needs a comprehensive set of unit tests though.
There's a difference in the tests of that era though. Around the xp times, unit tests were for unit of functionality, not per-method.
That’s not really true.
“Unit tests are small tests, each one exercising a little piece of functionality. The units tested are usually individual methods, but sometimes clusters of methods or even whole objects.”
Extreme Programming Explained: Embrace Change, 2nd Edition (2004) Kent Beck
You're agreeing with me there. "each one exercising a little piece of functionality". In Beck's approach the tests are added at each step for a simple functionality addition, which then gets implemented in the project to pass the test. These days unit tests are more commonly used as "every method is a unit to be tested completely", often after the implementation is already there.
I don’t see how?
You said: “Around the xp times, unit tests were not per-method.”
Beck said: “Unit tests are usually individual methods”
That quote is saying the same thing as GP.
I also wonder if this is written from a statically-typed perspective. In dynamic-typing land there are so many more stupid little things that can break that the compiler would otherwise catch for you
Either that or tracing/logging/debugging, but other than specific niches like parsing (of specific bug repros) I think integration tests are generally a lot more bang for the buck.
Anyway, if you want to go down a related-but-unrelated rabbit hole, J.R. Thompson's lecture on the Space Shuttle Main Engines is a good one. You can probably watch it at higher speed to smooth out the many, many "uh"s (believe me, it's bad):
Integrated testing: https://youtu.be/uow6v1EuybE?t=1292
Test to failure: https://youtu.be/uow6v1EuybE?t=3135
https://ocw.mit.edu/courses/16-885j-aircraft-systems-enginee...
--
There's this more-modern link but in true modern fashion you can't really link to specific things presumably because it's all javascript muck: https://openlearninglibrary.mit.edu/courses/course-v1:MITx+1...
I think a more accurate version of this is: unit tests were not only per-method but also per functionality. This was often called BDD (Behavior Driven Development), e.g. Ruby's cucumber. Your intuition here is correct though.
I disagree with the "not only". The idea in xp is to write the test first. http://www.extremeprogramming.org/rules/testfirst.html You don't know how many methods/functions (if any) you're going to add to make it pass, so they're explicitly per-functionality.
Depends on how accurately AI can close the loops.
Really? Because there is nothing agile about not shipping half your code to users (unit tests).
If you're not trolling, you're doing a great impression.
We're practically a 100% XP shop compiled of ex-Pivots and Thoughtworks. Pairing, TDD and client-on-site as our baseline. We've also been using AI as part of our IDEs full-time for 2+ years.
Yet, the most unexpected thing happened this year on my team of 4 senior/staff-level developers:
Instead of "splintering/pairing off with AI" individually even further, we wound up quadrupling (mobbing) full-time on our biggest project to date. That meant four developers, synchronously, plus Claude Code typing for us, working on one task at a time.
That was one of the most fun, laser-focused and weirdly effective way of combining our XP practice with people and AI.
Interesting! What tools are using to make this collaboration easier?
I'd totally forgotten about XP.
Funny how some of it is now day-to-day, and other parts of it would be considered extremely weird.
Yeah, much of XP has just been integrated into modern workflows (for the better!), really getting this out there as a call to arms for folks to _think_ before they churn out 1000s of lines of code with an LLM and ship without thought!
From your perspective, which bits of XP would you consider weird?
Just in case: This is not a call for everyone to "pair program" with an AI.
If you pair program with someone else on your team, you both learn what the other is thinking. You both become more familiar with what the code is doing, and why it's doing it.
If you "pair program" with an AI, anything it learned, it forgets as soon as the prompt is closed.
So don't think that's what he's talking about here. He's talking about XP, with humans, just like in the 1990s. There may be some AI in there too, but that's not where the XP part comes from.
That's only if you don't preserve the results explicitly. If you're trying to delve into some new code without enough docs, I could imagine learning lots about the system along the LLM and then leaving that as documentation and/or agent files in the repo.
> Just in case: This is not a call for everyone to "pair program" with an AI.
If that's not what you're doing, you're likely doing it wrong.
> If you pair program with someone else on your team, you both learn what the other is thinking. You both become more familiar with what the code is doing, and why it's doing it.
Yes.
> If you "pair program" with an AI, anything it learned, it forgets as soon as the prompt is closed.
Same with humans, including your future self. So pair on docs.
TL;DR: You should absolutely be XP pair programming with your LLM.
I think you're stretching the definition.
Maybe we need a new term, maybe we don't, but it's not pair programming if you're doing it with an LLM.
> You should absolutely be XP pair programming with your LLM.
If you want AI slop everywhere, that is.
100%
Certainly someone is willing to sell Extreme Vibing (XV) courses.
that’s what onlyfans is predicated on
Extreme Programming attempts to weave together several independently useful concepts into a single paradigm... For that to make sense, the amalgamation of ideas has to be greater than the sum of its parts individually, but it's not clear that this is the case.
TDD is useful in some situations, yep totally. Pair programming is useful in some situations, yes. Continuous integration; yes, much of the time. Frequent feedback; yes, sometimes, for some types of work which doesn't require deep focus...
It just doesn't work as a blanket 'XP' paradigm because you rarely need all these parts all the time, at the same time. IMO, this is why Extreme Programming lacks gumption as a concept. It feels like a bunch of good ideas thrown together. If there was some kind of synergy between those ideas and practices, the concept of XP would be more important.
As it stands today, everyone is implementing maybe 1 or 2 aspects of XP, but almost nobody is implementing ALL of XP... So nobody can claim that they're adhering to XP.
This is not the same as as 'Agile' because with Agile; the vast majority of big companies are implementing maybe 90% of agile practices, with 70% fidelity... This consistency is enough for companies to identify themselves as 'Agile'. I've worked for many companies which implemented ALL of the Agile practices but not one of them actually implemented them exactly as taught in the Agile Manifesto. I think the closest one I worked for was maybe 90% of the way there; they even followed the story point system exactly and used a packet of cards with numbers on them to allow people to vote during Sprint Planning meetings... but anyway, pretty much all the companies/projects I worked for identified themselves 'Agile' because all the practices fit into a single paradigm and there was value in adopting all of them. After a while, it became easier for project managers to just say "Let's switch to Agile" instead of saying "Let's time-box our development work into short increments, with a planning meeting, refinement meeting and retrospective meeting for each 2-week increment."
That's why the XP book arranges itself into values, principles, and practices. The best line in the book is about how practices without underlying values are dead, while values without practices are wishy-washy abstractions. What he's really advocating for at the highest level is skilled teams, who are given ownership, that are actively defining their own processes, and executing them with discipline to produce well-designed and reliable software. The book is a "grab bag" (very legitimate point) because those are the sorts of techniques that those kinds of teams use.
>TDD is useful in some situations, yep totally. Pair programming is useful in some situations, yes. Continuous integration; yes, much of the time. Frequent feedback; yes, sometimes
For production code I do pretty much all of these, always - at least insofar as it is possible (e.g. willing pairing partner).
Im curious to know under which scenarios you think im doing something wrong. Coz I dont think i am.
Agreed, we’ve come a long way since the dogmatic agile of the 90s, and maybe I could be more explicit that this is about introspecting how you’re delivering software (now AI-enabled workflows are everywhere) to decrease the probability of only increasing output (rather than increasing the probability of outcomes) for your users… XP is a good place to start (but not necessarily end).
What is Extreme Programming => XP is an agile methodology that keeps teams laser‑focused on delivering working software through short iterations, tight feedback loops, and simple design, using practices like pair programming, test‑driven development, and continuous integration to adapt quickly to changing needs. It optimizes for learning and quality over raw output: build the smallest thing, test it, ship it, and iterate with the customer. ~ GPT5 in perplexity
Waterfall is the thing that's coming back with AI.
It never went anywhere in the first place
What do you mean? I suppose it depends on the company. Maybe big, conservative companies? Startups don't operate on waterfall. Most jobs I've had didn't do the ol' all requirements upfront -> design -> implement dance.
I would also point out that a lot of organizations think scrum ceremonies and sprint satisfy the requirement for ticking the agile checkbox, but in reality, practice waterfall.
Hm, agreed that the ceremonies are there just to tick some checkbox, but why does it mean this is waterfall "in practice"?
To me, most orgs don't practice any kind of sensible methodology at all. Waterfall implies a rigor they don't have.
Most companies I've seen recently, including a lot of startups, are operating in a waterfall that they then window-dress every 2 weeks in the form of SCRUM-ish rituals and ceremonies as if it's agile because it has iterations and story points or whatever.
Behind the scenes the PMs are making Gantt charts and deciding what's in and what's out and who is going to do it, without the team having any input or really getting to cost it out.
XP and agile generally was supposed to about shortening the communication and iteration gap between customer and maker. I almost never really see that.
Oh, I wasn't arguing that any companies actually do Agile (lower or upper case).
I meant in my experience, the methodology most companies I've worked in seems to follow is capital-C Chaotic. Requirements change at the whim of customers or leadership week to week, pivots are frequent and unpredictable, leadership gets fired/quits and the whole plan changes, lots of effort is wasted on stuff that then gets ignored, and customers are sold one thing but delivered another.
I don't believe organizations or companies follow either Agile (any brand of it) or Waterfall. I don't think what they do can be called a methodology at all.
Ah yeah, that's fair. And my experience too.
I would guess "big conservative companies" with waterfall are by far the overwhelming number of programmers, even if agile startups may (may) win be market valuation.
Then there's the definition - like, is SAFE really agile plus so many other hybrid approaches that have veneer of agile as long as we get all requirements up front and have detailed plan.
Maybe! I stopped working for consulting companies early in my career, and that was the last time I saw anything resembling waterfall. After that I worked in product or service companies, and none did detailed requirements/planning prior to implementation, they mostly winged it (calling it "agile", but we know better). Maybe I'm biased.
Beyond consulting companies, there's also just so much back office / line of business software out there - procurement, human resources, payroll, enterprise performance management, etc. Most of it at high level is slow and onerous because it needs to be reliable and predictable. It cannot fail fast and stakeholders place premium on the feeling of certainty / forecasting.
I understand that, but didn't agile arise because that feeling of certainty/forecasting proved false? That is, experience showed that the end result ran over budget, underdelivered or simply wasn't needed anymore by the time it was done?
It's not that Agile is chaotic because it's cool, it simply (allegedly) surfaces the chaos and uncertainty that was already there. And in my limited experience in consulting, I did build one of these heavily specified LOB software that got canceled near finishing, with all of us laid off and all the effort wasted. This was some CRUD system for an insurance company, by the way; "boring" software by definition.
(To be clear: I'm not arguing Agile truly fixed this, just that what was before had serious enough problems to spark a paradigm change).
Oh, I agree, and we can probably sit for 3 hours over a drink (Orange Juice, preferably:) sharing sea stories of executives embracing illusion of predictability and its ultimate fallacy :). But that desire / delusion did not go away. I don't even need to go into politics to showcase that human kind, sadly, on average does not necessarily learn from past experiences and mistakes.
If waterfall didn’t exist then there wouldn’t be release dates and software being pushed out before being done. Waterfall is there; it’s just at the top of the project.
Those are external factors that exist regardless of methodology. They do not make something "waterfall".
The ol all requirements up front -> design -> implement that people classically associate with waterfall came from an infographic on how not to do waterfall.
Actual waterfall looks very much like actual agile, in that it is designed around iteration loops. The primary difference is that waterfall prescribed steps in the iteration process, and agile is just a set of principles in a manifesto.
Edit: reference: https://beza1e1.tuxen.de/waterfall.html
TLDR: the original impetus for waterfall is basically what we call agile today.
Someone copy-pasted a random chart from a paper (one the paper specifically said was too problematic) into a DOD process spec, that turned into a standard because the DOD loves to standardize everything, and big companies all adopted the fundamentally flawed approach and called it waterfall.
Most people know nothing about "Waterfall Model" which if you think about it, is just commonsense meta framework using which you can implement any SDLC methodology. Pair it with "Spiral Model" (https://en.wikipedia.org/wiki/Spiral_model) and you are golden.
This excellent writeup by David Olson gives both the history and the correct understanding; The Myth of the 'Waterfall' SDLC - http://www.bawiki.com/wiki/Waterfall.html
Reading this subthread is wild. I worked for NASA earlier in my career. We never used the term waterfall, but the process described by that term is epitomized by large government projects, and NASA engineering culture in particular.
Most of what people are describing here would be unrecognizable to any government program office.
> Actual waterfall looks very much like actual agile, in that it is designed around iteration loops. The primary difference is that waterfall prescribed steps in the iteration process, and agile is just a set of principles in a manifesto.
In that case, I don't believe companies follow either. I've never seen anything as principled (in any form) practiced anywhere.
Companies claiming to do Agile were usually doing some rituals and cosplaying as agile. I don't believe I've ever seen a company doing "waterfall" or anything resembling what your link describes either.
They mostly do chaos-driven development.
> Actual waterfall looks very much like actual agile, in that it is designed around iteration loops.
No, Waterfall was not agile, it was the diagram from Royce but not what he recommended from his paper (which tore down that diagram). What Royce added to that diagram (fundamentally, just common sense with feedback loops) was closer to agile, though. Royce himself never called anything Waterfall, but what was termed Waterfall was the bad process he tore apart.
Apple famously uses waterfall.
Which is tragic. Waterfall is almost always the wrong way to do things.
Why? Waterfall is suboptimal mostly due to human failings.
Waterfall is suboptimal because it's optimistic and lacks feedback loops. Waterfall as codified was not the improved process Royce described, but the flawed process early in his paper.
It's optimistic because it carries an assumption that you can delineate your development into clear phases with a distinct start and finish. That doesn't work on large projects. You don't spend years designing your new system and then years building it and then years testing it. You commingle each of those, and once you do that, you're not doing Waterfall. You're doing something better, you're using your brain.
Iterative & Incremental, Spiral development, or most ideas out of the Agile movement are better. They incorporate feedback into the project and don't have strongly delineated phases. They don't make 10 year project commitments before they've even written a single requirement. Because these are methods that are realistic.
We didn't get to the moon by Waterfall. The Wright brothers didn't succeed in flight with Waterfall. Linux wasn't developed with Waterfall. Waterfall is a failure for large scale systems.
AI loves waterfall because every time you insert yourself in the agentic coding loop you reduce the velocity of the system, and if the system blocks on your input the reduction can be pretty epic. Beyond that, AI has myopia, and if you tell it to implement something without a larger framework it understands how to slot it into, it'll put it somewhere that makes no sense, duplicate code, make incompatible interfaces, etc. It's much more efficient to just have the system outlined clearly from the get-go, and this also helps because you can generate E2E tests for validation up front to ensure the features really are valid and working.
That is half of it. The other half is that AI is tireless about planning. Most waterfall implementations fail from lack of planning, or when done right (think well managed government programs) are significantly delayed compared with agile because the planning process itself takes forever.
AI will happily spend the human equivalent of months getting the planning details right before implementation. It won’t by default, to be sure, but if prompted right it will. So you can go into a waterfall implantation plan with significantly better and more thought out plans.
Yup, I actually force my agents to build a formally validated CUE spec for everything they build, I have a service that gives them a wizard for interacting with the cue to add/remove/update, then when everything we discuss is represented they can use it to sync a project, which will automatically generate missing unit/e2e tests, iac docs, folder stubs with README.md files, etc. It was a lot of work to get agents to interact with the service correctly, so many facepalm moments, but it's pretty magical when it works.
> CUE spec
Have you heard of Ada, whose type system does the same thing?
Still waiting/hoping for you to share your stack!
You can follow my development if you want, I'm developing a lot of stuff in public, https://sibylline.dev/products/ or https://github.org/sibyllinesoft/, I haven't done real releases on anything because it's all alpha and I'm iterating on it rapidly so I don't want to rug pull anyone, but if you want to try something out and hack on it I'm happy to have collaborators!
Is hydra the main agent coordination framework?
As a former Pivot and diehard XP dogmatist, yes please!
Yay! NYC Pivot here, see my comment below - we're still doing the thing ;)
[dead]
[flagged]
I'm gonna write a blog post titled "Does Betteridge’s Law always apply?".
Does the exception disprove the rule?
A pair of articles, then: "Is Betteridge's Law Useful?" and "Is Betteridge's Law Useless?"
“Is This Headline An Example of Betteridge’s Law?”
> No. (Betteridge’s Law dictates so)
Maybe. But its not a law. Its a vague heuristic. Thought is still required.