author: @sleepyfox
title: The corruption of critical thinking
date: 05-Apr-2014
preamble: An open letter to Mr. Binstock and Dr. Dobbs addressing their recent editorial entitled "The Corruption of Agile" and its follow-up article addressing feedback from the community.

EDITED: 2024-10-29 in order to fix broken links and to use the Internet Archive in order to make available material which commercial publishers have egregiously removed - see Fox's 8th Law¹. Sadly it appears that my closing hope was not upheld over the intervening decade by the recipients.

Dear Mr. Binstock,

I recently read your editorial piece entitled "The Corruption of Agile"² in which you argue that with the mainstream adoption of Agile the loss of its intent and the replacement with doctrine has undermined its effectiveness.

I also read the follow-ups by Rob Myers³ and Robert C. "UncleBob" Martin⁴, whose 'letters to the Editor' were themselves addressed in your return piece entitled "Addressing the Corruption of Agile"⁵

Please correct me if I am wrong, but your central argument appears to run as follows:

1. You are distressed over a growing tone of fundamentalism about Agile in the IT community, particularly in Testing
2. You see some practices associated with Agile methodologies (TDD was mentioned) you characterise as being preached with a near religious fervour
3. You criticise the use of the Waterfall model by some Agile activists as a straw-man
4. You accuse programmers of emulating a culture's practices without understanding their roots
5. You claim quality software pre-dates Agile, therefore Agile cannot be the cause of improving software quality
6. You claim it is possible to follow the rites of a methodology and not reap the benefits, because the value and principles underlying that method are not understood
7. You affirm that Agile is not Scrum

Let's examine these individually.

I've seen three decades of methodologies, from structured (JSD, SSADM) to iterative (Boehm Spiral, RAD, RUP, DSDM) to OO (Coad-Yourdon, Booch Method) to Agile (XP, Scrum, FDD, Crystal) to Post-Agilism (Lean Startup, Continuous Delivery, Lean Software Development, Lean UX)...

If there is one constant during those three decades it is that people who don't completely understand the method will sell it, based purely upon their own belief with no evidence or science to back it up. It's a flaw of human psychology that if something seems congruent with our world model we will assume it is true until proven otherwise, and the proving is very difficult the more the thing becomes interconnected with our internal model. This is not limited to software development methodologies, or even methodology in general, but is rather a universal constant of human experience and the foundation of dogma.

I too have noted a tone of fundamentalism is some places in our industry. I have even heard the term 'Scrumdamentalist' mentioned. I'm not fond of this trend, not because I have anything against belief, or Agile per se. but simply because I think that having an opinion based upon a total lack of critical thought is not a good reflection upon the individual.

Criticising anything (including Agile) because some people will believe it without proof, is a criticism of people (in general), not Agile (in particular).

I like TDD. Do I think it is the cure for all ills? No. Do I think it has helped me improve the standard of my technical skills? Yes. Would I go back to doing it the way I did before? No. Rob Myers article³ has plenty of explanation of the 'why' that this is so, so I'm not going to reinvent the wheel. Please read it.

Your evaluation of Myers article, pointing out "All the benefits (of TDD) he lists could be attained equally by writing tests after the code, rather than before" - completely ignores a) the aspect of using test-first as a design tool, and b) the use of refactoring, neither of which the method of 'write tests afterwards to check work' give. This is a typical mistake that people make when evaluating TDD without actually having experience working with it.

You further point out "I have no difficulty with any of Myers' points, save the implication that you need TDD to do this". I don't think anyone is saying that TDD is the only way of achieving quality code, that would clearly be fallacious. What is clear is that a lot of people are getting benefit from TDD, and are writing better code.

I would further emphasise Uncle Bob's point that if you (or anyone else for that matter) know of a better way, please inform us. Saying a method is theoretically not the only way of achieving a desired result is not an argument not to use that method.

I will close this with paraphrasing Winston Churchill: "TDD is the worst form of building software, except all those other forms that have been tried from time to time."

The comparison of Agile with Waterfall is triply fallacious, first because it is an obvious straw-man argument; secondly because even the founder of the Waterfall method, Winston Royce, notes in his original paper⁶ "the implementation described above is risky and invites failure"; and thirdly because no-one actually develops software using Waterfall. Winston's paper shows many different forms of software development that actually do occur when you try (unsuccessfully) to use the Waterfall model, all of them looking less like a Waterfall and more like an explosion in the plumbing department of a DIY store.

The fact that people who don't actually understand the methodologies that we used before Agile are trying to sell Agile based upon something that no-one is actually using (e.g. Waterfall) says nothing about Agile, and everything about hucksters.

You quote Alan Kay saying that "programming has become a pop-culture" and that programmers have no idea where it came from. This, despite being stereotypical I can agree seems common (at least in my experience here in London). If there is a call to arms here it is for us IT professionals to take a greater interest in the history of our profession, and let's face it, there isn't all that much of it compared to say Law or Civil Engineering.

Those that ignore History are doomed to repeat it. Point upheld, but not valid as an argument against Agile is it applies to all IT professionals generally.

Firstly, let's put to bed a myth "It will pain some readers to know that the vast, error-free Internet pre-dates Agile".

I'm sorry Mr. Binstock - the vast Internet is anything but error-free. Part of the very reason for the success of the Internet is that it was designed as a resilient system that was tolerant and accepting of errors. If there was any doubt in your mind about this, just try Googling "Cisco router fault". Come back when you're done; I won't hold my breath.

That example aside, it is obvious that Agile practices, like oranges, are not the only fruit. Does anyone really believe that you have to adopt the One True Way: Agile in order to be able to develop quality software? I doubt it.

What I will put forward is the hypothesis that using an Agile methodology will help a team develop a valuable software product that satisfies the customer, faster - because this is a core principle!

This is tautological, we are in effect saying: "If we focus on building a quality product, we're more likely to build a quality product". The fact that it was possible to develop quality software without Agile says nothing about Agile's utility, and is hence fallacious as an argument.

You put forth the argument that it is possible to adopt the ceremonies of Agile, but not understanding the values and principles fail to reap the benefits of Agile.

Really? I'm shocked. How is this different from any other method, system or field of study? This cannot be effectively used as an argument against Agile.

Good, we have managed to separate two different concepts.

The word Agile may mean:

• Adj. "quick and well-coordinated in movement" or "marked by an ability to think quickly; mentally acute or aware"
• One of a family of lightweight software development methodologies e.g. Scrum or XP
• A tool, technique or practice deriving from a lightweight software development methodology
• An approach to software development characterised by a manifesto of four values and twelve principles⁷

Scrum itself is Agile, because Scrum was developed according to the values and principles that were later made manifest in the Agile Manifesto[6]. Any particular implementation of Scrum may not be Agile, if the implementation does not follow those values and principles. I'm uncertain that this actually warrants saying due to it being rather obvious. A plan and the execution of that plan are two different things, and a good plan does not guarantee a good execution.

Similarly a methodology can be Agile without being Scrum e.g. XP. In consequence your comment does not form an argument against anything.

All of the arguments above but one are fatally flawed, and do not hold water, and the remaining argument is one that reflects not upon Agile, but upon all programmers.

If you were to have argued based upon actual data showing that Agile is worse for certain defined outcomes than one or more other methodologies studied then you might have had more success. If you had argued that there is a better way than Agile, and named that way, then even without hard data a conversation could have been had. As it is your article comes off as lacking in critical thinking.

Agile as a methodological family was a term coined thirteen years ago. Methods that led to Agile have been around a lot longer. The fact that I'm having to explain what I would have hoped were simple and well-circulated concepts means that we have a lot more work to do in the IT industry to educate internally and externally about modern development methods, what they mean, what the benefits are and how to use them effectively. I finish with the hope that you and Dr. Dobbs can play a positive role in that programme.

Yours sincerely,

Nigel Runnels-Moss

Agile Environment Ltd.