Extreme Progamming Explained

“Eclipse is an open source project and one of our goals is to practice completely transparent development. The rationale is simple; if you don’t know where the project is going you cannot help out or provide feedback.” -Erich Gamma (foreword to Extreme Programming Explained: Embrace Change, 2e
, the subject of my post here) Even if your development process is slightly translucent, Erich’s rationale applies. If your development process is opaque, ask why and demand an answer.

Values bring purpose to practices. Practices are evidence of values. Principles bridge the gap between values (universal) and practices (intensely situated).

Extreme programming (XP) values communication, simplicity, feedback, courage and respect. These values are effective when applied together, not in isolation.

Mr. Beck’s four criteria used to evaluate the simplicity of a design:

  1. Appropriateness for the intended audience
  2. Communicative
  3. Factored
  4. Minimal

Feedback is the value I focused on the most during my read of Kent Beck’s text. I see the need for better heartbeat recognition, pulse taking and continual health assessments in some of the projects I lead. Establishing the right frequency and depth of project heartbeats can lead to a proper balance between process and reflection. Without periodic and regular project “physicals” it can be difficult to ascertain whether project/participant health is improving or declining. Project assessment need not be arduous or mysterious, but it does require discipline and commitment.

I was also impressed by Mr. Beck’s focus on flow. Insist on a high degree of continuous flow and quickly resolve all flow disruptions. Daily builds are not enough! Software should function correctly on a (verified) daily basis, at a minimum (i.e. always be deployable). Integration environments are critical to project flow. Metrics can lead to awareness. Awareness can lead to change and the development of practices to institutionalize change.

Here are just a few of the statements made by Kent Beck that made a particularly strong impression:

  • “If you’re having trouble succeeding, fail.”
  • “A concern for quality is no excuse for inaction.” The goal is to make the quality of software development good enough that there is no need for downstream QA. This means that everyone in the project is responsible for quality without exception.
  • “Without daily attention to design, the cost of changes does skyrocket.”
  • “Keep the design investment in proportion to the needs of the system so far.”
  • On the role of Product Managers: “In XP, product managers write stories, pick themes and stories in the quarterly [release] cycle, pick stories in the [bi-]weekly [iteration] cycle, and answer questions as implementation uncovers under-specified areas of stories.”
  • On the role of Architects: “Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories.”
  • “There is so much waste in software development. The waste is rooted more in what we believe and feel than in what we do. Becoming aware of and addressing those beliefs and feelings takes time and experience.”

Update 12/1/2008: For more of my book reviews and to see what else is in my book library (i.e. just the business-related or software-related non-fiction therein), please visit my Books page.