Extreme Programming (XP)

Extreme Programming (XP) is an agile project management framework used in software development. It prescribes everything, from how to organize projects and develop software to how to increase developers' productivity and what's the best way to collaborate on code.

What is Extreme Programming?

XP starts with the idea that software development is hard. That's why, according to extreme programming, the four most important things in software development are: coding, testing, listening, designing. Extreme programming aims to produce software of high quality and improve responsiveness to customers’ needs. It’s renowned for creating quality software, feedback techniques that provide rapid feedback, and improving collaboration among teams.

Extreme programming helps to improve quality of software, but also quality of life for the team members. In extreme programming managers, customers and developers are all equal partners who work together to create the best software and work as a collaborative and cohesive team. In a scenario where the requirements are ever-changing, extreme programming helps teams to develop high quality software.

Basic Principles of Extreme Programming

CODING - At the end of the day, if the program doesn't run and make money for the client, you haven't done anything.

TESTING - You have to know when you're done. The tests tell you this. If you're smart, write them first, so you'll know when you're done. Otherwise, you're stuck thinking you maybe might be done, but knowing you're probably not, but you're not sure how close you are.

LISTENING - You have to learn what the problem is in the first place, then you have to learn what numbers to put in the tests. You probably won't know this yourself, so you have to get good at listening to clients - users, managers, and business people.

DESIGNING - You have to take what your program tells you about how it wants to be structured and feed it back into the program. Otherwise, you'll sink under the weight of your own guesses.

Listening, testing, coding, designing. That's all there is to software. Anyone who tells you differently is selling something. - Kent Beck, the creator of Extreme Programming

Project Lifecycle in XP

Small releases - finished work is delivered to the customer at the end of each week, so the customer gets value sooner rather than later.

Weekly cycle - the team plans what features to deliver at the end of each week, works in one-week cycles, and reviews progress each Friday. If some feature takes more time, it's broken down into several cycles.

Quarterly cycle - because work is delivered in small releases, you need some long-term strategy to make sure stories fit together, and the software doesn't end up all over the place.

Extreme Programming Practices

XP is a very specific methodology that gives practical advice to managers and software developers so they can reach the goal of delivering on time what the stakeholders require.

• Pair Programming - all production code should be written by two developers working on a single computer. This should increase code quality and lower the number of bugs, thus saving you from future bug fixing.
• Collective code ownership - everyone has access to all code and is empowered to fix things independently. Also, the code you write will be used by someone else, so you should make your code clean and simple to understand.
• Together but alone - there shouldn't be cubicles and walls between developers to encourage face-to-face communication. But everyone should have privacy when needed and shouldn't be interrupted so that they can stay focused.
• Cross-functional teams - work is done in small teams, so each developer should have multiple skills and take care of whatever needs to be done. There are only two mandatory roles on a team (customer and developer) and two optional (coach and someone who will track results).
• Customers always available - only the customer knows how the software should work, and only they can answer questions that constantly pop up during the development.
• Information radiators - work should be transparent, and everyone should know who is working on what. This is solved by using a public Kanban board.
• Daily stand-up meeting - it's more efficient to have one short meeting everyone has to attend than many smaller getting-up-to-speed meetings during the day.

Values of Extreme Programming

Extreme programming brings positive aspects and values to the production process, such as simplicity, communication, feedback, courage, and respect. By figuring out the simplest way to create software and implement changes based on the customers’ feedback and requests, extreme programming brings simplicity to the complex process such as creating software. Effective communication is needed to keep the project on track especially when problems arise. Extreme programming encourages and expects that everyone involved in the process effectively communicate and be open and honest. Extreme programming involves customers in the process and allows them to be in touch with the developers throughout the process. As the clients share their feedback it makes it easier on the team to incorporate the requested features in the production process. Courage to take on accountability and openly and honestly share updates on the progress is what pushes the team forward when they use extreme programming. Mutual respect between customers, developers and team members is in recognizing that every member of the team contributes to the success of the project, instilling honesty and trust.

Best Practices for Coding

• The planning game - you should treat planning and estimating like a game, with rules to create emotional distance. This way, business and development know what to expect, and there's no conflict.
• Simple, incremental design - simply designed software takes less time to write and fix than a complex one. You should never add extra functionality because only 10% of it will be used, thus wasting 90% of your time.
• Refactoring - you should always go back and improve the code (make it simpler, remove redundancy, eliminate unused functionality, etc.). The goal of refactoring is to make the old code better to make work easier in the future.
• Coding standard - all code should be consistent so others can read it more easily. This means, for example, adopting Hungarian notation or camel case, deciding on tabs vs spaces, etc.

Best Practices for Code Deployment

Test-driven development — Tests are the cornerstone of XP. Automated testing saves time and lowers the number of defects. To make sure developers focus on tests, they first need to write an automated test (which will first fail) and then develop just enough code to pass the test.

Ten-minute build — You should be able to build the whole system and run all the tests in 10 minutes. If the process takes longer, it's less likely the test will be run frequently, thus negating the benefits of testing.

Continuous integration & deployment — To pull off a 10-minute build, you need to automate testing and code deployment. Every time changes are added to the code base, they are immediately tested and deployed if they pass the test.

Benefits of Extreme Programming

XP is specifically designed to successfully complete software development projects. Extreme programming relies on continuous releases and collaboration with stakeholders, minimizing the risk of missing the iteration’s scope. Rather than waiting for a sprint review meeting, the team works closely with clients and quickly changes course when necessary.

It’s only fitting for a specialized methodology such as XP to emphasize crucial practices that ensure top-notch software quality. Pair programming, test-driven development, and continuous integration are employed to ensure a sustainable development process without defects.

Each team and project could benefit from different project management methodologies, depending on their size, scope, and industry. Agile frameworks are usually better suited to smaller teams and projects, but some methods under this umbrella can be scaled easily and fit the shoe when it comes to managing larger projects. Waterfall works best when all activities are sequential and interdependent, while Kanban can be applied to almost all types of ventures.

When XP Doesn't Work (and Its Disadvantages)

XP only works for some software development companies. Each company has a different structure and develops a different type of software, so the one-size-fits-all approach XP advocates doesn't work everywhere.

XP suffers from the same disadvantages as all agile methodologies, plus a few more of its own:

• XP is a complex framework with many rules, rules someone has to enforce and everyone has to adopt.
• Collaboration takes more than putting all developers in one room, and logistically, it's only sometimes possible.
• XP relies on too many things, so if you don't do one thing right, all others, both up and down the dependency chain, will be affected.
• XP doesn't offer a clear-cut, foolproof process you can easily adapt and follow.
• Having an on-site customer so you don't have to write extensive specs is extremely risky because, if they leave, they take all domain knowledge away with them.
• Pair programming locks up twice as many resources as solo programming. Pair programming is useful for solving complex problems, but solving complex problems is very rare in everyday development in 90% of companies. Plus, not everyone likes to work in a pair, and it's more difficult to achieve a state of flow.
• XP de-emphasizes good UX design. Walking customers through mockups, storyboards, and use cases until they know what they want is much cheaper than fixing the code. This makes XP especially bad for both large programs and consumer software, as good UX design doesn't happen incrementally.
• Refactoring and unit testing are not a substitute for thoughtful design, modeling, and software architecture.
• Constant involvement is a tough sell for your customer/client, as well as not knowing how much everything will cost.
• Refactoring can be a time-waster. Refactoring is only beneficial for code used often by others than the original author, which is not always the case.
• Automated testing can only detect "computer" problems, while subtle, "human" usability problems are pushed aside.
• Most software consultancies and contractors don't care for the level of code quality that XP demands. Their job is to simply make something work in the short term while maintaining it is often someone else's job. Thus, they have no incentive to refactor or do other unbillable work.

XP is based on the assumption that the whole team is in one place - both development and the customer. In most cases, that's not viable.

Most software development companies today are outsourced, meaning the customer and the development team work not only in different places but on different continents, making XP impossible. Just to get an answer about some requirements, the XP team would have to wait anywhere from a few hours to a day. This is a deal-breaker for a framework that relies on agility and close collaboration.

Extreme Programming vs. Kanban

XP and Kanban are both part of the Agile framework, but they’re distinctly different in their application and main goal.

Extreme Programming vs. Scrum

The easiest way to understand XP is to think of it as Scrum with an added layer of coding best practices. XP takes Agile principles, gives you some processes like Scrum, and tells you exactly how to approach coding.

Extreme Programming is an Agile framework, meaning it advocates frequent releases, iterative development, and a high level of customer involvement. It's similar to Scrum, only XP is more prescriptive and opinionated.

Unlike Scrum, which is primarily concerned with team organization, XP is primarily concerned with code: its simplicity, how it's written and deployed, how developers work, etc. This means you can apply XP only if you work for a software development company.

Both Scrum and XP are best applied to smaller projects and best used by smaller teams of about five people. Scrum, however, can be scaled if managers wish to apply it to larger projects. The sprint velocity and iteration time are the same in these two approaches and amount to cycles of two weeks.

The main advantage of extreme programming in Agile over Scrum is the regular feedback loop the team gets from the stakeholders. Scrum teams could wait two weeks to discuss whether the direction they’re taking in their development process is good, while XP teams let clients get involved regularly so they can adjust and make changes immediately.

This leads to a lower risk level because XP teams react promptly and waste no time and resources on developing the wrong features. Specializing in software is another benefit XP holds over Scrum because it guarantees technical excellence.