Burningbird

eXtreme Programming has all the markings of a cult. I'm not surprized that you're not signing up to join the collective. The "pragmatic" thinkers might be closer to your view. Great software is a function of… talent. If you can't hire for that key skill: pick a methodology. It helps the project managers create task lists and schedule meetings.

McD they're all cult-like. Agile programming camps have done for technology what Hallmark did for holidays.

Well i'm not one of the Agile groupies, but i do think the traditional project cycle (design,code,debug) is changing. Take notice, adapt of die, "eat alpha for lunch, and piss out betas by afternoon tea" is the way to go … we just did it, see ming and the afternoon is not yet here :)

Shelley, this is an awsome piece of insight - thanks. I was working with a superb team where each individual brought a diverse range of skills to the table. Now we are being physically separated - the team has been split in two, with one half being shoved on an Agile programming project. So now we lose the convenience of chatting over a problem with a neighbouring colleague - one who would jump in to help without hesitation.

We're being told things like "using wikis and whiteboards improve communication in projects", yet these people fail to notice splitting a team in two kills the face-to-face knowledge sharing that these items cannot shore up. Its been eating away at me for too long now.

Our lively, always supportive, web team is effectively dead. Killed by buzzwords like Agile and the identification of diversity as a problem rather than a strength.

Thanks for a timely piece.

Shelley, can you tell us what your experience with XP teams is? I must admit I reacted against your post, but as one of the converted I am wary of appearing too zealous, especially here. I can see that neglecting to use the diversity, for example, of the folks available might cause untold harm, but can you point to examples from your experience of where XP practices — properly carried out — have caused harm rather than good?

Curiously,

Chris.

Chris, I've never run anyone over in the street, or seen anybody run over, but I'm still able to deduce that doing so is ultimately not in the best interests of either the pedestrian or the driver. One doesn't always have to explicitly experience harm to see how something may not be healthy.

Other than turning down two jobs that demanded team programming and I said screw that, I haven't been involved with an eXtreme job. Which means, I guess, that's two jobs with one woman less.

I look at the money being made off of the concept, and I wonder how anything that supposedly is so natural to web development cost so much to learn.

I also compare the fact that since the beginning of the 1990's, when agile programming really started taking off, there has actually been a drop in women in the tech field. I don't necessarily know that these are connected, but I do know that agile programming takes nothing into account other than what works for a certain type of individual.

You might chat with Isofarro about direct harm.

On the other hand, I've been in several very successful projects where agile programming wasn't used, and one factor they had in common was the diversity of the participants. Does agile programming encourage diversity? Not from that picture at the Manifesto site. I would say, just the opposite. I know my first reaction on seeing the site was: where's the sheets? If anything, this to me shows that there agile programming favors guys. Why? Because only guys are involved with it.

What's the makeup of your team, Chris, and which of the 'beliefs' are you following? I say beliefs because you talk about being converted. It sounds like you're following eXtreme.

very very interesting.

there is nothing to fear as long as it looks, acts, reacts, thinks, and talks just like me.

but, don't think business won't be demanding some uteruses in that picture–how else will they create Asperger's babies who will be even MORE agile, less social, more productive, more cubicle-driven, and unneeding of a life outside of programming 24×7 in order to continually adapt to that all-exciting "change"?

it's the new industrial revolution, just trade in the automobile for pieces of code. put the women on the line too–it's good for the war effort.

Adding a European perspective, America is the land of the plug and play solution. If you've got a problem, be sure someone is there to sell you something. In the same way Extreme Programming and its advocates are intense and narrow, meeting this minority with an equally shrill response doesn't help, Mademoiselle. I don’t fully agree with either perspective, but both have something useful to contribute. Some consideration of the technical and social aspects of this difficulty and mutually agreeable ways of moving forward will, hopefully, emerge over time.

How we deal with things matters, and the structure and balance of Extreme Programming, and diverse and less systemised approaches, both have their place within the overall scheme of things. Pushing one in favour of another where consideration suggests they’re not the best fit for the problem or the people is to court failure in the long-term. I suppose, just to punch another button, it’s a matter of flexibility and will. It’s not that there aren’t challenges and solutions. It’s the choices we make and the degree to which we pursue them that determines outcome.

Structure and balance are important. It might not fit with some people, but setting tough rules and forcing compliance has its benefits, as does allowing broader horizons. In that respect, bringing up children is no different to managing a team, or setting public policy. There’s a place for conformancy as much as there’s a place for diversity. Neither is good or bad on their own. It’s a question of applying them to the right degree, in the right place, at the right time. For instance, too diverse and demanding a society breeds disorder and selfishness, while too high a degree of conformity and sensitivity breeds a closed society that’s scared of change.

Focus, sensitivity, order, and balance are important considerations. They have a direct and measurable impact on our mental health, economic success, and wellbeing. Also, they’re as important whether you’re an individual, corporation, or nation state. Learning about and developing them is a doorway through which you can better question who you are, what you, do, and where you should go. By doing so, you will know yourself and other people better, and how you all fit together within a bigger picture. Instead of seeing the world through the mantra of conformity or diversity, or being too driven or laid back, you will be more correct as the situation demands, thus, you will be more useful, productive, and a much better person to boot.

I've been on a number of (successful) teams, and I'm not sure that diversity in and if itself had much to do with our success. I think that the following factors worked for us.
We were able to do iterative development. Getting all of the parts working together, even if they're not feature complete is a great help. It's also good to get early feedback.
The parts were loosely coupled. That really helped with both reliability and the speed that we could make changes.
We took the time to hire good people, and to train them in the tools that we use. It often takes us months to find someone acceptable, and takes looking through a lot of resumes, and doing a lot of interviews, but it's worth it. (And if you're doing this right, you'll probably end up with a diverse team, anyway.)
We're in contact with our users, and try to help them. (I've known teams where this wasn't true.)
We don't have to fight the bureaucracy much.
We like each other.

Shelley, you sound like Matt Stephens, who co-authored the heretical work Extreme Programming Refactored: the Case Against XP.

In addition to more direct railings against XP, Stephens also had some fun back in the old pre-book days:
XP Society's Annual Picnic (don't miss the Star Trek event at the end)
Twin Valley Kingdom
Emperor's New Code (this one is by Doug Rosenberg, creator of the Iconix process)

Oh, and one of my favorite XP documents from C3—the original XP project—about the fun of having a fully-involved Customer representative: Will Extreme Programming kill your customer?

In the same way Extreme Programming and its advocates are intense and narrow, meeting this minority with an equally shrill response doesn’t help, Mademoiselle.

Not having been to Europe (I hear they have different words for stuff there), I am wondering if one's perception of "shrill" is geographical. I didn't find the above review of XP to be particularly shrill at all. I have no stake in XP pro or con so I may be too far removed to see the shrillness.

Just sayin'.

Oh my Doug, the picnic reminded me — at Intel we did start using some of these practices. We had the 10 minute stand up ever morning. I felt like a trained monkey: stand up for 10 minutes, get a muffin.

I have read some of Stephens stuff. He's got a point–there are some good things about all of the agile programming practices. I like shorter deliverables, more communication between team members. But I like requirements, data models, use cases. I like knowing what I'm creating BEFORE I create it.

I think agile can be salvaged. First thing that has to go, though, is the religious ferver. And I am very concerned about how much of this is focused at a specific type of individual. This could lead to even more isolation of women and minorities in tech.

Like Ethan, Charles, I don't think I was being shrill, but I guess our milage varies. Odd how often I get called 'shrill' when I'm critical, especially of tech.

Jeneane, we need war posters — We Need You for Tech! Women, do your part. Perhaps a eXtreme pInk programming paradigm.

Jeneane, we need war posters — We Need You for Tech! Women, do your part. Perhaps a eXtreme pInk programming paradigm.

How about this poster?

Not having been to Europe (I hear they have different words for stuff there), I am wondering if one’s perception of “shrill” is geographical. I didn’t find the above review of XP to be particularly shrill at all. I have no stake in XP pro or con so I may be too far removed to see the shrillness.

Looking at the differences in how the media covers certain stories and my own more direct experience, there are geographical differences. I’m not phased too much by the contrast and comparison of methodologies, but the topic tilted too far towards a them versus us mentality, technically and socially. It may be invisible to Americans, but it screams to me.

Getting too excited and partisan might help force an issue, but it produces a lower quality outcome in the long-term. If Shelley could put aside the technical differences between methodologies, and the feminist agenda, the foundation of a very illuminating article for everyone’s benefit would emerge and, I’m sure, be more persuasive.

I’ve read a few articles by Professor Alison Wolf, and exchanged a few emails about the role of men and women in society. Speaking generically, she has a fair grasp of the complexity and size of the issue but, I think, would find a more simple view of the order and balance of society useful. The strategic parallels with software development, methodologies, and the roles people fill is compelling. Ditto global warming. Presentation matters.

Like Ethan, Charles, I don’t think I was being shrill, but I guess our milage varies. Odd how often I get called ’shrill’ when I’m critical, especially of tech.

We have knowledge and skills in abundance, whether we’re talking about software development or some other field. These are commodities. What’s not given such a high profile, and one I think is important to people of all backgrounds, is character development or leadership. This is something that can be developed and self-developed, and may require some hard choices to pursue. Deliverables aside, the single most important thing is communication.

It hasn’t escaped my attention that this and previous comments fit into the scope of what we're talking about. Being technically right, and right, aren’t always the same thing. As Shelly picks up in her topic, what we do and how we relate to other people is key to success, and that’s something we’ve always got to remain open to improving, regardless of wherever we fit in the spectrum.

You can be shrill and partisan, but I’ll cut you some slack. I can be single-minded and long-winded. Sure, there’s a time and a place for everything, but bad habits like this as a default position need nuking. Not only does this extend our range and flexibility, which is a good strategic capacity to acquire, but it helps bring other parties more willingly and usefully into the game. Methods and teamwork shape us, as we shape them.

Thank you. That was very enlightening, and gives me an additional critical perspective. (My professional universe occasionally overlaps with programming.)

I'm most of the way through Soul of a New Machine, and your piece reminds me of it, and it has been reminding me of you, and these discussions of women & tech. The particular ethos of that time and that place has been generalized out to a whole profession. It can't possibly be healthy!

Shelly,

Many moons ago I wrote an essay on this topic
http://www.niwotridge.com/Essays/AAPrinciples.htm

The core problem here is there are foundamental "truths" in the agile manifesto that are applicable to many software development environments. As well there are many really boneheaded applications of these same principles.

I've worked with several clients undoing the mess created by the blind application of XP or its derivatives. The challange is how to manage a software project "in the presence of change." The traditionalist what to control change and the extermist what change to drive the project.

The principles of "agile" provide a good starting point, but we have a motto here in aerospace - "don't do stupid things are purpose." When applied to XP or other agile process, good results occur.

Shelley,
Wow.
I'm usually a big fan of your writing (it tends to be well written, clearly thought out and avoids being enthralled by superficial fads) but I think you're mistaken here. I can understand your point of view but quite a lot of it seems to be based on ignorance and misunderstanding. For instance: when I look at the list of the original signatories of the Agile Manifesto I see at least one dutch guy (Arie) and at least one English man (Martin Fowler). And I know Martin lives in Chicago. So it's not accurate to say that the manifesto came out of some kind of californian ideology. It is true that all of the original signatories were white males. But as a black male I tend to believe that something can be a good idea despite the gender and ethnicity of the originators.

I've successfully used Agile software development techniques over the last 5 years both before and during my time at ThoughtWorks. Moreover very little of that time has been spent developing public-facing web applications that are in 'beta'. Instead I've been working for investment banks, hedge funds, retailers and other companies run by the sort of people who don't do things because it's cool but because it has a measurable effect on profitability. In those kinds of corporate environments the early release of a polished application (even one with minimal functionality) with professional standards of documentation and support can have a significant impact on profitability.

I agree with you that the most vocal proponents of agile lack diversity but that's true of the software industry as a whole–the loudmouths all tend to look the same. This is largely because people who don't fit the stereotypical image of IT developers (for example Rachel Davies ) tend to be overlooked by outsiders whe are only interested in confirming their own prejudices. You've just done it yourself.

You've taken one look at the bunch of blokes who met at a ski lodge somewhere to come up with the agile manifesto and decided that they represented everybody who is promoting or using agile. If you take a look at something like the board of the Agile Alliance (the umbrella organisation that runs some of the agile conferences): http://www.agilealliance.org/aanpo/board you will see a surprising number of women there. Just because those of us who belong to various minorities are not launching websites emblazoned with our pictures doesn't mean we don't exist.

I'm not claiming that agile software development is a panacea. Like any tool there are places where it isn't suitable. But if you take the time to understand it by asking questions rather than making assumptions you might find that parts of it can be useful to you. Or you might find that it's of no use to you. But you would be in a position to reject it based on accurate information rather than supposition.

If you're interested feel free to ask questions of me, any of the agile mailing lists, or even groups like London's Extreme Tuesday Club using our wiki.

After reading this article I'm thinking XP is like the Scientology of the software industry. It's a bunch of nonsense that has gotten lots of people to pay for the privilege of embracing it as a way of life. I'm not familiar enough with the culture to have noticed how white-male it is, but this would support the comparison.

XP smelled funny to me from the moment I first heard of it. I'm always leery of methodology fads, and when I look at XP I see a lot of books and seminars being sold, and I don't see a lot of actual insight into the challenges of writing software. It's almost as if the creators of XP woke up one day and decided to see if they could put together a nonsense collection of recommendations, give it a stupid name, and pass it off as wisdom worth paying for. Hey, it worked for L. Ron Hubbard.

ade, your implication is that I must be wrong because look here at this board–there are women, there are blacks. Therefore my questioning of the bias of the approaches must be in error.

But I didn't go looking for that picture and then form a prejudice. I've long thought that many of the agile programming practices are based around an imbalance within technology. Rather than impose cultural controls, wouldn't a better approach be t fix the imbalance?

I think some of you have an impression I've had no previous experience with agile programming techniques. I knew about these well over a decade ago. At the very beginning, many seemed focused less at creating technology applications, and more on adjusting the culture and behavior of the group. Why I asked myself. After all, most other businesses and industries don't have an equivalent.

Ah but one thing that tech, specifically, and engineering as a whole does have, is a disturbing imbalance in the make up of the practitioners. Disturbing because as even the experts contend, it makes no sense for this to continue happening.

It does make sense, if you question everything about the field — including these approaches to 'fix' the field. In this case, agile programming. What are some of the approaches? Many have to do with communication–the pairs programming, the face to face, the bringing in the customers.

One difference between men and women is communication styles. No, I don't think men and women are hard wired to communicate differently. But I do think society encourages this difference.

What does Agile hope to change? The fact that techs sit in their cubes, heads down, uncommunicative except when absolutely necessary–never asking for help, never asking for a review of code. The customer is disregarded or disdained, the meetings consist of the same re-hash of the same facts, over and over again. Everyone has an opinion of how something should be done (not to mention a great deal of inflexibility in regards same). But no one wants to accept responsibility for making a decision, because they might be proven wrong.

Tell me something: would you consider this typically male or typically female behavior?

So in an agile department, people are encouraged to get up and talk, decisions are by consensus, competition is discouraged, while cooperation encouraged–programmers program in pairs, the customer is brought into the group and actually even told to lead it.

Tell me: does this sound like typically male or typically female behavior?

Even with this, how many times do women in the groups get pushed into the administrative tasks, while men do the decisions? In a pairs programming, with a man and a woman, who types more, and who dictates? Has the groups involved with this even looked at this as an issue? Or has the focus been on technique only?

I have a hypothesis: that agile programming arose because tech departments are imbalanced: consisting not only primarily of white males, but a specific type of white male. Yet this same imbalance is already now impacting on the agile programming techniques–a focus on tools, a rigid adherance to processes. The push away from written to verbal communication, I think, strongly reflects this. The only way you can change a culture, is by recognizing that there's something wrong with the culture.

As I said, I agree with many of the concepts, but I also feel many of them arose because there is something flawed about the industry. And to me what the flaw is, is pretty obvious just by looking around.

No, I didn't go looking for the photo and then form an opinion. I had an opinion–finding the photo was just serendipity.

But thanks for clarification on the geography of the people in the photo. Oh, and I appreciate that you've found the techniques helpful, and I'm glad you pointed out Rachel; but this doesn't alter my opinion.

I generally stay out of programming arguments, as I am now strictly an amateur, but I've seen my share of these arguments even way back when I was a professional programmer. These promotions of particular methodologies strike me as an ex post facto attempt to turn ONE team's successful method into a general case.

It reminds me of an old art critic who wrote that every good artist is absolutely convinced HIS way of doing art is the only valid approach, and all others are invalid. Of course this is sheer egotism. It's like saying everyone should paint like Picasso.

Shelly,

Your piece reads like the work of someone who has read a fair amount about a subject but has no direct practical experience with it.

>I’ve just spent a few minutes ‘trashing’ agile programming.

Think so? I disagree.

Most of the assertions you make about how things happen on agile projects, the dynamics of agile teams, and even the "beliefs" of agile practitioners, are simply nonsense. You're not trashing agile because you're not describing agile in the first place.

Sure, some proponents of agile methods get a bit carried away with enthusiasm, and I think healthy skepticism is a pragmatic reaction to that kind of exuberance. I've seen the same pattern too many times to count, over the years. RUP, CASE, BPM, and more recently SOA. All are good ideas and all have a proper place in our professional practice, but none has proven to be the panacea its proponents sang about. Now here we go again with this "agile" thing, whatever that means.

Healthy skepticism is wise. But what about unhealthy skepticism? How is dogmatic opposition any better than dogmatic support? Like any other methodology, process, or technology, agile methods work well in some situations and poorly in others. And like any other methodology, process, or technology, if agile methods are applied incorrectly, they will fail. When they are applied correctly to the right sort of problem, results are good. I've personally experienced all those outcomes on different projects.

I would expect strong critical thinking skills from members of our profession. I dare to hope for some measure of objectivity as well. Call me an optimist.

Many problems people blame on "agile" really boil down to incompetent management, don't they? The commenter, Isofarro, who wrote about his team being split up is a case in point. He blames "agile" for preventing, of all things, "face-to-face knowledge sharing" - a phrase one could use as a nutshell definition of agile exactly as written. Even from his brief comment it's clear enough the problem in that case lies with management, not with methodology or buzzwords.

And this business about the white men and so forth…surely you're not serious! A racist software development methodology? What next? Racist popcorn? Racist sunshine? Racist water?

If that was an April Fool's post, you got me. Congratulations!

You have some very good technical commentary about lacks in agile methods (over-reliance on casual conversations to formal requirements, lack of project management) - but after spending the last couple years in agile'esque environments I can tell you that with good client management, agile methods can delivery maximum value to a customer who doesn't really know exactly what it is they want to build (more common than anyone would like to admit).

But agile methods are an attempt to make a more casual, flexible, collaborative, "human" development process - you even note that they are more "feminine". Any methodology taken to extremes becomes dogma and replaces old blind spots for new ones, at it's worst agile methods guarantee an unsuccessful death march project - but you seem to have come to agile bearing a lot of baggage.

Your abhorrence of team programing for example is a blind spot. Programming is more like a skilled trade than a science - as such the techniques that worked for artisans for thousands of years (journeymen learning by working closely with a master craftsman) work quite well for both productivity and quality. Similarly, far from throwing away testing, agile methods insist on the creation of test code as a responsibility of the developer for the entire project. For this reason, integration testing if largely unneeded as it happens during each iteration. The use cases that are the requirements magically turn into the user acceptance tests that determine completion.

As for inclusivity - the last agile project team I managed was made up of Latino and European men and women located in the US, Brazil and Argentina, speaking at least 3 different native languages. The agile project before that was all Caucasian Californians in their mid 20s (though we did have a gay Latino customer subject matter expert).

The values of the company and the team members drive inclusivity and communication styles. Methodologies are just tools that are used by those team members.

Jonathan, I don't think I mentioned that testing is tossed out. I'm aware that tests are derived by the developers, usually before development. This has been used in other projects I've been involved with. In fact, many of the agile techniques have been used in various companies I've worked with, but not under this umbrella concept. Not suprising: I'm assuming the new methodology people have absorbed previous or parallel methodologies.

As for pairs programming… Not. A. Chance.

I do agree that it is the values of the company and team members that drive inclusivity and communication styles. So we have to ask ourselves, why are most high-tech companies in the States at least, so predominately male, and usual white male? Is it then that they don't want to be inclusive, and communicative? If so, then would agile methods change this? From what you've said, it doesn't sound like it.

I agree: I have put much baggage on agile programming in this post. But then, the agile proponents promise much. Mild promises would most likely only have generated mild commentary.

As for adding femininity, I imagine that we could hope that these methodologies would make an environment more welcoming to women. I think, though, that this would be demanding too much from the concept. Don't you?

Dave, other than that you've mastered the art of hypertext linking, what is your arugment here? That agile works when applied correctly, and if it doesn't work, it's the fault of the organization? Isn't there some logical fallacy associated with this reasoning?

You've chosen not to respond to individual items in this post. Is it then the case then that yout response is based on the fact that I'm critical? Or is that I've introduced the lack of diversity? I can't tell–all you've done is tell me and others that agile isn't something, it's something else, and when it fails, it's other's fault. Whatever that something is that fails.

As for agile programming providing an atmosphere where perhaps a more diverse work force would feel comfortable and welcome–I don't think you need worry on that.

Like feminism versus machismo, or narratology versus ludology, and all the rest of the manufactured silliness, I don't have much time for it. Life's too short. I thought I'd skip saying something redundant and scribble some haiku.

Extreme Programming
Look at the loonies multiply
What a bother.

Charles, I work in a field where I'm lucky if there is one other woman other than myself on any project. A problem that is blatantly denied by most practitioners in the field. I don't consider this an issue of manufactured silliness. But it is responses such as this that are more telling, and make my arguments far better than I can ever create.

I am still waiting for those who defend agile to refute my individual arguments. What I have received is some agreement, some thoughtful disagreement–and commentary.

But don't allow me to add to your sense of ennui.

Oh, and that wasn't shrill.

Asshole.

Now that, that was shrill.

Shelley,

You asked what experience I had of XP. The answer is very little. I am not a programmer by trade, I'm a research scientist working for a large company in the UK. (I did apply for, and was offered, a job in a startup company that used XP — which "process" was crucial to my decision to apply to them.) And you picked up my use of the word "convert". I lay this out to show that I like what XP teaches and offers.

My reason for responding to your post was mainly that you described something that didn't sound to me like my understanding of XP. I don't want to respond in detail to all the points you've made, but if you don't mind, I should like to pick out a few.

You talk about requirements as though by doing a very good job of gathering them you can get them exactly right. Experience (not mine, but plenty of other programmers' and writers') seems to indicate that it is virtually impossible to get good requirements that never change throughout the first development of a program/product. XP's response is to notice that the customer is better able to look at a working — if limited — program and say "not like that, more like this". In order to be able to support that sort of approach XP expects its programmers to keep their code clean enough that they can accommodate changes to the requirements as they go. It's not machismo, it's simply a response to difficulties that customers have in accurately formulating their own requirements. And it's not an adequate response to say "Do the requirements better then." People who embrace XP have been programming professionally as long as you have, I'm sure, and have seen the same trends come and go as you have. They honestly believe this is better than trying endlessly to perfect the requirements.

Timeboxing, likewise, is a response to difficulties with estimation. I'm a lousy estimator. Most programmers are lousy estimators. (Two approaches to estimation: (1) triple every estimate; (2) double it and use the next size time unit, i.e. one week really means two months. These both testify to the lousiness of the average programmer's estimation skills.) Timeboxing limits the effects of bad estimation, and provides a framework for learning to do it better.

You disparage the preference for face-to-face communication over remote communication. Agile methods don't prefer face-to-face communication on a mere whim. It is better. You have to resort to worse methods when you can't get all your developers and the customer into the same room. If you can't do that then your communication will suffer. What's to argue about? But if you can make use of face-to-face communication, then XP talks about how to make best use of it.

Finally, I don't understand why working software is not better than documents, testing, use cases, requirements, etc. They are all there to help the programmers produce the working software, aren't they? I really don't understand your point here.

When reading your post, I feel very strongly that its principal motivation seems to be fear. I may be wrong, and if you assure me that I am I will gladly accept it. I asked whether you had any experience of agile methods because fear quite often arises from lack of knowledge. I hope that I'm right in this case because I love reading almost everything you write. I didn't at first — you're an acquired taste! But this post seemed to be written by a person so different from the one I had come to know that I had to comment.

On the contrary, Shelley. I'm very engaged with this discussion, just not engaged with unecessary bias. Also, I thought a little humour might help lighten everyone's load and encourage reflection. Your last comments, I think, prove this necessary.

Carry on.

Chris, you've misread a lot of what I wrote. I didn't say that all one needs is requirements. I said that I don't agree with doing away with the requirements gathering process — all the modular programming in the world won't help if you don't have at least a decent understanding of your task before you begin.

And changes in requirements late in the process do cost. I've never seen this not be true. To encourage such is, in my opinion, just so much smoke and mirrors.

We may have to incorporate change, but it shouldn't be treated as a goodness. Late change can impact on the stability of an application at some future time. No amount of decent coding or abstraction will add stability to late changes. Not unless the changes are to do with the UI rather than the infrastructure. Late changes in UI usually are no big thing.

I've worked over 20 years in the industry. I have dealt with a variety of customers–from workers in a door factory, to the Saudi Arabian Air Force. You may not be able to capture requirements perfectly, but someone astute, and who listens, can do a damn good job.

As for clean code–what does this have to do with agile programming? Is it that there's an assumption that non-agile programmers are putting out crap? You write clean code, because all apps have to be maintained. Because you take pride in your work. You write modular code, because we're all basically lazy and don't want to have to recode the same functionality over again. You use the proper level of abstraction because most architectures demand this, and because it makes it easier to work as a team. All of which may make it easier to add late changes — especially if you isolate the user interface. But make no mistake: late changes cost.

I don't disparage fact-to-face communication. But I think it has its place. And in today's geographically distributed development environment, if the only way a person can team with someone is looking into their baby browns, then I would say that person is going to have problems adapting.

I agree that we need to discourage the programmer who goes off to do their thing with little communication to the other members. But communication does take different forms. And when someone communicates a requirement to me, I want it in writing. I want to be able to re-read the requirement later to make sure I understand what's needed from me. Sometimes I'm tired, and I don't remember what's told me correctly.

Now, discussing a design issue or decision could be face to face, or voice to voice. Asking questions is good. But you know, hasn't weblogging shown that an amazing amount of communication can occur with just text?

Communication is a measure of willingness to listen to what others say as much as the medium in which it's said. Several agile supporters have expressed in this post that I didn't understand what agile is. I ask them then, tell me. Especially given my opinion that the reason for many of the agile programming methodologies is because the tech industry is imbalanced. I may not be right, but who is to say I'm wrong? If the only response I get is I must not understand it, with the implication that I wouldn't be so critical if I did–this doesn't communicate where I'm wrong about agile programming.

If they can't communicate specifically where I'm off the mark (and many have–I don't want to seems as if I'm disparaging yours and others remarks) in writing, what makes them think they can in person? Other than one can use face-to-face communication to get others to back down when disagreement arises. Face to face is an effective intimidation technique, too.

Face to face can provide a lot of visual cues — but an effective writer can convey the necessary information in writing. Books come to mind.

Agile encourages a cheap way out of a task most programmers hate–writing.

As for timeboxing, I have nothing against short deliverables. Most of my work has been based on monthly deliverables. This isn't unique to agile–this is effective project planning and making sure a work load is evenly distributed. But a rigid adherence to a specific timebox–always 4 weeks–you'll burn many of your developers out over time. People are not clocks.

As for the comment on judging based on software working, the point I was attempting to make is that you can judge a project by the documentation, the test cases, the modeling and so on–it's not _just_ the software that tells us we're progressing.

And the note on fear and lack of knowledge–I never directly write about anything I fear in my weblog. No offense, I don't know any of you well enough to do so.

I wrote on agile programming because someone asked me for more on why I don't care for eXtreme programming. I answered.

Now, if an assignment I take on requires that I follow any agile programming methodology, other than pairs programming, I will do so. Because I am a professional–and a professional adapts to the environment of their client. But I doubt I'll be attending any agile conference, and posting little stickies up in the columns of my weblog.

As for the writing on this post, this is no different than how I write on most of my posts. Even the ones on deer in the park. I'm not always truthful, but I am always honest.

Thanks much for coming back in with a more detailed response. I really did appreciate your taking the time. I hope my responses provided some clarification back.

Yes, Charles, and I also introduced humor. Couldn't you tell?

Since you asked people to refute your arguments I have written this. I don't see it as a refutation per se since a lot of your points are perfectly valid. However I did want to point some of the inaccuracies and fallacious thinking.

Firstly you claim that incremental releases necessarily means the delivery of beta quality software. That's not the way people who consider themselves agile see it. Instead it's about providing the people who pay the bills with maximum visibility into the state of the project and the ability to adjust the direction of the project at any point. I've been on projects where we gathered all the requirements up front, minimised interaction with the customers from then on and at the end they told us that their business domain had shifted radically enough that the software was already obsolete before it was put into production. By delivering complete and working software in small chunks we give the project's sponsors a chance to do things like cancelling the project if the software we're delivering doesn't match their expectatations. This hopefully avoids the classic pitfall of large government projects where they don't get cancelled until after they've spent very large sums of money.

You claim that "agile programming pushes a four-week release cycle." That's not in the manifesto (which by the way is a broad outline that a bunch of people from a variety of methodological backgrounds were able to agree upon) or even the principles. Even there they only go as far as saying that software should be released on a cycle "from a couple of weeks to a couple of months." The idea is that the release cycle should be chosen in a way that is helpful for your project and your organisation. By fixing the release cycle (which may be the time between internal or external releases of the software) it becomes possible to measure things like a project's velocity and to estimate it's projected end-date. This lets project managers track a project that slips on a day to day basis rather than being suprised when the delivery date is missed. I've worked on agile projects that have had weekly internal release cycles as well as projects that had an annual external release cycle. As such I would consider this claim to be inaccurate.

You claim that it's a bad thing for requirements to change during the lifetime of a project. With regard to the development team requirements churn is a bad thing. But how does the rest of the organisation feel about it? If I'm a project's sponsor I need to know that I'm not committed to an inflexible project that will refuse to adapt to the changing business environment. As such organisations with development teams that understand the business value of adapting to change rather than resisting it often find that it's a competitive advantage. So for those organisations being able to change requirements is a good thing.

You claim "there are two [cynical] reasons for wanting your customers with you daily." Unfortunately you assume that the business domain is simple enough and static enough that you actually can document all the required knowledge. You also assume that the people paying for a project don't actually want to be involved in it. The goal of having a business representative (which may actually be a business analyst in some organisations) who regularly interacts with the team is twofold. Firstly it provides the business with insight into and control over the project. The second reason is to provide the team with easy access to someone who can both clarify the requirements and who has the authority to make decisions about requirements. Without that easy access: multiple meetings have to be convened; multiple emails have to be exchanged and long phone conferences have to be arranged every time a decision needs to be made. Having someone on-site is often far more efficient.

You also seem to imply that the only way to understand agile is to attend conferences or training sessions. Actually "agile" is little more than a brand name for what used to be called light-weight methodologies (e.g Extreme Programming, Feature Driven Development, Lean Software Development, the Crystal family of methodologies, DSDM, Scrum, etc). These all grew out of the working practices of various people that can trace their roots back as far as Royce's original (sadly misunderstood) work on Waterfall, Fred Brooks's Chief Programmer Teams, Barry Boehm's work on the Spiral Model, Lean Manufacturing and Tom Gilb's work on software metrics. Consequently most of the practitioners learned these methods by working with other people, talking to other people, modifying these methodologies themselves and reading books/experience reports by other practitioners. Unless you have an exceptionally good public library system you will have to pay for the books. But the rest you can do for free. If you're genuinely interested in software methodologies then you can lurk on mailing lists frequented by people who are actually using these techniques rather than trying to promote them, you can use CiteSeer to read PDFs published by people who have experienced these projects, you can read the pages on the C2 wiki, or the wikis of any number of local groups of agile practitioners. You could also take a look at AgilePlanet.

I appreciate your visceral objection to pair-programming but you should know that only one of the many methodologies under the agile banner actually advocates that practice. People often confuse XP and Agile then use the inapplicability of XP in their environment as an excuse to reject all the agile techniques. Instead if you find XP unappealing you should take a look at the other methodologies as you might find that they have useful techniques that you can adopt. I also find it illuminating that you think of 'pairs programming' as involving one person dictating whilst the other is reduced to a mere typist. That's never happened in any pair programming session that I've been involved in or seen. It's possible that you've seen a more representative sample of pair programming than I have but it's more likely that you've misunderstood the purpose and the correct application of the pair programming technique. Take a look at http://www.pairprogramming.com/ or Dr. Laurie Williams's research on the topic to get a clearer picture. Whilst I'm not competely convinced about the metrics she's gathered (since a lot of her subjects were students) I do find that her publications do examine the social interactions inherent in pair programming.

With regard to the issue of diversity: Robert Scoble does not represent me or any one else within the 'agile movement.' Using him and his ilk as a strawman is unfair and muddies the water. It is true that the software development world is at the same time more diverse than most people acknowledge but still less diverse than the mainstream of most societies. However it's rather harsh to criticise a methodology (which is really nothing but a set of techniques bound together by some value system) for not fixing the societal problems that have led to the monocultural tendencies of the IT industry.

You claim that "most of the developers work with people just like themselves. There is no diversity." Well I must be in that minority who never works with people like himself. In my relatively short career I've worked with people from all 7 inhabited continents (yes that includes someone who lived in Antartica for a year). I've worked with people of just about every conceivable size, shape, gender, ethnicity, background, orientation so when you say that "there is no diversity" I wonder if you're talking about all of IT or just your particular part of it?

The one consistent theme running through this article is a re-definition of agile. You make a set of incorrect assertions about agile, impute motivations to people who are just trying to deliver working software to paying customers, build up this towering edifice that enforces "a particular work style, as well as reward a specific set of behaviors" and then reject it. If the many different methodologies within the agile movement really promoted the things you claim then I would never work for any company that used them. Neither would most of the people I know.

Finally I would recommend that you take a look at the following books: Agile software development by Alistair Cockburn and Agile management for software engineering by David Anderson. They both attempt to give a balanced overview of the complete set of agile methodologies.

I appreciate the point by point ade. And the additional links to other material. I still think there is miscommunication.

I appreciate that it would take considerable amount of time to become aware of all the nuances of all the different agile methodologies. I responded only to the Manifesto, and primarily to XP; not particularly fair to other approaches, other than the bits that have appeared over the years in my jobs. And I don't have the time to do the job thoroughly, so must just agree: I don't understand the agile programming methodologies. It's either keep up with J2EE and RDF or the methodologies–I will have to bow out of the methodologies.

Definately wrong on the release cycle; I had read 4 week when looking through some of the material online, but not sure where. But what you're saying does make much more sense.

I can agree with the customer being involved. But I know of very few companies I worked at that could afford to have a domain expert assigned fulltime to the project. Seems to me, this is extreme. And I bet a lot of agile projects have easy access to a domain expert, but they're not 'assigned' to the team, fulltime. I can't help thinking that this is an approach that could be directly responsible for not having a more formal requirements process in the beginning.

As for pairs programming, I'm sorry, but the links you provide on pairs programming, how is this different than what I described? Other than we'll assume for the sake of argument that gender would never influence the interaction between the two.

"TwO programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software."

Oh, no. No way. Not on your life. I may, and do, make mistakes in my code, but I am willing to accept responsibility for same and fix. This approach strikes me as a way of neither programmer taking personal responsibility for their work.

Or necessarily feeling ownership of a piece of the puzzle. This isn't a 'bad' thing. This is coming home from work feeling good because you figured something out, on your own. Is there room for this at all in agile programming?

Seems to me that the individual is lost in agile programming. The individual was too much of an influence at one time, but this seems to be the opposite side of the extreme range. People need to accept responsibility. People need to be accountable. People need to have a personal sense of accomplishment.

As for the diversity, ade, please don't ignore the fact that the number of women in IT in the US has now dropped to less than 20% in college, and only 25% professinally. There are less of us now than a decade ago. There are more black programmers, but not equal to the percentages of black population in the country. As for Hispanics in the US — no, the percentages are less. Only the asians have kept up–and ever surpassed white guys as percentage of populace.

If this was across the board in all professions, I would say there's a problem across the board. But women at least have increased their numbers in all of the, what were traditionally male fields–but engineering and tech. And with tech, it makes no sense. Technology is a part of all our lives. It can't be healthy to have this disparity.

Feel free to disagree with me that agile programming is a symptom of a deeper more cultural problem; it is only an opinion; but please don't disregard that lack of diversity is a very real problems.

I do want to say, I apologize for all those who practice agile programming in their day to day lives. My intention was not meant to impune the practioners: just the practice, the zealots, and those who have found this to be marketing gold.

Thanks for your patience for providing such detailed answers. I did misunderstand aspects of agile programming, and I appreciate the clarification.

PS My apologies for also introducing Scoble. There must be a new weblogging law–when you introduce Scoble into the discussion, the discussion is over.

Ah, Wikipedia had the 4 week thing in the section on agile programming.

Every end is a new beginning.

It’s easy to acquire hurts in life, which distorts perspective and sets us up to spin the wheel of misery in someone else’s life, whether it’s a bad coding decision or lack of customer engagement. Any system which encourages people to develop better quality of action and relationships is no bad thing, and no matter how good the system the weak spot is always going to be people.

I’ve spent most of my life innovating and fighting the system, and jealousy and wounded pride in others always kept hitting me in the face. In many respects, this isn’t unlike your own position, Shelley. When push comes to shove, people won’t change unless they have to. You can try forcing it, but in the long-term it’s counter productive and a waste of time and resources.

The system we work within is important. Order is necessary for things to work. However, without balance the individual components run the risk of being too powerful or weak, to the detriment of themselves, others, and the system as a whole. A default aggressive or passive position is no good. However, positive and constructive engagement, or love and learning, are useful.

This is why I practice Daoism, Buddhism, and martial arts.

"So we have to ask ourselves, why are most high-tech companies in the States at least, so predominately male, and usual white male?"

Is this still true among young people? It seems like the cliche has been, for at least 10 or 15 years, that white Americans refuse to become computer programmers. Among my friends, it's simply something to laugh about, in a self-deprecating way. There was one party where it was especially vivid, the day after New Years, I can't recall if was the beginning of 2004 or 2003. The group was a bunch of well to do late 20s or early 30s professionals. We went round the room, and the degree to which we conformed to stereotype was laughable. Not counting me, all the white Americans were either in med school or just out of law school and all the kids of Indian or Taiwanese descent were in tech. We joked about it, and we briefly discussed why white Americans refused to become programmers, but we had no conclusions. One woman (who was white and a lawyer) mentioned the way television glamorized the life of high-powered lawyers, but we could not answer the question of why that allure might only appeal to whites.

The idea of programming being dominated by white people is surely ending? I've read that in America's universities, advanced degree programs in computer science are only about 20% white, at this point.

The predominance of males in the field seems to be a continuing reality. The number of women recieving advanced degrees in computer science peaked in 1989 and has since been in decline. But I think the days when people think of tech as white-dominated must surely be coming to an end.

It is true that IT suffers greatly from lack of diversity. The appearance of formalised agile methods is only a small fraction of the evidence which "validates" this.

We can't be sure of the extent to which the authors of the agile manifesto understand how homogeneity contributes to the problems agile seeks to address. Likewise for all the agile zealots out there.

But I experience agile as a part of the solution to the homogeneity problem.

Formally valuing and practising collaboration, customer focus, sustainable pace, simplicity etc. over lone-wolf, gold-plated, 24×7 hero-programming takes the traditional white male machismo right out of enterprise software development.

Increasingly (although admittedly still on a relatively small scale) I see this making IT more accessible, interesting and even appealing to a broader range of people. This is probably an accidental side effect of agile, but it does get us a few steps closer to reversing the mess we are in as an industry. We still have a long way to go.

Formally valuing and practising collaboration, customer focus, sustainable pace, simplicity etc. over lone-wolf, gold-plated, 24×7 hero-programming takes the traditional X right out of enterprise software development.

You had me at the X. Now why did you need to go and bind X = "white male machismo". I mean i've personally seen an Indian woman, a black person, and a fat antisocial white girl, exibit these same trits. When are you "guys" gonna stop seeing pinkos behind every tree. Laying the ills of IT at foot of male machismo makes as much sense as blaming the ills of the pre war Germany on the Jews. Warning … Stop it! … Stop it now! … before it rots your brains!

"We can’t be sure of the extent to which the authors of the agile manifesto understand how homogeneity contributes to the problems agile seeks to address."

For good-hearted people who mean well, the hardest thing in the world is for them to realize they are themselves the problem. I saw this all the time when I was active in the environmental movement.

I recall endless, agonizing meetings where the blacks and the women and the men loyal to feminist ideals would point out the extent to which an all white, male, middle class leadership limited the diversity of perspectives that were brought to bear on issues.

The answer, always, was for some of the (white male) leadership to fire themselves and let someone else lead. And when someone said this to them, their initial response was "But I truly want to help, and if there is anything wrong with my leadership, then I truly want to change myself and grow as a person. Please tell me what I'm doing wrong and I swear to god I will fix it. I am listening to you with all of my heart, and I will heed what you say." And of course, there was nothing in particular they were doing wrong, they simply lacked the perspective of someone who had grown up in utterly different surroundings. As an example, they lacked insights to offer to the mostly minority groups that were struggling with inner-city pollution. And when that was said, the person in the leadership role would say "But that's not fair. That's not anything I can fix. I can't go back and have a different childhood. And I truly want to contribute something to this movement. You can't tell me I'm not allowed to contribute just because I'm a white male from a middle/upper class background." To which someone would always ask "Why do you have to contribute from a leadership position? Why can't you volunteer your time after you resign your leadership position? We want your energy, your creativity, your brilliance, your passion, we just don't want you in a leadership role."

And it always took awhile for this to sink in, the extent to which the leader in question was conflating leadership with contributing. For some, once they lost their leadership positions they no longer saw any reason to volunteer their time. Others, most I think, came round to seeing how much their ego played into their volunteerist impulses, and they changed a great deal. Which is to say, they experienced real growth as leaders, once they gave up their leadership positions.

The same emotions and reasoning seem to underlie the agility manifesto. Rather than simply let someone else lead, they are saying "We really want to listen! We really want to change! We really mean well!"

But they really, really, really want to lead.

Lawrence, i found your remarks very interesting and food for thought. I was involved with a group back in the 70's where there were no "leaders". People were in a perdicament where things needed to get done, and people just stepped forward and did them; and the group was goverened by consensus. Icrediable as it may seem, it worked. I don't think it matters who is in the leadership positions … rather it is the traditional role, leader, which is at fault. But then when it comes to mission critical tasks, do we not need that leader role? Can just jettison leaders in all cases.

Actually, Seth, there is no such thing as a leaderless group. Many of the social movements of the 60s and 70s aspired to be "leaderless groups" yet they were not actually leaderless. Where leadership is explicitly forbidden then leadership tends to emerge on an informal and ad-hoc basis But it does emerge.

No one said it better than Jo Freeman, in her classic 1971 essay The Tyranny of Structurelessness" (she's speaking mostly of the women's liberation movement, but her words apply to any so-called leaderless group):

"The idea of “structurelessness,” however, has moved from a healthy counter to those tendencies to becoming a goddess in its own right. The idea is as little examined as the term is much used, but it has become an intrinsic and unquestioned part of women’s liberation ideology. For the early development of the movement this did not much matter. It early defined its main goal, and its main method, as consciousness-raising, and the “structureless rap group” was an excellent means to this end. The looseness and informality of it encouraged participation in discussion, and its often supportive atmosphere elicited personal insight. If nothing more concrete than personal insight ever resulted from these groups, that did not much matter, because their purpose did not really extend beyond this.

The basic problems didn’t appear until individual rap groups exhausted the virtues of consciousness-raising and decided they wanted to do something more specific. At this point they usually floundered because most groups were unwilling to change their structure when they changed their tasks. Women had thoroughly accepted the idea of “structurelessness” without realizing the limitations of its uses. People would try to use the “structureless” group and the informal conference for purposes for which they were unsuitable out of a blind belief that no other means could possibly be anything but oppressive…..

This means that to strive for a structureless group is as useful, and as deceptive, as to aim at an “objective” news story, “value-free” social science, or a “free” economy. A “laissez faire” group is about as realistic as a “laissez faire” society; the idea becomes a smokescreen for the strong or the lucky to establish unquestioned hegemony over others. This hegemony can so easily be established because the idea of “structurelessness” does not prevent the formation of informal structures, only formal ones. Similarly “laissez faire” philosophy did not prevent the economically powerful from establishing control over wages, prices, and distribution of goods; it only prevented the government from doing so. Thus structurelessness becomes a way of masking power, and within the women’s movement it is usually most strongly advocated by those who are the most powerful (whether they are conscious of their power or not). As long as the structure of the group is informal, the rules of how decisions are made are known only to a few and awareness of power is limited to those who know the rules. Those who do not know the rules and are not chosen for initiation must remain in confusion, or suffer from paranoid delusions that something is happening of which they are not quite aware."

George Orwell says similar things about the anarchists of Barcelona, whom he fought with during the Spanish Civil War, the experience of which he wrote about in his very good book, Homage to Catalonia.

Lawrence, I believe I have read that a higher percent of asians are following the computer field than whites, but this country is still white majority, so this counters this effect. I believe–could be wrong.

World wise, I have no doubts that asians are the dominant force in tech today.

Cyndi: "But I experience agile as a part of the solution to the homogeneity problem."

Just from looking at the people at all the agile sites, I see much truth in this Cyndi. I've seen more women associated with tech in this venue than I have in many others.

My concern, though, is that without addressing the underlying cultural issues, eventually the major paradigm controlling the environment will alter these methodologies until they reach a level where the controllers have re-found their comfort level. And the inroads that agile has made to make this environment more friendly to women will be for naught.

I know that agile is not synonymous with eXtreme Programming, but we can see this effect in this particular approach. This is a very rigid methodology, which takes no account of personality differences. That, to me, is the old way of IT.

Thanks, much for your comment. More on this in a post later this week.

As for clean code–what does this have to do with agile programming? Is it that there’s an assumption that non-agile programmers are putting out crap? You write clean code, because all apps have to be maintained. Because you take pride in your work. You write modular code, because we’re all basically lazy and don’t want to have to recode the same functionality over again. You use the proper level of abstraction because most architectures demand this, and because it makes it easier to work as a team. All of which may make it easier to add late changes — especially if you isolate the user interface. But make no mistake: late changes cost.

I've had a few go-arounds with the TDD/agile camps in different blogs about this. They always put forth the idea that you CAN'T write good code UNLESS you do EXACTLY what they say, write unit tests first that fail, then write code that makes them fail, then write code that makes them not fail. I look at 20 years worth of code, most of which is far more important to the end user (I'm thinking astronauts and fighter pilots here) than the typical enterprise application and none of which were produced using TDD/agile methodlolgies, and thinking, "It is too possible to write good code without doing all that. In fact, it's how a lot of good code was written."

Scobles law == Godwins law for the 21st century?

This conversation becomes more and more interesting, thanks for starting it Shelley.

"Because the two programmers periodically switch roles, they work together as equals to develop software.”

Oh, no. No way. Not on your life. I may, and do, make mistakes in my code, but I am willing to accept responsibility for same and fix. This approach strikes me as a way of neither programmer taking personal responsibility for their work.

I haven't actually done any formal pairs programming. But I have worked in very close, very small (2-3 person) teams with shared (i.e. no clearcut) responsibility for libraries, etc. In those instances, I've found that "ownership" is impossible to trace. A group coversation about system architecture ends up with some drawings on a white board that I might copy down. Then I spend 2 days implementing what I need and stubbing out the read. Later some stubs are fleshed out by someone else and I might check my stuff in prematurely so I can look over a teammates shoulder while she integrates some additions she made to some of my stuff. Later in a low-energy mood, I might spend a couple hours refactoring and cleaning up bounds checking code.

Assuming that we're in close communication the whole time ("Hey Reg!, is there a reason you returned this as a DWORD instead of a ULONG?"), it is flat out impossible to figure out who "owns" what after very few cycles.

SHARED ownership of resources (assuming everyone is working towards the same goal), means that EVERYONE is responsible for it, not NO ONE.

Your resistance to the pairs programming could be of the ego-driven "It's MY CODE" variety that many would characterize as a masculine trait or it could be the experienced verteran who has gotten stuck cleaning up other peoples' crap one too many times (my guess), but you have to admit that in some idealistic perfect team world NEITHER would be a problem?

Shelly,

You note that I didn't respond point by point to the specific issues you raised about agile development. That is true. The reason is simply that there is no argument to make. Your understanding of agile principles and methods is simply incorrect.

Rather than pausing even for a split second to consider the possibility, however remote, that you misunderstand agile methods, you seem to demand that I explain it all to you, or else admit that I have "no argument." The plain truth is there is plenty of information on the subject available already. All the concerns you have expressed about the viability of XP or, by extension, other agile methods are addressed elsewhere.

Many people already use those methods successfully and have delivered quantifiable business value to customers, including me. If you want to convince me that all the successful project I've worked on weren't successful after all, then I invite you to convince my customers of that, and they will then explain it to me. OTOH, I would be the last to say that agile methods can apply to any and all software development projects.

I'm not an "advocate" or "defender" of agile methods any more than I'm an "advocate" or "defender" of screwdrivers or hammers. Methodologies are simply tools like any other tools. If you don't understand what sort of job a tool is for, or you don't understand how to use a tool properly, then whose problem is that?

I don't claim that every problem is merely a management problem. I cited a specific example, the situation that Isofarro described in his comment. That sounds like a management problem to me. Apparently, a team that was functioning perfectly well was ripped apart arbitrarily in the middle of a project. Surely you don't see that as a "methodlogy" problem?

Jonathan, it's purely of the school that I couldn't stand being in that close a proximity with another person, day in, day out. I never minded sharing a cube or that sort of thing, but I could put on my music and 'get away' for a bit. And I love to program. I enjoy a challenge, I love tinkering.

Pairs programming doesn't seem to accoumt for differences in personality or preferences in work style, or anything of that nature. It's very rigid and unflexible, and I can tell you that's not feminine. Being able to pop over a cube and ask something is one thing; getting good feedback on one's code is also another thing. But sitting with a person, day in, day out. No.

I love what one person wrote in another space: I picked my wife, and I love her. But I wouldn't want to sit next to her day in and day out. What makes you think I want to do so with someone I hardly know, or don't care much for?

I like what another person wrote: agile programming is very noisy. It works well for the talkers, but less so for the quiet folks.

And I have to ask: what's wrong with having some ego? With wanting to create something? With wanting to have a piece all your own and watch it form out of nothing? Are all these 'old fashioned'?

Dave, I have no doubt that the agile approach does work, and has worked for you. I just don't think it's for everyone, or every project. I still think that much of it does have to do with the fact that computing is inherently unbalanced. But this is just my opinion.

Shelly,

Thanks for bringing the discussion back around to a factual level. I agree completely that agile methods are not for every problem or for every person. I'm not a believer in magic bullets. IMO there are objective ways to judge whether the agile approach applies to a particular problem or not.

A bit of clarification about pairing. Pairing was invented long before the agile movement officially got its start in 2001. Today, it's usually associated with XP because it is one of the 12 XP practices. But XP is not the only agile development methodology. There are plenty of agile projects that don't use pairing.

The key factor IMO is the relative emphasis on people over formal processes. That leaves a great deal of flexibility for different specific methodologies. The points you raise about having a healthy ego and wanting to be creative and proud of your work are all consistent with agile methods generally, even if pairing doesn't work for you personally.

Apart from that, the way pairing actually works when it is done right is that you switch pairs throughout the day, so you wouldn't be "married" to someone all the time. Time is also set aside for individual work and for personal activities. It's really the diametric opposite of "rigid."

Regarding diversity, there are multiple dimensions to consider. Racial diversity in the IT profession in the US is a larger issue than "agile," so I don't think it is specific to the agile movement.

Gender diversity isn't what the thread seems to imply. The IT profession has a higher proportion of women than other professions, although still not equal to the proportion in the general population. Among those of us involved in agile work, the proportion of women is still higher than in the profession as a whole. So I'm not quite sure where the perception is coming from that women are underrepresented in the agile movement. Many of our thought leaders are women.

If anything, agile projects benefit from diversity because a team that has different ways of perceiving problems and conceptualizing solutions has more capability to create innovative solutions. Since agile methods depend on the people to drive success rather than on following a process (with the traditional implication that the process can guide "anyone" to success), it seems obvious to me that a diverse team will be better able to deliver than a monolithic team.

I would agree about pairs if you were to actually build 2-man cubicles with only one workstation - like most of the agile stuff, I take those things as guidelines that should be understood and repurposed as best fits your environment, project and team.

As for egos in programming - I understand and as a programming there have been some brilliant hunks of code that I was solely responsible. But as a manager, people wanting to be solely responsible for any piece of a project make me nervous as hell because of the "hit by a bus principle".

Looking back over the long term, it's the teams I worked with and the overall project accomplishments that I remember, not any particular hunks of code (but almost of my development years were in larger teams, while you've done some substantial solo projects like your WordPress extensions/enhancements making a different perspective (and it's just as likely to be a matter of middle-aged forgetfulness since I have done serious coding in a long time).

Dave, big correction: The IT Industry does NOT have a higher proportion of women than other professions. In fact, it has one of the worst for white collar work. Women make up less than 25% of all IT workers in this country.

In college, women have been gaining parity in all disciplines except two: engineering and technology (computer sciences). In these two fields, women are underrepresented by a significant amount. Usually making up less than 20% of the class, as compared to almost 40% in most other 'hard' science (math et al), over 50% in the 'soft' natural sciences (biology et al), and over 50% in most legal, liberal art, and social sciences.

>Women make up less than 25% of all IT workers in this country.

I apologize for my error. I did not realize the proportion of women in IT had fallen that far since the 1980s. I've found a pretty good gender mix on the projects I've been involved with in recent years. It seems a lot of women go into management rather than staying technical; don't know why.

Thinking about Scott's comment about people who

>put forth the idea that you CAN’T write good code UNLESS you do EXACTLY what they say

it occurs to me this says nothing about whether TDD is a good practice, but only indicates the person is overly dogmatic. IMO it's wise to be skeptical about people who are overly dogmatic.

I don't think it's correct to say you must do TDD in exactly a certain way. TDD is still an evolving practice. The original idea was just to be sure and test anything that might fail. It's nothing new to say that the sooner you can catch defects the lower the cost of fixing them. Eventually that evolved into the idea of writing unit tests first. Then it became apparent that incremental refactoring, done right after you get the green bar, would help reduce design debt and keep the defect curve flat throughout a project, avoiding the common "death march" phenomenon that occurs to often in the last couple of months before a release. Now there's a lot of effort to extend the idea to the functional test level, and some experimentation with the notion of "behavior driven development." Automated acceptance tests written before the code is written could serve as "executable specifications," at least in theory. This could be a big plus, since it could potentially reduce the opportunity for miscommunication between analysts and developers. We've tried that at our company on a couple of projects, with mixed results and nothing solid enough to offer as a "best practice."

I would think we're all interested in improving the state of our art, but there's no need to be dogmatic about this sort of thing. It's ironic that people who have good ideas to share can turn others off by being dogmatic. What good can come of their good ideas then?

The "we elected Bush" wisecrack thoroughly ruins an otherwise good post. Having finished lecturing us on diversity, you might want to give a thought to political diversity as well. Not all software developers take your views on the President as self-evident.