Saturday, January 14, 2006
The Agile Religion and the need for Merciless Pragmatism
Does anyone else get the feeling that "Agile" is now a religion with its holy books, many patriarchs, its churches, and commandments? ("Thou shalt work in pairs"). It is just a set of useful practices, master them, adapt them, use what works, discard the rest and get on with life.
The moment 'agile' becomes some kind of religion with itinerant preachers of the Holy Word attempting to convert the unwashed heathen to the worship of the True God, its time to step back and take a hard look at what is being attempted. Kent Beck made a list of practices which he found useful. Later a whole bunch of marketing was thrown at it and we have the present situation where people speak of "true agile" , "distributed agile" "xp 2nd edition vs xp 1st edition" and so on.
Another factor often ignore is that most of the "agile" methodologies (to use the word loosely) have their origins in the world of enterprise programming where teams of programmers wrestle with coding up systems for banks, insurance companies etc. Thus there are a lot of assumptions built into the extreme programming and other agile methods which simply don't hold in other contexts.
As a simple example, think about "Customer" and "onsite customer" in the context of a massive open source effort like the Linux Kernel. These terms just don't make sense. Any efforts to twist the meaning of the word to mean "the community" etc just robs the word of any meaning.
There is an even deeper notion of the separation of "what to program" (the customer) from "how to program" (the coder).A "luminary" who spoke on Agile recently said "Programming is all about taking knowledge from others and converting it to code". (Really! I am NOT making this up!)
"Take knowledge from others". Bzzzt! Cluelessness Alert! This may be true in the practice of consulting/business app/enterprise programming etc today but not necessarily elsewhere (Kernel hacking, scientific programming, compilers, embdded programming etc)
I think this view of the programmer as some kind of "coding body" with the "domain knowledge" residing elsewhere is deeply embedded into many "schools" of "agile". More about this in another blog entry but this separation of "what" and "how" has many built in assumptions about the context in which programming occurs.
There are whole worlds of programming outside the "enterprise" world where the 'agile practices' apply very tenuously, if at all.
And even within the enterprise programming domain, agile /xp/ whatever-the-latest-buzzword should be constantly (re) evaluated, adapted and modified, not adopted and propogated mindlessly (I have been guilty of such behaviour in the past and use this blog post to unreservedly apologize to my victims).
If I want some kind of religious experience I can go to my nearest Descent-Of-The-Holy-Spirit-Scream-and-Yell-And-Speak-In-Tongues- Church. When I go to work I want logic, pragmatism and rationality.
I have adopted the "constantly growing test suite","refactoring" and "continous integration" ideas from XP to my work and jettsioned the rest. It is simply impossible to "pair program", do "test driven design" etc in the context in which I work.
TDD is, in retrospect, an insane approach to design. But more about that in another blog entry.
To conclude, the "agile" schools of programming do have many useful ideas. But "agile" is neither a scientific theory (like Relativity) nor some kind of Divine Revelation. They are just a list of practices which work(ed) for some people in some contexts. Beware of "Agile Consultants", "Agile Enablers", etc. Lock that chequebook away and do some focussed thinking and experimenting. Pragmatism trumps religious fervor any day.
Subscribe to:
Post Comments (Atom)
7 comments:
"pragmatism?" In an enterprise environment? As an (ex) consultant you should know that common sense and pragmatism are very scarce in most organisations and IT departments especially. For some reasons, such places react only to buzzwords. "Agile" is a buzzword for a set of common sense practices already used by most good developers, just as "POJO" is a buzzword for "just write good code instead of using over-complicated frameworks". It's sad that IT departments need the buzzwords instead of just doing the right thing.
Hi 'anonymous',
I believe we may be addressing two different (but maybe related) points.
I don't have a problem with people creating *names* for things. Thus it is convnient to use "extreme programming" (as an example) rather than say "we follow these 12 practice .. 1..2...12.We don't do up front design .. we don't .. we don't.." etc.
What I find strange is the almost religious fervor (some) people attach to such things. At this point what was created as convenient shorthand becomes something mystical and immune to rational analysis. A name for something becomes a buzzword when it is treated as something with magical properties and is used as a "Word of power" to confuse and obfuscate rather than reveal and enlighten.
Thus I have no problems with "agile". I do have a problem with agile (or any other) fanaticism.
Thank You for your thoughts.
"Take knowledge from others". Bzzzt! Cluelessness Alert! This may be true in the practice of consulting/business app/enterprise programming etc today but not necessarily elsewhere (Kernel hacking, scientific programming, compilers, embdded programming etc)
Enterprise programming is a huge portion of the market. Just to throw out a completely WAG, let's say 80% (based on perception of number of job postings, etc.) This is also something where complete knowledge of the domain is nearly impossible. Very few "power users" of these systems will ever know the entire domain either. Try to remember some of your nightmares for a little refresher of your leasing software days. This is not mathematics. Most companies have developed their own formulas over time. "Taking knowledge from others" is completely necessary in this environment. The core parts of many systems may be in a book somewhere, but the rest is only in peoples' heads. What rests only in someone's head will change! This is unlike your mathematical formulas.
The fanaticism for a lot of people comes after they experience a shift in productivity and happiness by applying the XP practices. Excitement ensues from finally "getting" what you've been hearing about until now. From this excitement, more people hear about it.
People take on only those practices that they are comfortable with. They may be ignoring the positive impact the different practices have on each other, but they're also avoiding roadblocks that they've never had to work through before.
Where fanaticism breaks down is in the uncritical nature of it. I agree that few people truly reflect on what they're doing and how they're doing it (even when they're "forced to sit through a retrospective" -- hey, there's one of those buzzwords). Though this is one of the core parts of XP (and should be anywhere, really), human nature wins out. People just don't want to change how they do things.
So, I pose the question: If someone says they're an XP fanatic, can they really be doing XP?
In my opinion, no. They're forgetting one big key: fix it if it's broken! http://www.extremeprogramming.org/rules/fixit.html
Nate,
I said "*may* be true of enterprise software ... but *not necessarily* elsewhere .. ".
Since I made no absolute statements about the "true nature" of programming (unlike the original speaker) I am not sure where we disagree.
Iow, *all* programming (imo) is not about situations where some coders (as distinct form "domain experts") know some "modern" technology like jsp/jdbc/ejb/.net and need someone else to "know the domain" and then have to "take" that knowledge in "iterations" and "convert to code".
These days (and this could change in the future) I do believe that unless you *understand* what you are coding up (this might be a small part of a large domain) you'll end up writing substandard (but possibly functional) programs.
And coding up a system (even with test-code-refactor cycles) is not always the most efficient way to acquire that understanding. As an example, to design a non trivial neural network system (not a toy example of "XOR separation"), you *have to* understand Linear Algebra and Calculus. No amount of "TDD" will give you insights into Integral Calculus.
Anotehr example is that of writing an *Optimizing* compiler. No amount of "java" or "object" knowledge or many repitions of "TDD" will give you the insight as to the design of the optimizations and the Intermediate Languages. The final system depends more on your insight and understanding than any agile methodology use.
Even in those faroff (thankfully) leasing systems, the best programmers were those who understood leasing best (better than the "normal" programmers anyway, even within an agile team).
The "ideal programmer" on such a project would be a "leasing expert" who is also a "coding expert". In the absence of this ideal programmer, you have to have various workarounds. Grungy "offshoring" makes it worse.
All this being said, an enterprise system can often be put together by programmers who know nothing of the domain (which is what happens in most "distributed agile" projects). The same programmers designing a correct optimizing compiler is impossible.
So it is not so much a question of the source of the information about a domain (books/formulas/businessrules/intuition) as about the level of understanding of the domain the coder requires (no mater how acquired) to code effectively.
Unlike in today's practice of (most) enterprise programming, in kernel coding or scientific coding it is impossible to know what to code unless you understand the domain well (OS theory and implementation experience or the underlying math).
Show me a kernel hacker or scientific programmer who says otherwise.
And that was my point.
"If someone says they're an XP fanatic, can they really be doing XP?"
This raises the question of what exactly *is* "real" XP? If any criticism of XP is countered by "oh that is not *real* XP" there is a circular logic in play very similair to any criticism of a religion being dealt with by "oh That is not the *real* religion".
"Real" Islam doesn't condone terrorism or misogyny or the killing of infidels. "Real" Islam does not condone polygamy. "Real" Christianity does not condemn non believers to burn in hellfire forever. "Real" Xp doesn't say that you must pair/refactor/write tests if that is not appropriate.
Nutshell: The value of any practice in software (xp or othewise) has validity *only within* a particular context. XP, and by extension "agile" methods have no intrinsic, absolute, context-free superiority.
All that being said, I hear you saying that "Where fanaticism breaks down is in the uncritical nature of it. I agree that few people truly reflect on what they're doing and how they're doing it"
That is precisely the point I was trying to make. I guess I should work at expresing myself more clearly!
Thanks for your comments. Quite thougt provoking.
Interesting ideas. I'm not so sure many people are really locked into rigid notions of what is "real" or "true" programming / agile / whatever. You may be reacting to a non-problem. Some further comments.
Dave,
you haven't met the people I have. I wrote this after listening to an agile "luminary" went on and on about "real" and "true" agile.
So yes there are *some* people who *are* locked into these distinctions. And whether these people "are a problem" or not depends on the context methinks.
YMMV.
And that is fine.
Also I am *not* "calling anything agile". re read my post maybe? :-)
...you haven't met the people I have.
I think we can safely agree on that point. Or can we? Hmm.
BTW, I cited some of your remarks in another post. I thought some of your observations about the importance of context were relevant to the topic.
Post a Comment