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

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 excelence.

Technical excelence 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.

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 achive 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 fous 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 difficuty 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 beforedoing 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 weast of time
  • Customer won’t trust us if he knewhow software develompent is
  • Weast time covering up

Incremental deployment

Beck’s is explicity on big releaseup front or the D-Day as it is called in the book, his personal experience depicts a disaster on trying to migratea 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 togheter, do not avoid the human aspect of it.

Shirinking Teams

Root-Cause Analysis

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

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

Taiichi Ohno, the five whys:

1. 2. 3. 4. 5.

Shared code

Chapter 10

Chapter 10 notes part 1 Chapter 10 notes part 2

Chapter 11

Chapter 11 notes

Chapter 12

Chapter 12 notes

Chapter 13

Chapter 13 notes

Chapter 14

Chapter 14 notes

Chapter 15

Chapter 15 notes part 1

Chapter 15 notes part 2

Chapter 16

Skipped - interview

Chapter 17

Chapter 17 notes part 1

Chapter 18 and Chapter 19

Chapter 18 and Chapter 19 notes

Chapter 20

Chapter 20 notes part 1

Chapter 21

Chapter 21 notes part 1

Chapter 22 and Chapter 23

Chapter 22 and Chapter 23 notes

Chapter 24

Chapter 24 notes part 1

Chapter 25

Chapter 25 notes part 1

References

  1. [1]K. Beck and C. Andres, Extreme Programming Explained: Embrace Change (The XP Series). Addison-Wesley Professional, 2004.