> I've worked under Agile and XP regimes and I hate both with a > passion. They were both a *huge* productivity drag (ever actually > tried "pair programming"?)
Yes. I've done agile and XP and even a little pair programming. And...I agree and I disagree. If you have a small project, something one person can do and you are content with the result being in only one person's head, agile and XP and the like are exactly what you say: a significant productivity lose. But if you need the result to be in more than one person's head, or if the project is such that one person can't handle it (too big, needs to be done too fast, whatever), pair programming is - well, can be - a substantial win overall. It impairs _individual_ productivity for the sake of _overall_ productivity. Agile and XP are less about programming productivity in isolation and more about customer interfacing - and therefore productivity in terms of producing happy customers (where "customer" should be interpreted liberally, not necessarily as "arm's-length entity that pays money"). If you're building something for yourself, if you're doing a well-defined and highly predictable "here's the task, go away and come back when it's done" job, they are of little to no use. But if you're building something where there's a nontrivial chance of the requirements changing mid-job, and the coders and the consumer are different, I find them to be of significant value - and that's a larger fraction of the coding jobs than one might wish. > It also seems to me that all the "greats" (incredible coders) No, if you're idolzing lone-wolf coders producing one-person projects on their own (or even very small teams, if they already know one another well), agile will be somewhere between irrelevant and obstructionist. > and software projects or companies I loved or respected weren't > "Agile". Possibly. I'd have to know which ones you have in mind to have any chance of saying anything of value - and probably not even then, as it's unlikely that whatever you have in mind is something I know anything about the internals of. I will hazard a guess that the projects/companies you're talking about were not producing code for a customer, but were producing something for themselves which, once produced, turned out to be appreciated. (Perhaps they did so expecting that result, perhaps not - the critical point is that there was no customer before/during coding.) There, too, because there is no customer during coding and thus no changing requirements during coding, and no customer to be kept happy during coding, agile and XP are irrelevant. If that's the only kind of coding you care about, or what to do, or whatever, yes, you should ignore them. A nontrivial fraction of the code I write falls into such categories. But there is also a nontrivial fraction of the code I write that _does_ have a separate customer, with changing requirements. While I don't formally do agile, what I do do is in line with many of the principles behind agile - things like "release early, release often", short iterations, and constant customer involvement. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
