A brief journey into XP and its 3 main pillars

Table of contents:

1. What is XP all about?
2. Values, principles and practices
3. Conclusion

What is XP all about?

We as developers are well accustomed to hearing “we need short development cycles in order to have more feedback and thus improve our deliveries both in time and quality”. I won’t say all of us do this because this is real life and many of our wishes can’t be done due to reasons out of our control, being them the open mindedness of other people, such as managers, clients and even other developers, of trying something new like XP or perhaps the inability to let go of old practices with its root on the fear of change.

Well, XP addresses all of these scenarios. I won’t reinvent the wheel trying to make a definition out of it, the book “Extreme Programming Explained” by Kent Back has a simple and efficient explanation:

“XP is a style of software development focusing on excellent applications of programming techniques, clear communication, and teamwork which allows us to accomplish things we previously could not even imagine.”

XP is older than I thought it was; Kent Beck published the book in 1999, sharing it to the world. We all know technology has changed a lot since then, however, many of the “antique” software development practices still stand valid nowadays. An example would be TDD (Test Driven Development), it was first introduced and defined in XP and is well diffused around the community.

Values, principles and practices

XP stands on 3 main pillars, “values”, “principles” and “practices”.

(Back, K., 1999. Extreme Programming Explained. )

Values

Values are what gives meaning to practices. They are root cause of why we like or dislike something in a situation. For example, while estimating tasks, a programmer exempts from doing so. Perhaps he does not want to be accountable if something goes wrong. In that case, the root reason is that he values protection over communication.

Values need to be made explicit because they give meaning to practices. Without them, practices can turn into tedious, dull tasks with no purpose. Whether communication is valuable for someone can be known by the practices also, writing a document 5 pages long instead of 15 minute conversation shows that I don’t really value communication as much as I say I do. “Practices are evidence of values”

XP embraces 5 values that guide development: communication, simplicity, feedback, courage and respect.

• Communication

“What matters most in team software development is communication”. On most of the cases, a problem happened due to lack of communication, not lack of knowledge. The user story was not explained well and no one cared to ask. Developing without communication is not progress. Communication has to be present in order to create a sense of team and cooperation.

• Simplicity

Simplicity is the principle that requires the most intellectual capabilities of all.

Aim for creating the simplest system capable of achieving the project goals. With simpler systems, communication also becomes easier, as you have less to communicate about.

• Feedback

“No fixed direction remains valid for long”. Change is inevitable, what we can control is how to approach it. Aim for feedback quickly, after every feature, know how it “behaved” and what to improve.

Trying to define everything in the first place does not work. First because we may not know what is the best way upfront, this comes only with experience, second, what is right today might be totally wrong tomorrow. With feedback, you can adjust the project and address these needs.

As with simplicity, feedback is crucial to communication.

• Courage

“Courage is the effective action in the face of fear”. Courage alone is dangerous, but with values, they are turn into something powerful. Telling the truth increases trust and communication. Courage to discard inefficient ideas make the system simpler.

• Respect

All values have respect in their core, if it’s not present, team members will not care about what they are doing. XP can’t save a project where team members don’t care about it.

Principles

“Principles are the domain specific guidelines for life”. Kent Beck makes an analogy with a bridge, having the ends as values and practices and the bridge itself, principles. Returning to the example of communication, do I write a long document or have a talk? Following the principle of humanity leads me to the path of the conversation, written communication is only a one way while the preferred option meets the needs for human connection, understanding and knowledge exchange.

“Practice are situation dependent. If the situation changes, you choose different practices to meet those conditions. Your values do not have to change in order to adapt to a new situation. Some new principles may be called when you change domains”

The principles below are the key ones:

• Humanity

Software is developed by humans. Many expectations and estimates are built without taking in consideration this factor. People aren’t machines, you can’t produce software out of the blue, and forcing it to happen will inevitably fail.

We need to have certain standards when it comes to making people good developers, such as basic safety, accomplishment, belonging and growth. A controversial topic among old school managers is time spent face-to-face to a computer. Classic and closed minded ones will say the more time, the better, however, people need time away from work in order to, first and foremost, rest, and second, learn new things, develop new perspectives and bring them into their workspace, thus leading to a more diverse and productive work environment. Without creativity, software development doesn’t grow.

A challenge is dealing with individual and team needs. Sometimes, your personal goals/needs won’t meet the team’s, and vice-versa. In such scenarios, there needs to be a good level of communication and understanding among team member to figure this out. As time passes and team members get more and more acquainted, achieving personal needs while respecting the team’s becomes easier, the reason being that trust is now present and stronger than before. Trust is the basis of any successful relationship, regardless if it is professional or personal.

• Self-Similarity

While estimating tasks, it is good taking as a base previous ones that were similar to the current. Self-similarity is about this, when the situation arises, “try copying the structure of one solution into a new context, even at different scales”. Sometimes, self-similarity won’t work because the context is extremely different, however, it still gives us a starting point, even if it serves as one to not be considered.

• Improvement

There is no perfect process and design in software development, the aim is to increasingly improve them with experience. Quarterly and weekly meetings gives us a change to reflect on what has been done, which in turn enables us to look on the improvements steps taken. For example, in software design in XP, a big upfront definition regarding a system architecture won’t work at the long run; by having continuous improvement, either small (tweaking a line in that class) or big (migrating databases), we can remove unnecessary code that took human power and financial support to take care of it. This helps us to narrow down our needs and simplify the system architecture on the first place.

• Flow

Aim to have a steady development and delivery. XP discourages phases, opting in for a continuous flow of activities. Software development has the well know cascade process, in which a single delivery is done, having no flow and only phases. This reduces feedback, then bug reports become more and more frequent because nothing is being solved, slowly transforming the system into having an unreliable fame.

Daily deployments is a commonly used approach to deal with this. Deploy once a feature has been written and its tests are passing. Another positive side effect is that if a bug is spotted, all team members know which specific deploy was the issue and rollbacking it turns out to be extremely simple.

• Opportunity

At every stage of development, aim to acquire the greatest level of knowledge. Don’t shy away from a problem, have the courage to face it and learn independent if you succeeded or failed. Knowledge does not come only in situations when everything goes according to plan, in fact, we learn most from our mistakes. For example, a person alones makes too many mistakes, program in pairs; estimates are way off? Meet more frequent and redo estimates.

“To reach excellence, problems need to turn into opportunities for learning and improvement, not just survival.”

• Quality

No don’t go horse, please

By no means should quality be sacrificed to serve as control. “Quality is not a control variable”. You may code like a maniac, having no regards for code quality, tests, design patterns, but the consequences will haunt the project for a long time. Leaving quality aside increases issues and costs, while the opposite, taking quality in and putting it on a higher ground results in more reliable software and faster deliveries.

Lack of knowledge regarding quality is no excuse for inaction. Do it the best way you can, while communicating with more experienced developers and going after knowledge sources, such as books, conferences, talks, and so forth. There is no limit in quality, only our ability to understand it.

• Accepted responsibility

“Responsibility cannot be assigned; it can only be accepted”. People can’t just make someone responsible for something if they don’t want it. Forcing it often causes a bad job being executed with a lack of purpose. Responsibility is coupled with authority. I don’t like the term authority because it gives a notion of looking down on people and thinking it is fine. I prefer to see authority as a condition in which somebody manages more, but does not mandate things.

Care has to be taken with responsibility, the reason being that the neglection of it causes confusion on the team. If the person who was supposed to take deal with the internal processes exempts from doing so, how can we improve? No one has the sufficient knowledge, that’s why that person was assigned responsibility. Living with uncertainty has emotional and financial costs.

Practices

Practices are our day-to-day actions, things we actually do, combining values and principles. It is tightly wrapped with knowledge, with more of it, the more of a change will happen to your practices. For example, I’ve been practicing the saxophone for about 4 years. On the first months, it sounded like a truck horn whenever I played, however as the years went by, I learned how to handle my breath and air flow intensity. Both a newbie and more advanced player play the saxophone, but what differs them are the techniques, which emerge from a junction of practice and knowledge. The practices below are the key ones:

• Energized work

Work as many hours to be productive while still being able to sustain them. Without a well rested and relaxed mind, you may still write code, but a not good and well thought one.

Don’t fool yourself into thinking that working long works will increase productivity, sure, it can make its way on the short run, but not on the long one; it is quite possible that you will have a burnout at the end.

• Pair programming

Program with somebody else, sit by their side and instead of thinking alone, do it together. This gives the opportunity to brainstorm and clarify ideas, taking the turn when the partner is stuck and hold each other accountable for the changes being done.

This does not mean you can’t think and program alone, you sure can. If necessary, tell the team so and explore the problem.

• Weekly cycle

A day of the week, get together with the team to review progress up to date, checking if the actual progress matched the previous week’s one. Customers can also participate by choosing which stories to attack. For last, given the defined stories, this is the time to break and estimate them.

As the team members grow closer to each other, the time spent on the weekly meeting starts to reduce. The team will know how to communicate effectively and gradually optimize their time.

• Quarterly cycle

A quarterly cycle addresses bigger decisions and less technical ones compared to the weekly cycle. Once a quarter, with the team, identify bottlenecks, plan the quarter theme(s), pick a quarter worth of user stories with the chosen theme(s) and for last, focus on the big picture regarding the project, where it’s supposed to be and at which stage, for example.

• Test-First programming

Before coding any feature, write a failing test. Test first programming, now called TDD, gives the developer a focus with a clear and explicit goal to accomplish, which is to make the failing test to pass. It gives a sense of progress and rhythm, write tests, a feature, execute the test; write tests, a feature, execute the tests.

For last, testing increases trust among programmers. It is hard to trust code with a failing test. By writing automated tests, you make it explicit to other programmers that what it is being written can be trusted, not only code, but also you as developer that cares.

• Incremental design

Invest on design every day, don’t simply design before all the code/logic takes place. Whenever you spot a piece of code that looks fuzzy, improve it. If all the architectural design is made prior to everything, it is easier to deviate from it, daily adjustments brings us back on track while still making progress

People might think that these continuous adjustments cost greater than the overall one to simply design upfront, however, the cost of a big bug due to a wrong design will cost more than the tiny ones in between development.

Choosing incremental design will come as a hard decision at the first time on projects with a fixed investment. Given the payment was previously done at the beginning with a fixed price, the uncertainty of how much will be spent is not appealing. I say “uncertainty” because given it is the first time, this is not well known. As more and more projects follow this path, experience will come to all team members, not only developers, and estimating how much will be spent turns out as something more and more accurate, which calms down the people holding the money. This is crucial for XP, however, also one of the hardest to achieve.

Conclusion

What I have written is only a section on XP, there is more. Its philosophy plays an extensive and important role in the learning process.

Beginning to adapt to XP practices can be a hard task, but don’t give up. There is no need to follow all of XP upfront, there are many ways to accomplish this. Like entering a pool, you can put one foot at a time, leave the feet dangling in the water, jump right in, enter in a smaller pool and so on. It’s up for you and your team to decide what’s the best approach. Also, XP does not make you follow all its guidelines, you may choose to start out with a few and then, as the team grows comfortable, insert more.