Extreme Programming vs. Interaction Design

I am interested in learning more about extreme programming, but haven’t been able to read in detail or practice any part of it so far – I will get back to that sometime soon. Interaction design – that’s a term which I came across for the first time and at the outset it sounds like a fuzzy concept to me. Following are some of my thoughts (quotes from article are in Italics):-

• I think the deepest tacit assumption is that we have a significant organizational problem, but we can't fix the organization. I believe that in order to create quality software, you have to change the organization.
• It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it. Neither the people who buy software nor the people who use it have the capability of visualizing something as complex as the behavior of software. They also don't have the ability to analyze what appropriate behavior is.
I started my career with software development which is transferring a written piece of requirements into design and code. It will only add to the quality of the software if you know the requirements first hand from the person who is going to use it – it will give a whole different perspective to the development of product. To someone transforming requirements document to code, idea of defining how your customer/user should be doing business and build software for that is paradigm shift. It requires a cultural change to go to a mode where we understand what user actually wants or rather needs and suggest it back to him.

• I believe that defining the behavior of software-based products and services is incredibly difficult. It has to be done from the point of view of understanding and visualizing the behavior of complex systems, not the construction of complex systems.
• The way the industry works right now is the initial cut at a solution is generally made from the point of view of a feature list that comes from the marketing people or the in-house customer, then given to the developers, who then synthesize a solution. It's not a construction problem; it's really a problem of design—not interface design, but behavior design.
• Usually, the architect at the sketch level will know enough not to design something that's an engineering problem.
• I think it's wrong when phases are abused, namely when phases have arbitrary boundaries and when there's no recourse and the people who are participating in the various phases are not working together.
There is an argument that there is logical side to software development which is essentially programmer’s domain and there is a human side where we understand users and business and there has to be a bridge of Interaction Designer who could define the behavior of the system and then translate it to Developers. Compared to this I tend to agree more with XP’s argument that software development shouldn’t be composed of phases and appropriate social structure is not a hierarchical one, but a network structure. I think it is not possible for every developer or designer or architect to be involved in the requirement definition to gain insight into the actual use of the product - but it need not be a segregated job function. It must be coming down to job profiles and competencies. Best programmers or architects may not be best communicators and hence may not have the tact to elicit the requirements from the customers. But there may be people who excel in this area but do not understand or have little interest in workings of software as such. To have the capability to define the requirements/product behavior/organizational complexity and architect the solution and understand the technical feasibility at the same time is the right combination at this stage. Building design is taken as example – I may have flights of fantasy when it comes to building my house, but some may not be possible to do technically or there may be better ways to do it – it is architect’s job to suggest a cost-effective, structurally good design. Interaction design is trying to alleviate this split/phase of design and development by suggesting that interaction designer links up with developer during the development phase. But in my experience that may not be enough. Breaking down the hierarchical structures of management, customer/user, technical architect, developer and having them interact and having open bi-directional channels of communication will definitely help.

From my understanding so far there has to be a better way to manage change in software development and by incremental cycles of development and better involvement of customers/stakeholders in the process of development it is possible to achieve much better quality. I guess the challenge is to do this without introducing more chaos and to institutionalize the practices to have more predictability.