I have been in the Computer Science / Information Technology / Management Information Systems profession a long time. There are times when I need to take a break from all of the noise going on in our profession and revisit words and thoughts from the people I consider my mentors. These are the people who helped me become a better programmer, a better thinker, and learn to question everything.
One of my favorite magazines that I have read since my early days in this profession is Dr. Dobbs Journal. Reading articles in this wonderful magazine from many of the thought leaders (e.g., Scott W. Ambler, Allen Holub, Bruce Eckel, Larry O’Brien, Dave Thomas, Andrew Koenig, etc.), who taught courses early on at various conventions I have attended during my actual computer language programming days (e.g., C, C++, Java), remind me of the principles and personal practices I have let slip or ignore with all of our new drag-n-drop GUI-related tools.
I came across this article from Andrew Binstock (photo right), who is the Editor in Chief of Dr. Dobbs Journal. Prior to joining Dr. Dobb’s Journal, Andrew Binstock worked as a technology analyst, as well as a columnist for SD Times, a reviewer for InfoWorld, and the editor of UNIX Review. Earlier, he was a senior manager at Price Waterhouse. He began his career in software development in the early 1980’s.
I have included Mr. Binstock’s recent editorial about his concerns about how we are corrupting Agile in it’s entirety below. In Parts 2 and 3 of this series, I will explore some interesting thoughts about the Agile Manifesto and an interesting technique developed by Dave Thomas to continuously improve our programming skills.
The Corruption of Agile
by Andrew Binstock, Editor in Chief, Dr. Dobbs Journal
What was intended as a set of personal practices has become a doctrine. And despite the mainstream adoption of Agile, the loss of its original intent has undermined its effectiveness.
Many people over the years have discussed their distress with the religious tone that cloaks the implementation of Agile practices. Particularly from the testing side of the world, there is a lot of “should,” “should not,” and “can do better next time” dialogue that sounds more like a man trying to fix ethical lapses than a developer writing code. When I speak with adherents of test-driven development (TDD) in particular, there is a seeming non-comprehension that truly excellent, reliable code was ever developed prior to the advent of this one practice. I sense their view that the long history of code that put man on the moon, ran phone switches, airline reservation systems, and electric grids was all the result of luck or unique talents, rather than the a function of careful discipline and development rigor.The disconnect between today’s Agile view and earlier reality is equally evident in the wanton bashing of the waterfall model. To get any programmer today to adopt your recommendation, simply state that not doing so is just a new way of doing waterfall. Watch his toes curl despite never having used waterfall, nor seemingly having any awareness that it served the industry really well for decades. What, was everyone in that bygone era a fool?Alan Kay was entirely right when he said that programming today has become a pop culture: “Pop culture is all about identity and feeling like you’re participating. It has nothing to do with cooperation, the past or the future — it’s living in the present. I think the same is true of most people who write code for money. They have no idea where [their culture came from] — and the Internet was done so well that most people think of it as a natural resource like the Pacific Ocean, rather than something that was man-made. When was the last time a technology with a scale like that was so error-free?”
It will pain some readers to know that the vast, error-free Internet predates Agile and even predates TDD. Crazy, right?
What I’m saying here is certainly not new. The fascination with today’s way of doing things and the view that it is the one true path to good code is a seemingly permanent part of the programming culture. But it has been greatly abetted by the legions of Agile consultants. By stressing the practices, they have corrupted what Agile was about. It’s important to remember that the Agile manifesto stated values, not practices. Immediately, though, values were translated into programming practices by consultants and, quickly, the former was lost. One of the original formulators of the manifesto, Dave Thomas, whom I interviewed this week, states his realization that a month after the manifesto was written it was already being corrupted: “…it got immediately productized in many different ways. The whole point, to my mind, of the Agile Manifesto is that it’s a set of personal practices that may scale to team level. You do not need a consultant to show you how to do that. It may help to have someone facilitate, but you do not need a consultant. And yet immediately what happened was that everyone and their dog hung out an Agile shingle and the whole thing turned into a branding exercise.”
What’s interesting in Thomas’s account is the view that Agile was a personal practice. Implicit is a personal way of orienting oneself towards a development process that accepts, even welcomes, change.
By pure coincidence, Allen Holub has been driving this point home in several blog posts, the most recent of which is a brilliant little piece that reminds us that Agile is a culture, not a set of practices. As he has previously explained, just because an organization is using scrum, doesn’t mean it’s Agile. He could have said the same thing about TDD, continuous integration, pair programming, or the like.
Whether a site is Agile or not depends on its culture. Does the culture support the personal values of the manifesto? If so, it’s Agile, if not, then it’s doing something else. So, indeed you could have a fully Agile site without TDD, continuous integration, or scrum. Likewise, you can have a site that uses all three practices, but cannot adapt to changes and is wholly inflexible in its work — so, not at all Agile. Yeah, I know, crazy, right?
Next: What the Agile Manifesto Really Said
Source: Andrew Binstock, The Corruption of Agile, Dr. Dobbs Journal, March 18, 2014, http://www.drdobbs.com/architecture-and-design/the-corruption-of-agile/240166698.