Extreme Programming (XP) is a widely known concept. It is one of the best in the whole package of what a Software Engineer should be with himself and with others. We will talk about the principles of XP and how they are applied in a day-to-day basis.
Humanity
The human part is really important for developers. We need our personal life as everybody else and satisfy our human needs; that, in order to be awake and ready to produce code and help the team.
What do people need to be good developers? 🤔
- Basic safety — free from hunger, physical harm, and threats to loved ones. For example, fear of job loss threatens this need.
- Accomplishment — the opportunity and ability to contribute to 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.
As a matter of fact, XP practices meet both business and personal needs. There are other human needs, such as rest, exercise, and socialization —these do not need to be met in the work environment.
As an ilustration, time away from the team gives each individual more energy and perspective to bring back to the team. Also, limiting work hours allows people to find time for these other needs and enhances each person’s contribution while they are in the team.
Economics
Somebody has to pay for things. 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 it later. Incremental design explicitly defers design investment until the last 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 people. 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 benefiting another one. When the situation is bad, these solutions seem attractive.
For example, 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 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 for new programmers.
Mutual benefit in XP is searching for practices that benefit me now and later; and my customer as well. The truth is 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 is not the only principle at work in software development. Just because you copy a structure that works in one context does not mean it will work in another one —it is a good place to start, though. Just because a solution is unique does not mean it is 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. Also, 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 does not 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 solutions. Teams need diversity.
Two ideas about a design present an opportunity, not a problem. The principle of diversity suggests that 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 do not just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed. They do not try to hide their mistakes, but expose them and learn from them. No one stumbles into excellence.
Reflection is not a purely intellectual exercise. You can gain insight by analyzing data, but you can also learn from your gut. “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.
Practices
In XP there are several practices that go in line with Extreme Programming, these practices help teams to get the best of them and to produce code in a new way that brings with it a lot of advantages. XP practices are the following and we will talk a little bit of each one:
- Sit Together
- Whole Team
- Informative Workspace
- Energized Work
- Pair Programming
- Stories
- Weekly Cycle
- Quarterly Cycle
- Slack
- Ten-Minute Build
- Continuous Integration
- Test-First Programming
- Incremental Design
Weekly Cycle
- Review progress to date, including how actual progress for the previous week matched expected progress.
- Have customers pick a week’s worth of stories to implement this week.
- Break stories into tasks. Team members sign up for tasks and estimate them.
XP encourages us to make planning once a week, this planning is where we define the tasks that will be completed within five days. The tasks will be estimated and assigned to each programmer. Also, in this meeting we should check the past week’s progress and ensure that all tasks were completed. If some tasks are still pending then we should better our estimates.
Something that many teams are doing is having this weekly meeting on Tuesday or Wednesday instead of Monday, the reason for this is that many people do not like Mondays and also they do not like planning, by doing this you reduce a bit of stress during these meetings.
Quarterly Cycle
- Identify bottlenecks, especially those controlled outside the team.
- Initiate repairs.
- Plan the theme or themes for the quarter.
- Pick a quarter’s worth of stories to address those themes.
- Focus on the big picture, where the project fits within the organization.
These meetings are designed to eliminate bottlenecks or identify problems mid-sprint. During a week a lot of things can happen and the quarterly meetings help to intercept any problems that occur during the week. I see them as mini-sprints to solve a certain task or problem.
Slack
You should always include some minor tasks that can be dropped if you get behind. It is very important that you fulfill your promises and deliver on time. Many companies are used to overcommitting and underdelivering, but their plan is to ask for too much in order for the team to deliver as much as they can and still the result will be good for them but this is not a good practice. You should estimate and promise a reasonable amount of tasks and deliver them, no more no less —well if you deliver more it is okay! 😉
Ten-Minute Build
This is a really good practice in which you compile, run, and test your whole project in ten minutes. This helps teams to feel more secure about their system. Every new change or feature can be tested easily with the whole system so you will not be afraid to test a big new release with tons of new features because week by week you will be doing this practice and never miss a bug on your way.
You should develop this process in ten minutes because if it takes longer you will not like to do it that often. So, it is key to make it in ten minutes, if it is taking you longer than that, find a way to automate the process.
Continuous Integration
Integrate and test changes after no more than a couple of hours. This saying is key to XP. Continuous Integration will help you to deliver fast and with not much trouble in the future, when integrating new code, it is always unpredictable what will happen or what will break. The correct thing to do is as soon as you have some working tasks and tests, start integrating to the project.
The longer you take to integrate new code, the more unpredictable things might get. This also helps you with daily builds and to focus on delivering what you were asked, if you follow this practice your first system deployment will not be a big deal or a huge change of functionality.
Test-First Programming
Write a failing automated test before changing any code. Test-first programming addresses many problems at once:
- Scope creep — It is easy to get carried away programming and put in code “just in case.” By stating explicitly and objectively what the program is supposed to do, you give yourself a focus for your coding. If you really want to put that other code in, write another test after you have made this one work.
- Coupling and cohesion — If it is hard to write a test, this is a signal that you have a design problem, not a testing one. Loosely coupled, highly cohesive code is easy to test.
- Trust — It is hard to trust the author of code that does not work. By writing clean code that works and by demonstrating your intentions with automated tests, you give your teammates reasons to trust you.
- Rhythm — It is easy to get lost for hours when coding. When programming test-first, it’s clearer what to do next: either write another test or make the broken test work. Soon this develops into a natural and efficient rhythm — test, code, refactor, test, code, refactor.
A refinement for test-first programming is continuous testing which consists of running tests on every program change. Continuous testing reduces the time to fix errors by reducing the time to discover them. The tests have to run quickly, however.
The advantage of these tests is that they run pretty fast and you can include thousands of them in the ten-minute build.
Incremental Design
Since we were in school, teachers always taught us that we should overdesign in the design phase because we would not have time to do it later and this way we can prepare for future changes.
In XP, this is not always the case. In today’s programming world, requirements change often, clients change their minds pretty often and sometimes a new requirement appears out of nowhere because of the petition of the head master director of the company. When you only design at the beginning of the project, applying these new requirements can be a pain in the back. A practice that XP uses to solve this is incremental design.
You will design the bases and basic requirements at the beginning of the project, but as you advance or as changes appear you will continue to design based on them. By using this system you will be more prepared for new changes. XP teams work hard to create conditions under which the cost of changing the software does not rise catastrophically. Automated tests, the continual practice of improving the design, and the explicit social process all contribute to keep the cost of changes low.
So, with all the practices of XP we can apply this one in particular and remain calm that our other practices will sustain the practice of designing on the go.
To sum up
As we discussed earlier, XP is amazing for every programmer and it really builds you up to reach that senior level we all want. Applying all these principles is not something that will take you days, so it’s okay to go slow and be patient on applying these new principles in our daily programming life. At the end of the day, the trip is more than worth it and you will actually produce professional code.
