XP explained second edition (WIP) - book club at Codurance
The content here is under the Attribution 4.0 International (CC BY 4.0) license
Extreme programming (XP)  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.
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”.
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
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.
Basically keep people that are doing great together, do not avoid the human aspect of it.
“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.
Skipped - interview
Chapter 18 and Chapter 19
Chapter 22 and Chapter 23
- K. Beck and C. Andres, Extreme Programming Explained: Embrace Change (The XP Series). Addison-Wesley Professional, 2004.
Table of contents
- Chapter 1
- Chapter 2
- Chapter 3
- Chapter 4
- Chapter 5
- Chapter 6
- Chapter 7
- Chapter 8
- Chapter 9
- Chapter 10
- Chapter 11
- Chapter 12
- Chapter 13
- Chapter 14
- Chapter 15
- Chapter 16
- Chapter 17
- Chapter 18 and Chapter 19
- Chapter 20
- Chapter 21
- Chapter 22 and Chapter 23
- Chapter 24
- Chapter 25