XP explained second edition (WIP) - book club at Codurance

Published Jul 27, 2021

Extreme programming (XP) [1] is a methodology focused on the technical and social aspect of software development. It focuses on two main pillars: agile and technical excellence.

Technical excellence is the structure that allows teams to be agile. On the other hand SCRUM is the methodology that got traction and is the most adopted by the industry as a means to “be agile”. Therefore, as already explored by Martin Fowler SCRUM has a place in the party, but is not the main course.

Kent Beck popularized different technical practices on writing XP and this post aims to go over the book and his contribution with the industry about software development. XP is the glue between the practices SCRUM and the technical side, XP fills in the gaps that SCRUM left behind. Alongside of this post, there is a mind map as well, that can be explored here.

this is a wip that I was building as we were reading xp 2ed in the @codurance book club, time to finish it up #craftatheart pic.twitter.com/o10R6uPG8o
— Marabesi 💻🚀 (@MatheusMarabesi) October 4, 2021

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

Chapter 7

Chapter 8

It is interesting how Beck’s starts the chapter 8 talking about getting started with XP practices, he follows the conversation exploring the idea of change. Changing too fas can be risky, on the other hand change is needed to accomplish results.

Looking at what you want to achieve might be a good way to start, as Becks’s says: Look at what you want to achieve. Then, start using one of the practices: “Automate the build”, “Test first all day”. Another scenario that might help is to focus on the task at hand, for example, there is an integration that is coming up and I am feeling nervous regarding the code and design. Pair programming is the practice that addresses technical collaboration.

It is interesting how Beck’s chapter starts about changing and before jumping into the next section he elaborates on the difficulty of change. Anyways, change always starts at home.

“Dictating practices to a team destroys trust and creates resentment”.

“Software development is capable of much, much more than it is currently delivering”.

Chapter 9

Be mindful of implementing the changes before doing the preliminary work to address the needs, otherwise you will have a disaster on your hands.

Real customer involvement

Customer should be part of the team
Proxy customer leads to waste of time
Customer won’t trust us if he knew how software development is
Waste time covering up

Incremental deployment

Beck’s is explicit on big release up front or the D-Day as it is called in the book, his personal experience depicts a disaster on trying to migrate a legacy system of contracts to a new one, failing to reproduce the new behavior, he lost the bonus he would received for that.

Team continuity

Basically keep people that are doing great together, do not avoid the human aspect of it.

Shrinking Teams

Root-Cause Analysis

“Every time a defect is found after development, eliminate the defect and its cause.”

Write an automated system-level test that reproduces the defect.
Write a unit test with the smallest possible scope that also reproduces the defect.
Fix the system, so the unit test works. Repeat till it works.
Once the defect is fixed, figure out why the defect was created.

This is inspired by Taiichi Ohno on the five whys.