XP Principles Part 1

In this post I will be talking about Kent Beck’s Extreme Programming Explained book, specifically Chapter 5, in this chapter we will talk about XP principles.

Humanity

The human part is really important in developers, we need our personal life as everybody else and satisfy our human needs to be awake and ready to produce code and help the team.

What do people need to be good developers?

• Basic safety — freedom from hunger, physical harm, and threats to loved ones. Fear of job loss threatens this need.
• Accomplishment — the opportunity and ability to contribute to their society.
• Belonging — the ability to identify with a group from which they receive validation and accountability and contribute to its shared goals.
• Growth — the opportunity to expand their skills and perspective.
• Intimacy — the ability to understand and be understood deeply by others.

XP practices meet both business and personal needs. There are other human needs; such as rest, exercise, and socialization; that don’t need to be met in the work environment. Time away from the team gives each individual more energy and perspective to bring back to the team. Limiting work hours allows time for these other human needs and enhances each person’s contribution while he is with the team.

Economics

Somebody has to pay for all this. Software development that doesn’t acknowledge economics risks the hollow victory of a “technical success”. Make sure what you are doing has business value, meets business goals, and serves business needs. For example, solving the highest priority business need first maximizes the value of the project.

Software development is more valuable when it earns money sooner and spends money later. Incremental design explicitly defers design investment until the last responsible moment in an effort to spend money later. Pay-per-use provides a way of realizing revenue from features as soon as they are deployed.

Mutual Benefit

Every activity should benefit all concerned. Mutual benefit is the most important XP principle and the most difficult to adhere to. There are always solutions to any problem that cost one person while benefitting another. When the situation is desperate, these solutions seem attractive.

XP solves the communication-with-the-future problem in mutually beneficial ways:

• I write automated tests that help me design and implement better today. I leave these tests for future programmers to use as well. This practice benefits me now and maintainers down the road.
• I carefully refactor to remove accidental complexity, giving me both satisfaction and fewer defects and making the code easier to understand for those who encounter it later.
• I choose names from a coherent and explicit set of metaphors which speeds my development and makes the code clearer to new programmers.

Mutual benefit in XP is searching for practices that benefit me now, me later, and my customer as well. Win-win-win practices are easier to sell because they relieve some immediate pain.

Self-Similarity

Try copying the structure of one solution into a new context, even at different scales. Self-similarity isn’t the only principle at work in software development. Just because you copy a structure that works in one context doesn’t mean it will work in another. It is a good place to start, though. Likewise, just because a solution is unique doesn’t mean it’s bad. The situation may really call for a unique solution.

Improvement

In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.

“Best is the enemy of good enough” suggests that mediocrity is preferable to waiting. This phrase misses the point of XP, which is excellence in software development through improvement. The cycle is to do the best you can today, striving for the awareness and understanding necessary to do better tomorrow. It doesn’t mean waiting for perfection in order to begin.

Diversity

Software development teams where everyone is alike, while comfortable, are not effective. Teams need to bring together a variety of skills, attitudes, and perspectives to see problems and pitfalls, to think of multiple ways to solve problems, and to implement the solutions. Teams need diversity.

Two ideas about a design present an opportunity, not a problem. The principle of diversity suggests that the programmers should work together on the problem and both opinions should be valued.

Diversity is expressed in the practice of Whole Team(which we will review later), where you bring together on the team people with a variety of skills and perspectives. The various planning cycles encourage people with different perspectives to interact with the goal of creating the most valuable software possible in the time available.

Reflection

Good teams don’t just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed. They don’t try to hide their mistakes, but expose them and learn from them. No one stumbles into excellence.

Reflection isn’t a purely intellectual exercise. You can gain insight by analyzing data, but you can also learn from your gut. The “negative” emotions like fear, anger, and anxiety have long provided cues that something bad was about to happen. It takes effort to listen to what your emotions tell you about your work, but feelings tempered by the intellect are a source of insight.

Reflection comes after action. Learning is action reflected. To maximize feedback, reflection in XP teams is mixed with doing.