Extreme Programming

For a long time software was built the way a building is built. Finish the design, construct what the design says, inspect the result at the end. One assumption sat underneath that order: the later you change something, the more it costs. Once the foundation is poured, moving a column means starting over, so blocking changes was the sensible response.

Process grew in that direction. Requirements documents got signed off, changes needed a written request, and requests needed an approval meeting. On paper the machinery worked. In practice the conversation stalled in the same place every time. Six months into a project the customer would describe a screen differently, engineering would answer that this was signed off in March, and the customer would answer that nobody knew in March how this would turn out. Neither side is wrong, and when the exchange ends the screen is still wrong.

Integration day showed the same problem wearing a different face. After two months of separate work, merging everything surfaced dozens of places where two people had edited the same file in different directions. Fixing those merges quietly broke features that had worked fine a month earlier, and since verification meant a human clicking through the product, finding the break took three days. A team that lives through this a few times starts shipping less often. It ships less because shipping is risky, and each release grows larger, which makes it riskier. A team that batches two months of work has 200 suspects when something breaks; a team that ships a day of work has three. The same mistake costs wildly different amounts of time to track down.

Extreme Programming cuts that loop from the other end. Instead of preventing change, it lowers what change costs. Once editing code is cheap and safe, there is no reason left to forbid it. The method, assembled in the late 1990s, took the habits that were already considered good practice and asked teams to stop doing them occasionally and start doing them always. If review helps, review while the code is written. If integration helps, integrate several times a day. If tests help, write them before the feature. The word extreme describes the dial on those habits, not the hours people work. Doing a good thing sometimes and doing it without exception differ in kind, not degree: merging once every two months takes a full day and gets postponed, while merging three times a day takes five minutes and stops being something to avoid.

This is also why the method sits in the framework branch of ways of working rather than somewhere else. Scrum, in the same branch, fixes a cycle length and names the meetings and roles inside it. Kanban governs flow on a board and caps how many items can be open at once. Neither says anything about how code gets written. Extreme Programming fills exactly that gap, which is why teams often run Scrum for the rhythm of the cycle and take their engineering habits from here. The root underneath both is agile.

Everything grouped under Extreme Programming belongs to one branch: practices. A practice is a concrete behavior the method asks a team to perform daily. The method defines about a dozen of them, and three live elsewhere on this map — writing tests before the feature, covered under test-driven development (TDD); merging everyone's work several times a day with automated checks behind it, covered under continuous integration; and reshaping existing code without changing what it does, covered under refactoring. The five collected here govern the relationship between people and code. The first three decide who writes it together, the last two decide how much gets built and at what pace. Read in that order they answer two different questions a team faces every morning: who is at the keyboard, and how much of the future to build today.

1. Pair programming — two people write code at one screen. One types while the other watches direction, and they swap often. Review happens while the code is written instead of afterward, so fewer problems survive until merge time.
2. Mob programming — the whole team works on one task at one screen. It is pair programming scaled up to everybody. Nobody does this all day every day; teams use it for a day at a time when opening an area nobody understands yet, or when touching something like billing where a mistake is hard to reverse.
3. Collective code ownership — anyone may change any code. There is no rule that only Theo touches the billing code. The point is to remove the state where one person's vacation stops all work in one area, and it needs evidence that anyone can safely edit anything, which is why it travels paired with automated tests.
4. Simple design — build only what today needs. Rather than laying down an abstraction now because five payment methods might arrive later, build the structure when the second one actually shows up. Structures built for requirements that never arrive are usually wrong, and they stay wrong while the next reader still has to understand them. The practice is easiest to misapply as an excuse for careless code, so the standard reading of simple is the smallest design that still passes every test and repeats nothing.
5. Sustainable pace — work at an intensity a team can hold for years. Around 40 hours a week is the reference point, and a heavier week gets paid back the following week. The rule exists because the concentration the other practices demand does not survive on top of chronic overtime.

The five are not a menu. Collective ownership only holds up when there is evidence that any edit is safe, and tests plus frequent merging are what produce that evidence. Simple design works the same way: a team only resists building ahead when it trusts that changing things later is cheap. Pairing and mobbing keep any area from becoming one person's private knowledge, which is what makes shared ownership possible. Adopt half and you rarely get half the benefit — usually you get none. This is where teams that map the interlock before choosing an order split from teams that pick whatever is most visible. The first group lays down tests and frequent merging, then stacks the rest on top. The second group switches on the most labor-intensive practice first and runs out of energy fastest.

"I'll pair with Theo on this one. When someone writes the billing path alone, we end up tearing it apart in review anyway."

Better to have the second pair of eyes during the writing than after it.

"We're only running two of the XP practices. Turning on shared ownership with no tests just means nobody dares touch anyone else's code."

Pulling practices out one at a time strips away the support the others were providing.

"Let's not cover this week with overtime. It eats next week's pace too."

Hours bought by pushing now come back as a larger loss in the next cycle.

Pagedeck first adopted the method inside its billing module. Two months in a row, customers who switched plans mid-cycle were charged the wrong prorated amount, and both times the customer noticed before the team did. What Theo proposed was not another review gate but a change in how that code got written. Billing code would always be written by two people, any function that calculates an amount would get its test written first, and work in progress would be merged before the end of the day.

The first three weeks were slow. Two people producing what one used to produce cut visible progress, and Mia watched planned items slip for two sprints straight. What changed by the fourth month was the time after each release. Releases touching billing used to consume two days of support handling, and those two days disappeared. For the rest of that year, exactly one ticket came in about an incorrect charge.

Today the practice covers two areas at Pagedeck: billing and permissions. It does not cover copy changes or experimental features that go up on Monday and come down on Friday. Theo's test is a single question — if this is wrong, does a customer lose money or data? When the answer is yes, two people at one screen is worth the cost. When it is no, that cost belongs somewhere else. Mia keeps the same boundary in planning: work inside those two areas gets estimated with pairing assumed, and work outside them does not, so the two kinds of item stop competing for the same slot in a sprint.

The most common misreading comes from the name: people hear a method that pushes working hours to the limit. The word extreme sits right there in front, and a description built on short cycles and frequent releases makes the picture look plausible. But what the method pushes to the limit is habits, not people. Always review and always integrate is the demand — not always be working. One of the five practices is sustainable pace, and a stretch of weeks past 40 hours counts as a problem to fix rather than a sign of commitment. Left uncorrected, the misreading kills the discussion before it starts. Engineers hear a proposal to make overtime official policy, and managers occasionally use it as exactly that. In teams where the second version happens, people leave within six months, and for everyone still there the name becomes hard to raise again.

Treating the practices as a menu is the other frequent mistake. Taking the three or four that suit your team out of a dozen sounds reasonable. Pair programming is what teams reach for first, because it is visible, needs no tooling, and can start tomorrow. But these practices function as safety equipment for one another, so pulling one out leaves whatever it was holding up unsupported. A team with no automated tests that merges once a day and switches on pairing pays the full price of two people at one screen and gets slightly faster review in return. Merge conflicts still pile up, and there is still no way to know whether today's fix broke something else. The ending is usually the same shape: three months later a retrospective concludes that this does not fit our team, the memory of paying double is the part that sticks, and the rest of the practices get closed off along with it. The order was backward. What belongs first is a test suite that runs on its own and the habit of merging often. Those two demand little extra daily time from anyone while building the floor the other practices stand on. Everything else only pays once that floor exists. The same order shows up in how teams describe the change afterward: the ones that started with tests talk about releases getting boring, while the ones that started with pairing talk about how tired everyone was. A team that cannot switch on everything at once gets more out of spending two quarters laying the floor than out of switching on the visible practice first and abandoning it by month three.