Blaming Agile for software stagnation puts the wrong villain in the wrong play

It's more about the wave of imposters that came with Agile, than the methodology itself. There are more non-technical gatekeepers in software than actual engineers. Many of the important decision making responsibilities have been factored out of real engineering roles and assigned to Imposter Roles (think titles ending in "Manager"). At most tech companies, the ability to innovate is severely limited by the intellectual capacity of several imposters inserted along the critical path.

There definitely is stagnation in software, but Agile doesn't seem to me like the culprit? I more blame the infinite abstraction layers we design, because we can't be bothered to learn about the details of the system we're using, and we'd rather use an abstraction that makes the easy things easy and the hard things impossible. It still puzzles me how many web developers in the company I work for don't know how HTTP works.

If anything, we used to have much fewer, but much more competent, developers, and with the explosion of demand, the bar was lowered to include the (many more) less competent people. The only way the less competent people can produce usable software is if things are made easier, and they struggle with understanding the systems more deeply.

Another linguistic confusion here. The author doesn't seem to clarify what exactly he thinks "agile" even means, which is not really surprising given that the original formulation [0] of "individuals and interactions over processing and tools" has somehow been co-opted and appropriated by the Scrum certified managerial class into an enterprise-scale methodology. There is Scrum(tm), and then there is kanban, and eXtreme Programming/XP, and your own homespun variant of "agile" that your team honed after a couple of years of working together and evolving your own working agreements... which one is under discussion here, and what are your definitions? The equivocation deepens once the author starts bringing devops into the picture, widening the already frighteningly large umbrella term "agile" into a diffuse, ill-defined mess:

    All the sins Marlinspike ascribes to Agile - siloing, big picture blindness, 
    suppression of skills acquisition - are explicitly addressed by devops, which
    is entirely compatible with Agile.

That being said, Moxie doesn't seem to clarify what _he_ means by "agile," either:

    Anybody who is managing an engineering organization will have some kind of
    management philosophy that is in some way downstream of, derivative of, in
    the zone of, or somehow related to agile [...] [1]

- but given that both his remarks and TFA's recapitulation of those remarks tend to revolve around technical practices, and abstraction in particular, let's try to bring an infamous example to bear to illuminate what exactly Moxie meant by "onboarding people into software by putting them into black box abstraction layers:" Ron Jeffries' sudoku solver attempt (found at [2] and discussed ad nauseam here on HN [3]) using an array of technical practices often espoused by the "software craftsmanship"/eXtreme Programming constellation of Agile: TDD, obsessive refactoring and renaming, and object-orientation to the extreme, hoping that if you soak the problem in sufficiently many layers of abstraction, the solution will just magically fall out. Five articles into Jeffries' saga and he is still refactoring and extracting objects; Peter Norvig's solution [4] by comparison is about 200 lines of Python, without a single class definition, in a shameless and brutalist (metaphorically) procedural style.

I would venture to guess that it is the former style of programming, overladen with tangled object graphs and pigeonholing of problem domains into object-oriented solution spaces (which accompanies much of the old-school Agile Manifesto and eXtreme Programming crowds) that Moxie is rallying against. Norvig's solution, on the other hand, is indeed "wizardrous" and exhibits the quality of deeply understanding the problem that Moxie espouses. There are hardly any abstractions to hide behind in those 200 lines.

On a personal basis, I cut my teeth on eXtreme Programming and TDD and Uncle Bob and Fowler's "Refactoring", so I have seen their merits; unfortunately I feel that the craftsmanship movement these folks fostered has been co-opted, cargo culted, and diluted to the point of inefficacy.

[0] https://agilemanifesto.org/

[1] https://www.theregister.com/2024/08/09/marlinspike/

[2] https://ronjeffries.com/xprog/articles/oksudoku/

[3] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

[4] https://norvig.com/sudoku.html

After like 5 paragraphs without any red string or point being made i gave up. Is there any connection between the title and the text? It feels like some good AI talking random tangential things.