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.
Extreme Programming is an agile framework, which means it advocates frequent releases, iterative development, and a high level of customer involvement. It's similar to Scrum, only XP is a lot 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 in a software development company.
Project Management Methodologies and Frameworks
What's at the core of Extreme Programming (XP)
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.
XP starts with an idea that software development is hard. That's why, according to XP, the 4 most important things in software development are:
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, you'll write them first, so you'll know the instant 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 different 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 software doesn't end up all over the place.
BEST PRACTICES FOR CODE COLLABORATION
Pair Programming - all production code should be written by two developers working on a single computer. This should increase code quality and lower 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 on their own. Also, code that 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 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 that 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).
Customer 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.
BEST PRACTICES FOR CODING
The planning game - you should treat planning and estimating like a game, with rules to create emotional distance. This way, both business and development knows 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 actually 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 in order to make work easier in the future.
Coding standard - all code should be consistent, so other people can read it easier. 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 really 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 on a frequent basis, thus negating the benefits of testing.
Continuous integration & deployment - to be able 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.
When XP doesn't work (and its disadvantages)
XP doesn't work for every software development company. Each company has a different structure and developers a different type of software, so a 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 a lot of 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 seldom 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 get 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 the 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 is not a substitute for thoughtful design, modeling, and software architecture.
- Constant involvement is a tough sell for your customer/client, as well as absence of knowing how much all is going to cost.
- Refactoring can be a time-waster. Refactoring is only beneficial for code that is 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.
However, the biggest problem with XP is that it's 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 different continents altogether, making XP impossible. Just to get an answer about some requirement, 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.
