Today we focus on some of the key values of Extreme Programming (XP), the agile software-development methodology, that leverages the power of communication, simplicity, feedback, respect, and courage [Infographic]

To put it out very simply, with the help from Techopedia, Extreme Programming (XP) is an intense, disciplined and agile software development methodology focusing on coding within each software development life cycle stage: continuous integration to discover and repair problems early in the development process, customer involvement and rapid feedback. It was created by Kent Beck (born 1961), an American software engineer and one of the 17 original signatories of the Agile Manifesto.

Beck created the XP during his work on the Chrysler Comprehensive Compensation System payroll project. He became the project leader in March 1996 and began to refine the development methodology used in the project and wrote a book on the methodology, “Extreme Programming Explained”, published in October 1999.  The approach was conceived and developed to address the specific needs of software development conducted by small teams that are facing changing requirements.

Fundamentals of XP include:

  • Distinguishing between the decisions to be made by business interests and those to be made by project stakeholders
  • Writing unit tests before programming and keeping all of the tests running at all times
  • Integrating and testing the whole system-several times a day
  • Producing all software in pairs, two programmers at one screen
  • Starting projects with a simple design that constantly evolves to add needed flexibility and remove unneeded complexity
  • Putting a minimal system into production quickly and growing it in whatever directions prove most valuable

and they are based on these 4 core values:

  • Communication between team members and customers must occur on a frequent basis and result in open project discussion without fear of reprisal
  • Simplicity – involves using the simplest design, technology, algorithms and techniques to satisfy the customer’s needs for the current project iteration
  • Feedback must be obtained at multiple, distinct levels, e.g., unit tests, code review and integration
  • Courage – Implement difficult but required decisions

It is based on very simple rules and values, often described by its creator as common sense. But why does it have “extreme” in the name? Well, simply because it takes commonsense principles and practices to extreme levels. This is why it is sometimes considered controversial; the focus of XP is on designing and coding for the needs of today instead of those of tomorrow, next week, or next month, which has a clear disadvantage – this approach might require more effort tomorrow to change the system that has already been initiated.

The real question is if the XP works out for you. The best way to find out, just like for any other Agile approach, is to get informed and test out, just as advised by Jurgen Appelo, the concepts of methods and frameworks communicate a rigid set of practices, and people can get dogmatic about whether a method or framework is understood or implemented “correctly”; he proposes the metaphor of workout exercises, because there is not a best method or framework for working out, that can be applied to everyone, but one can pick the ones that suit them best, and maybe even invent their own. The same thing goes for business.

So be sure to read Extreme Programming Explained by Kent Beck and decide for yourself. We bring you the the conclusion of his book, that describes very accurately how XP has been created to reconcile humanity and productivity.

All methodologies are based on fear. You try to set up habits that prevent your fears from becoming reality. XP is no different in this respect from any other methodology. The difference is in what fears are embedded in XP. To the degree that XP is my baby, XP reflects my fears.

I am afraid of:

  • Doing work that doesn’t matter
  • Having projects canceled because I didn’t make enough technical progress
  • Making business decisions badly
  • Having business people make technical decisions badly for me
  • Coming to the end of a career of building systems and realizing that I should have spent more time with my kids
  • Doing work I’m not proud of

XP also reflects the things I’m not afraid of:

  • Coding
  • Changing my mind
  • Proceeding without knowing everything about the future
  • Relying on other people
  • Changing the analysis and design of a running system

Writing tests I had to learn not to fear these things. It didn’t come naturally, especially with so many voices crying that these were exactly the things I should be afraid of, the things I should work very hard to avoid.

Check out the basics of XP in our new infographic



Extreme Programming Explained by Kent Beck