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 o

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/ https://agilemanifesto.org/ [1] https://www.theregister.com/2024/08/09/marlinspike/ https://www.theregister.com/2024/08/09/marlinspike/ [2] https://ronjeffries.com/xprog/articles/oksudoku/ https://ronjeffries.com/xprog/articles/oksudoku/ [3] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&query=jeffries%20sudoku&sort=byPopularity&type=all https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu... [4] https://norvig.com/sudoku.html https://norvig.com/sudoku.html