Extreme Programming (XP)

7 min readApr 21, 2016

What is Extreme Programming?

Extreme programming is a software-development discipline that organizes people to produce higher-quality software more productively.
— “Extreme Programming Explained”

Extreme programming takes the best practices of traditional software engineering methodologies to “extreme” levels, hence the name. It is commonly referred to as XP. Before going into details let me tell you the back story.

Recently, I attended a four day workshop on Extreme Programming for developers at ThoughtWorks. It is a nice place filled with a bunch of XP enthusiasts who are passionate about what they do and love sharing it with the community. I enjoyed my time over there and learned a ton. This is my first experienced with XP. This is no way a comprehensive article on XP. Its just my attempt to continue their philosophy of sharing and recording my workshop experience. Alright, back to our discussion…

What are software development methodologies? You see, writing code is not the end to programming. It has to be clean code. It has to work well in the system, ensuring that it’s not breaking code written by others. It has to be tested both code and functionality wise. We have to make sure that there are no security issues and deliver it to the clients constantly. In addition to this, we need to integrate the feedback we get and move the project in the direction of changing customer’s requirements. But at the end, we need to make sure that we are having fun doing what we love, “programming”. Achieving these, is difficult, especially when it comes to complex projects with huge teams as things can quickly get chaotic.

Processes and methodologies bring method to this madness.

These methodologies are guidelines and suggestions. Over a period of time, people observed the patterns, formulated structure around it, gave it a name so that we can identify and put in a conscious effort to follow them. XP is one such methodology and it falls under the umbrella of agile software development.These are not set procedures you need to enforce on your team to get quick results.

Kent Beck is the creator of Extreme Programming and one of the 17 original signatories of Agile Manifesto.

Read about the agile manifesto and the twelve principles.

INCEPTION

While there are different types of estimates and different ways of identifying the project requirements and they vary from companies, teams and projects, inception is one of the popular ways of initiating the project. In inception, customers, product owners, business analysts, architects, developers and quality analysts get together and discuss the customer needs, technologies, etc. This is a very high level evaluation of the project requirements. The stories(functionality) and their size(no of points) [small(1 point), medium(2 point) and large(4 point)] and the raw velocity of the team(how many points each team can complete in one iteration) are discussed. Based on that, project estimation is done.

STAND-UP

Stand-up is not a meeting. Stand-up has specific goals, procedures and practices. As the name suggests stand-up has to be done with the whole team standing together preferably at the work place unlike a standard meeting which is done in a seated conference. A typical stand-up should not be more than 15 mins.

Stand-up helps you to share understanding of goals, problems and improvements thus co-ordinating efforts and helps everyone identify themselves as a team. People who are interested to know the status of the project or contributing to it should attend it. Stand-ups are not aimed at reporting to the manager, it is team members sharing their status to the whole team based on “yesterday-today-obstacles”. While there are many ways to interpret it, the simple structure is

What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?

While people may jump into problem solving the moment they hear the obstacles, its better to take it offline.

PAIR PROGRAMMING

In Pair Programming there are always two people working on a single piece of code at the same time on the same machine. One who writes the code is called driver and another constantly reviews it as it is being written, he is called navigator. They constantly switch roles. The key advantage is the quality of the code. It brings the best possible solution as two minds are better than one. It brings down the bus hit factor, making the team members share knowledge and become aware of the whole project. It improves the dynamics of the team.

Try to avoid some negative patterns like superman, back seat driver, king of short cuts to make pair programming effective. The complexity of the problem at hand and the experience of the people involved determines the effectiveness of pair programming. Pairing matrix is one of the key information radiators used to make sure every one in the team is equally pairing to get the maximum benefit.

Test Driven Development(TDD)

This is the key component of XP. The programming cycle starts with writing unit-tests. Unit-tests are tests written for the smallest piece of code which can be tested independently. You write test cases for the implementations to be done, write code to make them pass and refactor it.

For a person who has not done TDD or never written test cases this might sound counter productive. The reason is to make testing part of the development process and not to see it as something to be done at the end. It might seem daunting to write tests for all the cases but you need to make sure that you are covering enough. The standard rule of thumb is, at least one test case should fail if one line of code is changed. The effort you put in will be helpful in the long term. TDD requires a minimal upfront design and helps you in evolving the design over time.

Good test cases should cover all possible error conditions but try to run in minimum possible time. There are lot of testing frameworks available to achieve this with minimal effort.

REFACTORING

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior.
— Martin Fowler.

According to TDD and XP methodologies you have to implement the features with minimum working code. Once that’s done you can go back and beautify your code. Let the design evolve from the requirements, don’t do upfront design. Don’t think of the future requirements, just do the minimum required.

During the refactoring stage, you have to look for code smells. Code smells are the warning signs in your code. Read about some code smells and develop your code nose.

TESTING

As part of TDD we write as many unit-tests as humanely possible and all our code is run against it every time we do a build. These are just one part of the whole testing gamut. You need to do other kinds of testing like acceptance test, security tests, stress test, integration tests…

We need to check how different units are playing along by writing integration tests. Acceptance tests are done to find out whether the implemented features are working in the way they are expected. As the name suggests security tests are for testing the strength of the code against any malicious attacks. Stress tests are written to find out the capability of the server against heavy loads and find out which part of the code is making it fail.

CI/CD

CI/CD stands for continuous integration, continuous delivery and continuous deployment. Continuous Integration encourages the team members to integrate the work frequently and automate the task of building the code, static analysis of code, running unit tests, functional test cases…etc. In Continuous Delivery and Continuous Deployment the focus is on taking the build to the customer production environment. Where Continuous Delivery is a planned deployment which happens in a product feature release cycle (could be a weekly or monthly release), continuous deployment pushes the build every time the code is checked in to the repository.

Few practices of CI/CD are maintaining a single repository where every thing needed for a build is available and everyone commits to the main repository every day. Automate the build generation by using tools available for the specific platform. Make your build self-testing by writing unit-tests, functional tests using the the testing frameworks. Keep the builds fast. Make sure every one knows the build status and access to the builds.

CI/CD takes out the boring manual tasks and helps you set up a automated way of integrating, building and deploying. In CI/CD you setup a pipeline. Pipeline is nothing but a set of tasks to be run from the moment you pushed your code to the main branch till the final build is deployed on the server which makes the product live. Early feedback is the key in CI/CD.

Retro

Retro is short for retrospection. Retro happens every few weeks to a month depending on the team requirements. Retro is the place where the team discusses the state of the project. They discuss the items which are successful and the concerns they are facing. The team comes up with the list of action items to solve the problems and assign a member to work on it and constantly check for updates. There are myriad ways of doing this. Over four days of workshop we have experienced a new style of retro every day, including remote retro, which is simulated over video conference.

Ultimately “Agile Programming”, “Extreme Programming”, “Spiral Development”, and the “Waterfall Methodology” are all just labels. In reality most software projects use certain aspects of these methodologies depending on their project requirements, all of which is based on sound software engineering principles and practices.

The XP workshop team did a fantastic job explaining the principles and making us understand and experience the XP way of doing things. If you get the chance to attend the workshop, don’t miss it. It’s really worth it.

Its been 3 weeks since I attended the workshop and all I could implement at work is stand-up. But yeah, it’s a not a bad start. TDD is the major component which can change the way of writing code. I am going to incorporate TDD into my workflow and will write about my experience. Stay tuned.