The architect Christopher Alexander describes a time not so long ago when people knew how to design and build spaces for themselves, uniquely fitted to their own needs and to their climate and culture. Growing up I heard stories of my carpenter great-grandfather. Whenever his family moved to a new town, he would immediately begin doing odd jobs and saving money. When he had enough, he would buy lumber and build a house. My great-grandfather wasn't trained as an architect, but he knew how to design a house that would suit his family.

Alexander notes that an architect's selfish interests are not aligned with the client's. The architect wants to get the job done quickly and win awards, but is missing critical information: how the client wants to live. Alexander's dream was to return the power of designing space to the people whose lives were most affected by it.

Alexander collected architectural patterns as a means to this end, encoding good solutions to the problems known to recur in designing and building homes. The patterns were never intended as an end in themselves, but as a means of balancing power between professional designers and those who live and work in the space being designed.

Alexander's vision still included a role for architects. Every project has unique problems as well as tediously predictable ones. The key to designing space that is alive is joining the deep understanding of individual preferences and social relationships held by the users of the space with the deep technical understanding of the architect. Bringing these two perspectives together in harmony, with neither dominating the other, enables the design and construction of a space that meets human needs and keeps the rain out too.

As I began to work in software development, I found the same imbalance of power that Alexander fought in architecture. I grew up in Silicon Valley, where engineering was king. “We'll give you what you need even if you don't know you need it,” was the often-explicit motto. Software written this way tends to be long on technical virtuosity and short on utility.

With more experience I began to see the opposite imbalance, where business concerns dominated development. Deadlines and scope set only for business reasons do not maintain the integrity of the team. The concerns of users and sponsors are important, but the needs of the developers are also valid. All three need to inform each other.

My bias in writing XP originally was towards the programmers. That's my background. That's who I identified with on teams. However, the past five years have taught me that software development can't be “the programmers and a bunch of other people” if the goal is excellence. Without balance between the concerns of everyone involved, some people will be unable to contribute to development, and their views are important to the team's success. My goal is now to help teams routinely bring technical and business concerns into harmony.

Harmony and balance are the aims of XP. Writing tests is a good thing in itself, but it is only preparation for the bigger task: fostering strong relationships between the diverse people who come together to make money with software. Without a change of heart, all the practices and principles in the world will produce only small, short-term gains. You and the rest of your team share a fate. Act like it and you may come to believe it.

Alexander ultimately failed in his attempt to balance power between the designers and users of space. The architects didn't want to give up any of their power and the clients didn't know to demand any. Programs are not buildings and software development is not construction. Our materials are not their materials and our social structures are not locked into millennia of fixed relationships. We, in software, have the opportunity to create new social structures in which technical excellence is joined with business vision to create new products and services of unique value. This is our advantage.

XP relies on the growth of powerful programmers; able to quickly estimate, implement, and deploy reliable software. These programmers turn over business decision making to the business-oriented part of the team. The appropriate sharing of power and responsibility among the team may seem utopian. This balance is contingent on mutual respect. There is no absolute power. The power of XP evaporates if misused. Each manipulated estimate, each job rushed through without pride, puts the team that much further from its potential power. XP relies on each member of the team; including executives, managers, and customers; to be fully committed and contribute what he can. A team working together can accomplish more than the sum of its members' separate efforts. Sharing power is pragmatic, not idealistic.

Realizing the potential in software requires teamwork. The first fifty years of computing have gone pretty well. I've heard lectures predicting that the next century is the century of biology, not computing. Computing will be relegated to a supporting role. I believe this will be true if software continues business as usual. If our software tools and techniques creep forward, biology will soon overtake software as a driver of social and economic change.

Tools and techniques change often, but they don't change a lot. People, however, change slowly but deeply. The challenge of XP is to encourage deep change, to renew individual values and mutual relationships to give software a seat at the table for the next fifty years. Unleashing the potential of the human spirit will lead to a future for computing that we can't yet imagine.