Agile Engineering vs. Interaction Design: Pissing money away and leaving scar tissue

I was never super into Alan Cooper (of Inmates are Running the Asylum fame) until I read this hilarious argument with Kent Beck, the godfather of Agile programming. ... it's pretty depressing that this doesn't exist anywhere except for the zombieweb.)

Here's a couple of the best bits.

Oh, and it's all about Agile programming and Interaction Design. If you don't care about such things then this is all really boring probably.

It might be boring regardless.

When an architect begins to define a building, he or she works very closely with the people who are buying the building to understand what the requirements are, and translate those requirements into a sketch of a solution. Then there's a lot of give-and-take between the occupants of the building and the architect in coming up with a viable solution. Usually, the architect at the sketch level will know enough not to design something that's an engineering problem. And if the architect does detect that there might be problems, he or she will consult with an engineer to make sure that he or she is not painting himself into a corner, technically speaking. At a certain point, the architect and the customer are going to achieve common ground. At that point, the architect turns those sketches into detailed drawings. Now, during the detailed-drawing phase, there's a lot more intense interaction between the architect and the engineer. The architect, you know, draws a span and calls in the engineer and says, how big a girder do I need to support this span? And there's a lot of detailed interaction between the two. This is precisely what happens in the world of good interaction design.
I think XP has some really deep, deep tacit assumptions going on, and I think the deepest tacit assumption is that we have a significant organizational problem, but we can't fix the organization. Essentially, the crap rolls downhill and ends up rolling right into the programmer's lap. When the product or the program turns out to be unsatisfactory, the fingers point to the programmer. XP is very well-intentioned; it's the software-development community beginning to say, "Hey, this is not only unfair to us, but it's not productive as a discipline and we can do a lot better."
"I applaud that sentiment and I agree with that sentiment, but then XP says, "OK, so, I can't change the organizational failings, so, I'm going to build my own internal defenses." I suppose this is probably better than nothing, but I'm interested in changing the way organizations are constructed. I believe that in order to create quality software, you have to change the organization. We can change the organization, and it strikes me that the assumption underlying XP is that the organization's structure is a given."
Building software isn't like slapping a shack together; it's more like building a 50-story office building or a giant dam. Beck: I think it's nothing like those. If you build a skyscraper 50 stories high, you can't decide at that point, oh, we need another 50 stories and go jack it all up and put in a bigger foundation. Cooper: That's precisely my point. Beck: But in the software world, that's daily business. Cooper: That's pissing money away and leaving scar tissue.