Let’s not let this religion do what the catholic religion did and stop scientific advancement for 200 years.
On the other hand, there are a lot of benefits in (some) religions. And since software development is far more of an art than a science, religion is often the only thing we got!
Should we throw all of it out because of a few nuts?
Also, I clarified the wording on point 2 since there were objections, and I wasn’t clear on what I meant:
religion is the substitution of the rational by the supernatural. the last major one was the Dark Ages. there have been lots of mini medieval periods in Western society since the Enlightenment; the birth of eschatology (early 19th century) is among my faves.
since systems development is thought by most, even practioners, to be mostly magic; well can religion be far behind?
WaterBreath’s missive was far too insightful for just message boarding; my goodness.
Evangelism is just the catchterm for marketing/propoganda.
I disagree. Or at least, that’s not how I’ve been using the term…
Marketing is a necessary evil with capitalism. And it can be done honestly, by people who both truly understand and believe in what they are advocating for.
Propaganda is intentionally misdirective, even deceptive. It’s intentionally divisive, creating good guys (“us”) and bad guys (“them”), obscuring the middle, and trumping up false dilemmas. But it is done with a purpose in mind that need not necessarily be about power or greed. (Consider pro-Nazi propaganda vs. anti-Nazi propaganda during WWII.)
But when I call something a “religion”, it is because it not only includes aspects of both marketing and propaganda, but it supercedes them. And yes, I am intentionally connoting all the negative aspects of religion, disregarding for a moment that they not all be qualities of a “real” religion. By these I mean rules from on high, mindless obeisance, inexplicable rituals, a refusal to even address opposing viewpoints other than to decry them.
A “methodology” becomes a religion when sales people are pitching it as an instant cure for your business ails (salvation). And when consultants are promoting themselves as the only safe doorway by which you can enter the world of that methodology (clergy). And when conferences are arranged that disseminate all the success stories without addressing real problems people have run into (healing and worship services). And when my coworkers start “witnessing” to me about how I should be doing X and Y on every project, without considering that every project is different, and maybe X works but Y doesn’t this time (born-agains).
That last paragraph does not represent Agile as originally conceived nor, I’m sure, as its founders continue to promote it. But it does represent a whole lot of other people in and around the industry. People that should stop and think about what they are trying to achieve, and decide if a given aspect of a given approach is feasible and applicable. Rather than just taking on blind faith that some practice is universally beneficial.
I think the big disconnect here is that you have a relatively broad statement (dare I say vision statement) of beliefs (e.g. the agile manifesto) and some well defined practices (e.g. pair programming, aggressive refactoring, etc.) which are both referred to by the same name. Some people disagree with the manifesto itself, either totally or in part. Others agree with the tenets of the manifesto, but don’t see how the well defined practices associated with them achieve the manifesto’s goals. And still others agree wholeheartedly with the manifesto and do as many of the “best practices” as are suggested by leaders of the movement.
I think one of Steve’s points was that the lumping of practice+belief is a dangerous thing, and I would tend to agree. I’m more inclined to agree with the manifesto, but that’s because it’s broad and general enough to allow many different actual behaviors/practices/processes underneath it. I think the marrying of the agile manifesto and mandatory agile practices is that they contradict the first line of the manifesto itself: Individuals and interactions over processes and tools – and it’s this combination of practice+belief which gets alot of people bent out of shape (on both sides).
Ultimately, there’s only one simple guideline: Do What Works. Whether that means agile, Agile, scrum, RUP, foo, bar, or even gasp waterfall, the point is at the end of the day, we’re writing software and anything that gets in the way of that is bad news no matter what it’s called, or where it came from. You would be foolish to ignore the lessons of previous (and other people’s experience) but at the same time be foolish to assume that the context of their experience is the same as yours. Perhaps it’s fitting that we developers like to framework our processes as much as our software, but that’s another discussion for another time…
Jeff Atwood wrote “On the other hand, there are a lot of benefits in (some) religions.”
Is there some reason to think those benefits could not have been gained without the religion? Do the benefits outweigh the costs?
Jeff Atwood wrote “And since software development is far more of an art than a science, religion is often the only thing we got!”
Software development is neither science nor art - we might sensibly ask whether it’s engineering or craft.
Framing this as a discussion of religion is needlessly emotive - we’re talking about dogma.
We can do better than dogma. We can instrument our development processes, and continually re-evaluate what we do based on knowledge rather than supposition.
It’s interesting to watch some of the “leaders” (in the sense that they went first) of movements change over time. One gets the feeling that they find something they like and evangalize it until they find something better. In that way, software development doesn’t look like religion. Kent Beck wrote about XP. XP went off the deep end and he thought about TDD separately. Dave Astels started with TDD and has moved into BDD. The thought leaders(as it were) aren’t settling for finding a niche and propogating at the top of their lungs, that’s for all the people that come along 5 years later and take a few truths and ideas and run them up the flagpole as righteous dogma. Like Jeff, don’t settle for waterfall when there’s something better out there. Don’t settle for Agile (whatever that means) if you can get Google. Don’t settle for Google if you can move forward.
At least each of these things are promoting some good practices with the bad. For example, some customers are becoming more aware of the crap that’s been pushed off before and finally want to take responsibility for defining acceptance tests. Fantastic. This is a dream of mine: verifiable, black-and-white requirements. Sure it’s painful now, but we’re making progress…I think. Let’s improve this until we can actually get to where we really want to be. Whether bullpens, stand-ups, cards or whatever get us there, I’m easy.
Don’t forget the tools that come along with these movements. My IDE writes out method stubs for me now! It will move stuff around so it reads better and make sure I don’t screw it up! If religious zealotry will get me an IDE that helps me go faster and smarterer, sign me up.
My Definition of Agile (capital A) is pretty much Scrum + XP + TDD. agile (lowercase a) is lightweight among other things. I think Steve is responding to the Agile (captial A) people saying “Do Scrum + XP + TDD or you suck and your projects will fail” and yet there are clearly 1000s of projects that appear to be doing just fine without Scrum or XP or TDD.
I think it was Noel Llopis (http://www.gamesfromwithin.com) who has been promoting Agile (capital A) like crazy and yet admits compared to their non-Agile project their measured progress is 40% slower than it was with non-Agile.
He seems to believe that there’s still a net win down the road because of more confidence in the codebase through TDD, better design through both TDD and XP as well as less chance of major problems if a programmer quits since XP means more than one programmer is familiar with each piece of code.
If they are 40% slower though it’s certainly not guarenteed it’s going to be win for them in the end. They are taking it on faith and there in lies the bad side of “religion”. That the believers will convince people to do things that don’t actually help and actually waste time.
I’m not saying who is right or wrong. XP sounds interesting to me having never done it. My gut feeling is, at least for great programmers it couldn’t possibly be faster but if given the chance I’d love to try it.
TDD sounds great too, especially for libraries with lots of users. At the same time having shipped 18 commerical projects without TDD and having never had more than 4-8 weeks of bug fixes I’m not convinced the extra effort of TDD would have actually saved time in the end, at least for the specific projects I worked on.
So, again, it comes back to religion. If there was some proof that Scrum, XP and TDD worked it would be great but all we have are anecdotes, feeling and beliefs and no proof.
I like Tim Lister’s comparison of learning software development methods to learning how to swim at the olympic competitor level.
If you just throw someone into the water who has never swam before, they will either drown or dog-paddle. They will struggle to keep their whole head above water, and their legs will be far from the surface. But teach someone to swim well, and they will learn how to do the counter-intuitive things: keeping your head and legs near the surface of the water, “sipping” the air at regular intervals, and so on.
A lot of programmers think they just “naturally” know how to develop software, but they’re really just dog-paddling. After I learned and practiced “counterintuitive” Agile practices like pair programming, time-boxes, and test-driven development, I found that those practices did indeed help me get software done (from feature requests to shipping shrink-wrapped boxes, not just “coding”) faster and with higher quality.
I don’t consider the butterfly stroke to be religious, nor do I consider practices currently labeled as “agile” to be religious, unless you count religion as being something that helps you have a productive and enjoyable life, which I suppose many people do.
nor do I consider practices currently labeled as “agile” to be religious
Most of us, I think, are not saying that “agile” is religious. What we are saying is that many people are “religious” about “Agile” (note the capitalization), sometimes fanatically so. And that these people are doing neither the movement, nor the rest of the community, any favors.
An excerpt from the upcoming book, “The Bastard’s Guide To XP”:
The three main principles of Bastard Agile were first formulated by George Orwell in his novel ‘1984’.
WAR IS PEACE
Your mission as an Agile Bastard is to ensure that the iteration cycle is quick enough that no-one else ever gets their grubby little hands on the part of the product you broke. Therefore, keep iteration cycles short, in order to maintain enough fear and panic among your colleagues so that no-one dares question your “wisdom”. It worked for Adolf Hitler and George W. Bush, and it can work for YOU too! See Chapter 4, “Tactical Refactoring: I Didn’t Break It”, for some valuable tips to make iterations traumatic enough so you never lose control.
FREEDOM IS SLAVERY
Bastard Agile requires the illusion of progress. Therefore, you must ensure that your methodology is omnipresent in the daily lives of your victims. See Chapter 3, “A Full Inbox Is A Happy Inbox”, and Chapter 5, “Public Humiliation Is Your Best Entertainment Value”, for tips on using the reams of data produced by nightly builds and unit testing suites to keep your co-workers demoralized and submissive.
IGNORANCE IS STRENGTH
Test Driven Development is supposed to help ferret out bugs early on, so it’s in your best interest to learn techniques to hide your code’s flaws. Chapter 6, “Obfuscating Tautologies”, will help you learn to use language features to produce “tests” that do the most important thing of all – make you look good!
In order for programmers to be effective, they have to believe in what they’re doing.
This is the best sentence I have ever read in your blog.
There was a point lurking in my (admittedly) silly post – Agile methodologies in the hands of the incompetent and/or malicious can do a lot of damage.
I do not reject Agile out of hand; I have found adopting certain Agile techniques has made me a better programmer. Test-driven development and the “always keep it working” mindset help me, personally, produce code that converges quickly to the desired level of functionality.
Unfortunately, what works for the individual can be harmful in an organization. It worries me that Agile proponents do not see the potential for abuse, because it happens fairly often in the real world.
Great posts.
The one thing I haven’t seen you address is the question of why we even care. Why argue over which methods work best? I work in a DBUF company developing solutions with my own brand of Agile. I get away with it because the business area writes my check, not the IT area. Frankly, I hope the BDUF guys never change. They’re the reason business loves me. They can complain all they want but the results speak for themselves.
I think the actual number of people “religious about Agile” is smaller than the number of people who are “religiously Anti-Agile”.
We hear from the Anti-Agile people about how many “Agile Zealots” there are, but their numbers are overstated.
Most of the people that the Anti-Agile label as zealots are reasonable people just saying that Agile works for them… not being religious and not being “superstitious”.
The people who have tried Agile have tried multiple development methods, but the Anti-Agile generally have not.
Everything can be overhyped (think of Java, for example, or “Object Oriented”, the hype comes a few corporations, not from a lot of individuals.
Fairly twisted and uninitiated understanding of religion…
Agile is similar to religion in that once you’ve had a personal experience of it that unwinds your skepticism, you don’t really bother looking for objective proofs of what you have become aware of through experience.
Like religion, agile practitioners constantly and rigorously test the basis of their beliefs against new experience and new learning.
That said agile is no more a superstition than religion is. Although to the uninitiated - closed heart and closed mind - religion can appear to be superstition.
Dalai Lama constantly reminds us to keep testing the teachings against experience and to receive dogma as something to be proven out through rigorous experimentation and experience. He talks about “subjective proof” as a central experience of contemplative life. Christianity calls Christians to the same, as does Islam, and a host of other contemplative traditions.
It’s the fundamentalistic spinoffs of contemplative traditions that bring down the crap and lead to resistance to rational and experiential investigation - both of actual religion and actual agile development.
Self-imposed ignorance in response to fundamentalism is just more fundamentalism.
"From that perspective, the “scientific method” of Software Engineering, at least as it is practiced at the coal-face of development, is as follows:
– http://fishbowl.pastiche.org/2004/01/13/the_art_of_programming
Actually, after 28 years of programming, I’d have to say that religion (at least some religion) is a lot more objective than is programming!
Of course the religions that can’t explain themselves with proof I’ve found to be false. Whereas in programming, there really are many ways to the same end. For my part, after studying theology full-time for 3 years (and still doing a little programming on the side;-), I was disappointed with most religions. For my part, I’ve found Catholicism to be the only one out of about 10 I’ve extensively studied that can answer all the claims and counterarguments. The reader will strongly diAsagree, of course, because the world has taught you a false version of this religion. Of course Judiasm in its time, as well.
On the other hand, if you can program it, you can probably get it done with a PC, a Mac, in java, and a lotta times on a Basic Stamp (ok maybe that’s going too far).
Truly being able to say I’ve viewed all religions with the same skepticism I view any new magic bullet programming paradigm, I do not find this type of logical closed-endedness among the majority of the variety of religions, even some of the ones with many adherants.
Dev isn’t a religion. It’s better!
We just finished a 4-year project with a 800 data entry screens and 400+ possible form pages of output. I’d be hard pressed to say we used any methodology, but just because most of the users, testers and developers actually cared, and most knew what they were doing, it succeeded. So if you want success, get good people
Something dev does, then, have in common with religion for sure - a dev method or religion after gets praised or blasted not on its legitimacy, but on the care of the people who adhere to it. Sometimes you’re working with a Gregor Mendel, other times, a Judas.
I think at the end of the day a programmer needs to produce code to do his/her job. Whether or not they go to church is another thing altogether, but I do think you need to have some sort of process/methodology to produce better code. Part of the process/methodology could include code reviews, peer reviews, small cycles of work, etc. If you have no methodology and have a bunch of programmers go off and produce something 6 months later, chances are, your project will fail. Agile and Waterfall are 2 methodologies that can be implemented and I am sure they have produced both good and bad results. I am also sure that in the coming years there will be other highly touted methodologies as well.
David wrote-
“And no methodology is going to make the large number of mediocre programmers great.”
This is true, but no methodology turns mediocre programmers into a bunch sloppy hacks, and I have seen the unholy works that they have manifested. Methodology helps makes mediocre programmers better. Not everyone is a superstar, and if there is a bell curve for progammers, I bet the masses could probably use some sort of methodolgy.
Faith based on eg. experience is good, if there is no other scientific proof. Anyway, if there were scientific proof, then that would be just better. It is clear, that if you write self explaining code, it is easier to maintain than complex and mysterious looking code. This easier maintenancy can be measured scientifically with these two kinds of codes being maintained. And, of course, also pure intelligence can reason, that self explaining code is easier to read - hence easier to maintain, too.
Now, people trust things more, if they get some arguments for the things. Programmers may use some methods just because the methods are fun and cool. But professional programmers usually search for methods, that have good arguments for being better methods than some other ones.
I would not like agility or xp just because people believe in them. What is agility for one, may not be agility to an other. Of course you may be very “productive”, if you can roam the code free and agile and do things here and there as you wish. But that is not good as such. We need agility, but we need also something that engineering needs. If we want to build agile software, we may not achieve it with plain agile programming, but we need also plans, coherency, blueprints, architecture, and so on.