Extreme Programming Explained

Author : Kent Beck with Cynthia Andres

I’ve been reading and listening about Extreme Programming (XP) practices for the past few years. My knowledge about XP was limit to blog posts and videos which I consumed.

I heard a lot of terminologies while developing software that was part of XP practices, but I was able to understand only a few of them.

So I picked up this book. Of course, just reading the book won’t help. I need to apply these practices in the real world to understand them. But I see this as a start.

This book explains the XP values, principles, and practices. To perform these practices, XP teams should have certain values i.e Communication, Simplicity, Feedback, Courage, and Respect. Without these values and principles, it’s very hard to practice XP. We need to build those values at the individual, team, and organization levels.

There many other values, principal and practices are explained in this book. I am going to highlight a few of them which I feel important base on my experience.

After reading I found there are some practices that I was already following like.

  1. Communication: Communication is key to any team. Whenever you encounter a problem. Ask yourself. Is it because of a lack of communication? How can you address those problems in the future using communication?
  2. Pair programming: Pair programming does not mean that you can’t work alone. Pair programming is a dialog between two people simultaneously programming, analyzing, and testing to program better.
  3. Feedback: We use feedback to get closer and closer to our goals. Are we going in the right direction? Do we need to improve? These are some of those questions to get feedback.

There are some practices which I am still improving.

  1. Test First Programming: We also called it TDD (Test-driven development) where we are writing tests before writing production code which helps us to understand the scope and designing of the code. In TDD I found writing GUI and end-to-end test cases are very hard.
  2. Daily builds: We should have CI/CD in place which provides daily builds. These builds should be able to run tests and should be ready for deployment.
  3. Estimates: When you ask a programmer for the estimate, they will find a place to hide :). Estimates are hard. This can be improved over time. To estimate better we need to know the constraint and acceptance criteria from user stories.
  4. Planning: You can plan weekly, quarterly and yearly. Try to break down planning as much as possible into a shorter period.

And there are a few things that I am still exploring.

  1. Involved customer: Make people whose lives and business are affected by your system part of the team. The point of customer involvement is to reduce wasted efforts by putting people’s needs in direct contact.
  2. Incremental Design: The question is not whether or not to design, the question is when to design. The incremental design suggests that the most effective time to design is the light of experience.

I highly recommend this book if you are developing software.

Highlighted Quotes :

  • The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change.
  • To make a system simple enough to gracefully solve only today’s problem is hard work.
  • Two ideas about a design present an opportunity, not a problem.
  • Learn to see problems as opportunities for change.
  • Working weekends is not sustainable; if the real problem is that the estimates are overly optimistic, then work on improving your estimates.
  • Everyone on the team can recommend changes, but they should be prepared to back up their concerns with action.
  • Inaccurate estimates are a failure of information, not of values or principles.
  • 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.
  • Expecting others to do what you are not willing to try yourself is disrespectful and ineffective.
  • Respecting everyone on a distributed team is even more important because of differences in culture and lifestyle.
  • Listening is a far more important skill inside a community than talking.

Get it from amazon

Thank you for taking the time to read my blog.

In case of any question, you can reach me on Twitter or Email me.

If you like this kind of content then you can subscribe to my blog and be the first one to get notified when any new content is published.

If you like this article, please like and share it with your friends/colleagues and help me to spread the word.

Site Footer