This post sets up a straw man from the outset, and only gets worse from there.
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
This is legislating history at this point, so not sure it really matters...but many of the agile authors directly reference the fact that their ideas are not new, that they date back to the 1970s or earlier, probably referencing the same works the post mentions. Many of the signers of the manifesto worked on projects that were using 'spiral' or 'waterfall-ish' metholodogies, and they wanted a name for it. But you'd have to read the actual body of work to know that, rather than just taking the agile manifesto as the end-point.
It is pretty funny though that the author turns an attack on sell-out corporate Agile into a promotion of spec driven development as some sort of high watermark of software design. Most folks who are really using llms day-in and day-out are realizing the downfalls of focusing entirely on a spec driven approach (see superpowers plugins for one). But hey, history repeats, over and over and over again. I just hope at some point there is some actual acceptance and learning from the past without trashing it for a clickbait blog post.
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
I directly mentioned, linked, and repeatedly quoted from the Agile Manifesto in my "clickbait blog post". Half the point was that it was nothing but a set of platitudes, not enough to count as a process. So what is there to criticise? If we see agile practiced in the wild, we are told it's not Real Agile. If we ask what is Real Agile, we are told the manifesto. When we look at the manifesto, it lacks substance. I'm done with the loop.
I would disagree that the manifesto is 'nothing but a set of platitudes'. The problem with platitudes is that they just repeat clearly good things without adding more information or questioning why those obviously good things are not already implemented. 'Responding to change over following a plan' or 'customer collaboration over contract negotiation' are not straightforwardly, obviously correct: they lay out a vision of how software work should be done, with certain priorities, and that vision stands in contrast to how most software work was done at the time and today.
I'm inclined to think the vision laid out there is a pretty good one.
And yet.
Basically everyone I've ever spoken to or read on the subject, including some of the signatories like Ron Jeffries, agree that the vast majority of actual 'Agile' implementations in actual workplaces totally fail to live up to that vision or actually prioritize those priorities. When this is pointed out, Agile's defenders claim that it's not 'Real Agile' and invariably recommend an overpriced consultant who is definitely going to fix it this time, promise.
I don't think this means we should dismiss the manifesto entirely, or the vision in it. But we should question why these seemingly very nice sets of priorities virtually always fail on contact with actual workplaces, even (or especially) when those workplaces put a lot of time and effort and money into implementing them.
I'm of the opinion that it's because the vision of work in the manifesto is fundamentally incompatible with the requirements of corporate management structures, which usually prioritize legibility over effectiveness. But the people supporting these structures aren't able to introspect to that degree and are always looking for some magic bullet that will fix the problems inherent in the system. That's where capital-A Agile, usually Scrum, comes in with big promises aimed squarely at management, rather than the programmers actually doing the work. It's a way to reinforce the structure while giving the outward appearance that things have changed, at the cost of the individual contributors. See also Ron Jeffries talking about how basically all Scrum certifications are for managers, not for programmers.
You're right that the manifesto doesn't lay out a process, because all the 'processes' predate the manifesto. Scrum, XP, Crystal, DSDM, were all around for years before their creators got together in a ski lodge and tried to figure out "what is the core that we all agree on". And the answer was almost nothing besides these four sets of priorities, because the processes shared no common ancestor and weren't built off the same foundation. All they really shared was an objection to the currently-dominant waterfall-ish model, but they didn't all have the same objections.
I've written more on the subject here.
Altogether, I think the subject is more ambiguous and worthy of study than your article makes it out to be.
Altogether, I think the subject is more ambiguous and worthy of study than your article makes it out to be.
One thing I tried to set out in my article - though perhaps hidden in footnotes - is that I am slowly working my way through the 20th century.
I mainly tackled the two papers where the Waterfall Bogeyman - in both papers, shown as an example of what not to do - are said to come from. But "No Silver Bullet" also says a lot on this, and I today I will read the pre-cursor to Scrum (from product manufacturing in the 80s).
So, I feel like I am making a decent dent in studying software methodologies. I will only do so through serious papers and articles, and not books from consultants.
the manifesto was a starting point. a stake in the ground. It is not and was not meant to be an in depth practioner's guide, or an exhaustive review of the history of software dev practices and the many varieties that already existed, many of which were 'agile' before the term was coined.
To find things beyond the 'platitiudes', all it takes is googling pretty much any of the signatories to find their books, published papers, talks, blog posts, mailing list posts, the c2 wiki, the list goes on. This is was a vibrant and often combative area for discussion and analysis and 'lessons learned' from many people who were trying things as the industry matured and tech advanced.
The manifesto was just one piece of a much larger thing, and to focus on it and ignore everything else misses a much larger, rich, and interesting discussion that is still ongoing.
If that's all it is, people should have the honesty to say they mean XP, Scrum, or whatever the hell else they mean. But they don't. They point to the manifesto.
All we've established is that "agile" is useless as a term.
Man, I have really unlearned a lot of ideas everyone agreed on back when I was a baby programmer building Rails apps. I learned all about Uncle Bob and his "clean code" and his "agile manifesto", and I read DHH blog posts about how duck typing is great because it's flexible, how OOP is great and it just makes sense because it works like the real world. Hell I even thought metaprogramming was a good idea in cases where it was absolutely not necessary, just because so many other people were doing it in the Ruby world.
Kinda wish I hadn't spun my wheels on bad ideas for so long.
I mean, a lot of those things aren't necessarily bad. The bigger problem, I feel, is the tendency for many people (certainly in IT) to put things in binary categories and definitions. While things rarely are.
The original manifesto doesn't provide all these rules and rituals people think about now. And it most certainly didn't define the four core principles as binary either or statements. But that is exactly how many people came to see them. So "Working software over comprehensive documentation" became "code is the documentation" where in reality it is more along the lines of "documentation is important, but it is more important that the software works rather than the exact right word and comma is used in paragraph 5, subsection 3a".
The same thing happened with clean code. The dogmatic stuff (every function must be five lines, abstract everything) deserves the backlash it gets. But it also very much brought attention to basic readability, decent naming and not writing needlessly clever code. That's just good practice. Saying "clean code was a bad idea" ignores that we still apply many principles from it we otherwise might not have.
From my perspective the lesson shouldn't be "those ideas were bad". It is more that any idea applied as a universal rule will eventually bite you. Even more so if you follow them without understanding the principles and ideas behind them. Like your metaprogramming example, doing it because a lot of people do it without understanding why they are doing it.
Idunno, metaprogramming is pretty necessarily bad if there's any other reasonable way to accomplish the same thing. And personally after working with typed languages, I hate to go back to duck-typing for anything that won't fit on one screen. I feel like half the tests I wrote were for things a typechecker would catch before I finish writing the function.
I'll concede that some elements of OOP are pretty good; functions on a struct can be handy and adding behavior through composition is a good pattern. Deliberate consideration of your namespaces is another one. Inheritance sure isn't, though, and I used to do a lot of it.
If by "clean code" you mean "organized, obvious, working code" well then yeah of course it's good, but it's also not exactly cosmic advice (unless you're saying it was at the time?). I understood "clean code" to mean "small, simple functions", which led me to introduce so many layers of misdirection that tracking down the actual implementation for anything became a chore (exacerbated by the fact that static analysis of Ruby is pretty limited).
I think that some ideas actually are bad in almost all cases, but it took awhile for us to collectively figure that out. You're right though, a lot of ideas aren't bad themselves, they're just situational and we started to treat them as universal.
Idunno, metaprogramming is pretty necessarily bad if there's any other reasonable way to accomplish the same thing.
Fair, some practices have such niche use case and such a heavy learning curve they probably shouldn't have been as popular and widespread as they were.
well then yeah of course it's good, but it's also not exactly cosmic advice (unless you're saying it was at the time?)
At the time it certainly wasn't universal cosmic advice. To be clear, it isn't as if all of the practices were completely new and unknown. But they certainly were not as widely practiced in the entire industry.
What clean code mostly did is bundle a lot of different practices in a highly opinionated fairly easy to read rule book. That's probably why it got such traction in the industry as it became a sort of onboarding manual for many developers giving them and teams a shared baseline.
I understood "clean code" to mean "small, simple functions", which led me to introduce so many layers of misdirection that tracking down the actual implementation for anything became a chore (exacerbated by the fact that static analysis of Ruby is pretty limited).
Clean code is much more than that, but this specifically is where I, and probably most people, agree the concept was taken too far and absolute.
Because of that strictness and the resulting over-abstracted code you eventually did see to start a lot of push back and a decline in popularity. But a lot of other practices that were popularized thanks to the book remain still in use.
It's often how it works, it is an ebb and flow where you'll see a technique/methodology become popular in response to something and then decrease in popularity but leaving behind some practices.
I think that some ideas actually are bad in almost all cases, but it took awhile for us to collectively figure that out. You're right though, a lot of ideas aren't bad themselves, they're just situational and we started to treat them as universal.
I can really recommend "The principles of product development flow" by Donald G. Reinertsen. He explains in multiple dimensions in great detail and very practically how to setup research & development organization, which don‘t just include software companies. Really a great read. His work is a mixture of Kanban, Agile, Scrum and Lean Manufacturing.
I really don't get why there's any dogma at all about specs or prototypes. It's so dependent on what each project is, on the context… Use your intuition every time to decide whether writing specs is worth it or jumping into prototyping is easier.
I'm a lot more sympathetic to agile than this post is, but on "waterfall": agile established the narrative about the bad old waterfall it rescued us from. Everybody kept repeating that narrative. Such dominant cultural narratives should be viewed with some suspicion. In reality of course people did all kinds of things.
When I read "Debugging the Development Process" by Steve Maguire from 1994 it struck me how quite a bit of it echoed agile, though not everything did. One of the biggest points it makes: fixing bugs when they are detected, instead of deferring them to the end and writing a lot more code, strikes me as very iterative in nature. Apparently some developers would be seen as heroes because they would crank out a lot of code, but left the bugs in them to be debugged later, possibly by others, before release which pre-internet was a lot more involved than it is now.
I find it hard to distinguish learning to do software development as a young developer from what was in the culture at the time, but I certainly picked up notions of collaborative development, iterative development and writing tests from XP and agile. Now writing tests is wide-spread, but I wish the notion of collaboration during development were more widespread, rather than the mindset of interacting with each other mostly through PR reviews. But PRs are very legible to a corporation, and companies often prefer to do what's more legible rather than what's more effective.
Well put. This article gives the “old” truth. Typically, for other than the largest government, military, and industry projects, iterative development largely preceded agile. However, the “new” truth repeated ad-nauseam (by those that weren’t there) is that nothing existed before agile but “evil” waterfall. A lie repeated often enough becomes the truth.
All the 1970s papers I quoted were from people in US military, or adjacent civilian contractors (not sure how that works). I believe that's where the spiral model came from as well. Though I suppose just because it was described and published, does not mean it was followed...
Just finding out now that the "scrum" methodology came from an article in the Harvard Business Review about product manufacturing, in 1986. Interestingly they also have a waterfall-esque diagram, followed by one immediately showing overlapping phases (ie the right way to do it).
There were 2 things i hated about agile/scrum, first was the lack of a proper planing phase. The argument was "we work agile, we plan every sprint, a rough project understanding is enough", which led often to planings with too little detail about the features, constant contact with the customer to clear things up. The second thing was giving the customer to much influence during implementation phase. Most of the time a non technical customer doesnt know what he exactly wants, so the tech guys (us) should take the project lead, but with agile we considered the customer also as project leader (adding new features, completely changes features), which complicated the dev process and in the end made projects much more expensive.
I agree completely with these two items. I have never been a big fan of Agile (with a capital A), but it did have some good points. Those points just generally weren't new at all.
Why the hell has a "vibecoding" tag been added to this?
I said that LLMs had brought spec driven development back into fashion, and that regardless of whether one used LLMs or not, it was still a good idea. LLMs merely brought it into focus.
rsanheim | a day ago
This post sets up a straw man from the outset, and only gets worse from there.
The version of agile many programmers, managers, and 'tech people' know is the capital-A Agile version: watered down, sold and peddled via certifications, medium posts, and Atlassian flavored kanban boards.
This is legislating history at this point, so not sure it really matters...but many of the agile authors directly reference the fact that their ideas are not new, that they date back to the 1970s or earlier, probably referencing the same works the post mentions. Many of the signers of the manifesto worked on projects that were using 'spiral' or 'waterfall-ish' metholodogies, and they wanted a name for it. But you'd have to read the actual body of work to know that, rather than just taking the agile manifesto as the end-point.
It is pretty funny though that the author turns an attack on sell-out corporate Agile into a promotion of spec driven development as some sort of high watermark of software design. Most folks who are really using llms day-in and day-out are realizing the downfalls of focusing entirely on a spec driven approach (see superpowers plugins for one). But hey, history repeats, over and over and over again. I just hope at some point there is some actual acceptance and learning from the past without trashing it for a clickbait blog post.
[OP] LAC-Tech | a day ago
I directly mentioned, linked, and repeatedly quoted from the Agile Manifesto in my "clickbait blog post". Half the point was that it was nothing but a set of platitudes, not enough to count as a process. So what is there to criticise? If we see agile practiced in the wild, we are told it's not Real Agile. If we ask what is Real Agile, we are told the manifesto. When we look at the manifesto, it lacks substance. I'm done with the loop.
Well I'm glad I could make you laugh
nrposner | 21 hours ago
I would disagree that the manifesto is 'nothing but a set of platitudes'. The problem with platitudes is that they just repeat clearly good things without adding more information or questioning why those obviously good things are not already implemented. 'Responding to change over following a plan' or 'customer collaboration over contract negotiation' are not straightforwardly, obviously correct: they lay out a vision of how software work should be done, with certain priorities, and that vision stands in contrast to how most software work was done at the time and today. I'm inclined to think the vision laid out there is a pretty good one.
And yet.
Basically everyone I've ever spoken to or read on the subject, including some of the signatories like Ron Jeffries, agree that the vast majority of actual 'Agile' implementations in actual workplaces totally fail to live up to that vision or actually prioritize those priorities. When this is pointed out, Agile's defenders claim that it's not 'Real Agile' and invariably recommend an overpriced consultant who is definitely going to fix it this time, promise.
I don't think this means we should dismiss the manifesto entirely, or the vision in it. But we should question why these seemingly very nice sets of priorities virtually always fail on contact with actual workplaces, even (or especially) when those workplaces put a lot of time and effort and money into implementing them.
I'm of the opinion that it's because the vision of work in the manifesto is fundamentally incompatible with the requirements of corporate management structures, which usually prioritize legibility over effectiveness. But the people supporting these structures aren't able to introspect to that degree and are always looking for some magic bullet that will fix the problems inherent in the system. That's where capital-A Agile, usually Scrum, comes in with big promises aimed squarely at management, rather than the programmers actually doing the work. It's a way to reinforce the structure while giving the outward appearance that things have changed, at the cost of the individual contributors. See also Ron Jeffries talking about how basically all Scrum certifications are for managers, not for programmers.
You're right that the manifesto doesn't lay out a process, because all the 'processes' predate the manifesto. Scrum, XP, Crystal, DSDM, were all around for years before their creators got together in a ski lodge and tried to figure out "what is the core that we all agree on". And the answer was almost nothing besides these four sets of priorities, because the processes shared no common ancestor and weren't built off the same foundation. All they really shared was an objection to the currently-dominant waterfall-ish model, but they didn't all have the same objections. I've written more on the subject here.
Altogether, I think the subject is more ambiguous and worthy of study than your article makes it out to be.
[OP] LAC-Tech | 12 hours ago
Altogether, I think the subject is more ambiguous and worthy of study than your article makes it out to be.
One thing I tried to set out in my article - though perhaps hidden in footnotes - is that I am slowly working my way through the 20th century.
I mainly tackled the two papers where the Waterfall Bogeyman - in both papers, shown as an example of what not to do - are said to come from. But "No Silver Bullet" also says a lot on this, and I today I will read the pre-cursor to Scrum (from product manufacturing in the 80s).
So, I feel like I am making a decent dent in studying software methodologies. I will only do so through serious papers and articles, and not books from consultants.
tome | 22 hours ago
Were those instances of agile you saw practised in the wild in keeping with the manifesto, in particular the twelve principles?
[OP] LAC-Tech | 12 hours ago
Principles are not a methodology. They are in the eye of the beholder.
A collection of aphorisms is not a software development process.
rsanheim | 11 hours ago
the manifesto was a starting point. a stake in the ground. It is not and was not meant to be an in depth practioner's guide, or an exhaustive review of the history of software dev practices and the many varieties that already existed, many of which were 'agile' before the term was coined.
To find things beyond the 'platitiudes', all it takes is googling pretty much any of the signatories to find their books, published papers, talks, blog posts, mailing list posts, the c2 wiki, the list goes on. This is was a vibrant and often combative area for discussion and analysis and 'lessons learned' from many people who were trying things as the industry matured and tech advanced.
The manifesto was just one piece of a much larger thing, and to focus on it and ignore everything else misses a much larger, rich, and interesting discussion that is still ongoing.
[OP] LAC-Tech | 8 hours ago
If that's all it is, people should have the honesty to say they mean XP, Scrum, or whatever the hell else they mean. But they don't. They point to the manifesto.
All we've established is that "agile" is useless as a term.
qznc | 18 hours ago
I like Bertrand Meyer’s take on Agile but it is a whole book. My book review.
rbuchberger | a day ago
Man, I have really unlearned a lot of ideas everyone agreed on back when I was a baby programmer building Rails apps. I learned all about Uncle Bob and his "clean code" and his "agile manifesto", and I read DHH blog posts about how duck typing is great because it's flexible, how OOP is great and it just makes sense because it works like the real world. Hell I even thought metaprogramming was a good idea in cases where it was absolutely not necessary, just because so many other people were doing it in the Ruby world.
Kinda wish I hadn't spun my wheels on bad ideas for so long.
creesch | a day ago
I mean, a lot of those things aren't necessarily bad. The bigger problem, I feel, is the tendency for many people (certainly in IT) to put things in binary categories and definitions. While things rarely are.
The original manifesto doesn't provide all these rules and rituals people think about now. And it most certainly didn't define the four core principles as binary either or statements. But that is exactly how many people came to see them. So "Working software over comprehensive documentation" became "code is the documentation" where in reality it is more along the lines of "documentation is important, but it is more important that the software works rather than the exact right word and comma is used in paragraph 5, subsection 3a".
The same thing happened with clean code. The dogmatic stuff (every function must be five lines, abstract everything) deserves the backlash it gets. But it also very much brought attention to basic readability, decent naming and not writing needlessly clever code. That's just good practice. Saying "clean code was a bad idea" ignores that we still apply many principles from it we otherwise might not have.
From my perspective the lesson shouldn't be "those ideas were bad". It is more that any idea applied as a universal rule will eventually bite you. Even more so if you follow them without understanding the principles and ideas behind them. Like your metaprogramming example, doing it because a lot of people do it without understanding why they are doing it.
rbuchberger | 14 hours ago
Idunno, metaprogramming is pretty necessarily bad if there's any other reasonable way to accomplish the same thing. And personally after working with typed languages, I hate to go back to duck-typing for anything that won't fit on one screen. I feel like half the tests I wrote were for things a typechecker would catch before I finish writing the function.
I'll concede that some elements of OOP are pretty good; functions on a struct can be handy and adding behavior through composition is a good pattern. Deliberate consideration of your namespaces is another one. Inheritance sure isn't, though, and I used to do a lot of it.
If by "clean code" you mean "organized, obvious, working code" well then yeah of course it's good, but it's also not exactly cosmic advice (unless you're saying it was at the time?). I understood "clean code" to mean "small, simple functions", which led me to introduce so many layers of misdirection that tracking down the actual implementation for anything became a chore (exacerbated by the fact that static analysis of Ruby is pretty limited).
I think that some ideas actually are bad in almost all cases, but it took awhile for us to collectively figure that out. You're right though, a lot of ideas aren't bad themselves, they're just situational and we started to treat them as universal.
creesch | 7 hours ago
Fair, some practices have such niche use case and such a heavy learning curve they probably shouldn't have been as popular and widespread as they were.
At the time it certainly wasn't universal cosmic advice. To be clear, it isn't as if all of the practices were completely new and unknown. But they certainly were not as widely practiced in the entire industry. What clean code mostly did is bundle a lot of different practices in a highly opinionated fairly easy to read rule book. That's probably why it got such traction in the industry as it became a sort of onboarding manual for many developers giving them and teams a shared baseline.
Clean code is much more than that, but this specifically is where I, and probably most people, agree the concept was taken too far and absolute.
Because of that strictness and the resulting over-abstracted code you eventually did see to start a lot of push back and a decline in popularity. But a lot of other practices that were popularized thanks to the book remain still in use. It's often how it works, it is an ebb and flow where you'll see a technique/methodology become popular in response to something and then decrease in popularity but leaving behind some practices.
Yup, that's mainly what I am getting at :)
tome | 22 hours ago
Is there a specific element of the agile manifesto you disagree with?
JulianWgs | a day ago
I can really recommend "The principles of product development flow" by Donald G. Reinertsen. He explains in multiple dimensions in great detail and very practically how to setup research & development organization, which don‘t just include software companies. Really a great read. His work is a mixture of Kanban, Agile, Scrum and Lean Manufacturing.
valpackett | a day ago
I really don't get why there's any dogma at all about specs or prototypes. It's so dependent on what each project is, on the context… Use your intuition every time to decide whether writing specs is worth it or jumping into prototyping is easier.
faassen | a day ago
I'm a lot more sympathetic to agile than this post is, but on "waterfall": agile established the narrative about the bad old waterfall it rescued us from. Everybody kept repeating that narrative. Such dominant cultural narratives should be viewed with some suspicion. In reality of course people did all kinds of things.
When I read "Debugging the Development Process" by Steve Maguire from 1994 it struck me how quite a bit of it echoed agile, though not everything did. One of the biggest points it makes: fixing bugs when they are detected, instead of deferring them to the end and writing a lot more code, strikes me as very iterative in nature. Apparently some developers would be seen as heroes because they would crank out a lot of code, but left the bugs in them to be debugged later, possibly by others, before release which pre-internet was a lot more involved than it is now.
I find it hard to distinguish learning to do software development as a young developer from what was in the culture at the time, but I certainly picked up notions of collaborative development, iterative development and writing tests from XP and agile. Now writing tests is wide-spread, but I wish the notion of collaboration during development were more widespread, rather than the mindset of interacting with each other mostly through PR reviews. But PRs are very legible to a corporation, and companies often prefer to do what's more legible rather than what's more effective.
aryeh | a day ago
Well put. This article gives the “old” truth. Typically, for other than the largest government, military, and industry projects, iterative development largely preceded agile. However, the “new” truth repeated ad-nauseam (by those that weren’t there) is that nothing existed before agile but “evil” waterfall. A lie repeated often enough becomes the truth.
[OP] LAC-Tech | a day ago
All the 1970s papers I quoted were from people in US military, or adjacent civilian contractors (not sure how that works). I believe that's where the spiral model came from as well. Though I suppose just because it was described and published, does not mean it was followed...
Just finding out now that the "scrum" methodology came from an article in the Harvard Business Review about product manufacturing, in 1986. Interestingly they also have a waterfall-esque diagram, followed by one immediately showing overlapping phases (ie the right way to do it).
qznc | 18 hours ago
I wrote up the Waterfall history once and how Iterative came before it.
[OP] LAC-Tech | 9 hours ago
Oh that's awesome... we have been down the same rabbithole and quote the same two papers!
mro | a day ago
and finally washed away by vibe, isn't it?
drrobotic | a day ago
There were 2 things i hated about agile/scrum, first was the lack of a proper planing phase. The argument was "we work agile, we plan every sprint, a rough project understanding is enough", which led often to planings with too little detail about the features, constant contact with the customer to clear things up. The second thing was giving the customer to much influence during implementation phase. Most of the time a non technical customer doesnt know what he exactly wants, so the tech guys (us) should take the project lead, but with agile we considered the customer also as project leader (adding new features, completely changes features), which complicated the dev process and in the end made projects much more expensive.
zod000 | 21 hours ago
I agree completely with these two items. I have never been a big fan of Agile (with a capital A), but it did have some good points. Those points just generally weren't new at all.
[OP] LAC-Tech | 8 hours ago
Why the hell has a "vibecoding" tag been added to this?
I said that LLMs had brought spec driven development back into fashion, and that regardless of whether one used LLMs or not, it was still a good idea. LLMs merely brought it into focus.