A difficult aspect of software programming is that it is always changing. This is no doubt true in other fields, also, but there is no tenure system in software development. Whereas in academe, it is quite plausible to reach a certain point in your discipline and then kick the ladder out behind you, as Richard Rorty was at one point accused of doing, this isn’t so in technology. In technology, it is the young who set the pace, and the old who must keep up.
The rapid changes in technology, with which the weary developer must constantly attempt to stay current, can be broken down into two types: there are advances in tools and advances in methodologies. While there is always a certain amount of fashion determining which tools get used — for instance which is the better language, VB.Net or C#? –, for the most part development tools are judged based upon their effectiveness. This is not necessarily true concerning the methodologies of software development. Which is odd since one would suppose that the whole point of a method is that it is a way of guaranteeing certain results — use method A, and B (fame, fortune, happiness) will follow.
There is even something of a backlash against methodism (or, more specifically, certain kinds of methodism) being led, interestingly enough, by tool builders. For instance, Rocky Lhotka, the creator of the CSLA framework says:
I am a strong believer in responsibility-driven, behavioral, CRC OO design – and that is very compatible with the concepts of Agile. So how can I believe so firmly in organic OO design, and yet find Agile/XP/SCRUM to be so…wrong…?
I think it is because the idea of taking a set of practices developed by very high-functioning people, and cramming them into a Methodology (notice the capital M!), virtually guarantees mediocrity. That, and some of the Agile practices really are just plain silly in many contexts.
Joel Spolsky, the early Microsoft Excel Product Manager and software entrepreneur, has also entered the fray a few times. Most recently, an blog post by Steve Yegge (a developer at Google) set the technology community on fire:
Up until maybe a year ago, I had a pretty one-dimensional view of so-called “Agile” programming, namely that it’s an idiotic fad-diet of a marketing scam making the rounds as yet another technological virus implanting itself in naive programmers who’ve never read “No Silver Bullet”, the kinds of programmers who buy extended warranties and self-help books and believe their bosses genuinely care about them as people, the kinds of programmers who attend conferences to make friends and who don’t know how to avoid eye contact with leaflet-waving fanatics in airports and who believe writing shit on index cards will suddenly make software development easier.
You know. Chumps.
The general tenor of these skeptical treatments is that Extreme Programming (and its umbrella methodology, Agile) is at best a put-on, and at worst a bit of a cult. What is lacking in these analyses, however, is an explication of why programming methodologies like Extreme Programming are so appealing. Software development is a complex endeavor, and its practitioners are always left with a sense that they are being left behind. Each tool that comes along in order to make development easier always ends up making it actually more difficult and error prone (though also more powerful). The general trend of software devlopment has consistently been not less complexity, but greater complexity. This leads to an indemic sense of insecurity among developers, as well as a sense that standing still is tantamount to falling behind. Developers are, of course, generally well compensated for this burden (unlike, for instance, untenured academics who suffer from the same constraints) so there is no sense in feeling sorry for them, but it should be clear, given this, why there is so much appeal in the notion that there is a secret method which, if they follow it correctly, will grant them admission into the kingdom and relieve them of their anxieties and doubts.
One of the strangest aspects of these methodologies is the notion that methods need evangelists, yet this is what proponents of these concepts self-consciously call themselves. There are Extreme Programming evangelists, SCRUM evangelists, Rational evangelists, and so on who write books and tour the country giving multimedia presentations, for a price, about why you should be using their methodology and how it will transform you and your software projects.
So are software methodologies the secular equivalent of evangelical revival meetings? It would depend, I suppose, on whether the purpose of these methodologies is to make money or to save souls. Let us hope it is the former, and that lots of people are simply making lots of money by advocating the use of these methodologies.