# Extreme Programming 1999->2026 > Source: > Published: 2026-08-18 06:01:00+00:00 One of my main struggles in the past year: I’m expected to mentor my engineers and help them adopt AI more effectively. But I first need to get better at it myself… This became much easier since my company integrated . It gives you (and your engineers) visibility into the work process: prompt quality, one-shot success, code quality, and skills+tools usage. [Weave](https://weaveos.com/?utm_source=manager-dot-dev&utm_campaign=xp-mid&utm_term=anton_zaides) So instead of a vague ‘we need to be more effective’, you can see exactly where your team can improve. The first time I read [Extreme Programming Explained](https://www.goodreads.com/book/show/1001606.eXtreme_Programming_eXplained_) by [Kent Beck](https://www.linkedin.com/in/kentbeck) was in 2021. I accumulated years of ‘scrum-fatigue’, and started feeling that [sprints were taking the joy out of building software](https://www.manager.dev/newsletter/why-sprints-are-broken). So I turned to my favorite way of solving problems - reading old books about the topic. Until that point, I thought that Extreme Programming was a code name for “Pair programming” and “TDD” ([test-driven development](https://en.wikipedia.org/wiki/Test-driven_development)), and was surprised to learn how much deeper it goes and how relevant it remained after 20+ years. It didn’t solve all my challenges, but it definitely helped. In the last few months, I started to feel a similar frustration. The pace is crazy, expectations are super high, but nobody really knows what a good software team looks like today. So I decided to go back to the roots and reread the book. No surprise here - it’s STILL very relevant! Almost every criticism I’ve read about the methodology focuses only on 2-3 practices (in 90% of the cases it’s TDD being shit and pair programming exhausting). That’s a big miss - XP has 5 values (all truer than ever), 14 principles (many great ones), and 26 practices (with some real gems, even if TDD and pair programming are not your cup of tea). ## So what IS extreme programming? In short, it is a methodology that aims to improve both the software we create and the lives of the engineering teams creating it. The name *extreme* comes from taking common-sense practices and dialing them up to extreme levels. For example: Reviewing code is good, so XP does it all the time by writing code together (pair programming). Fixing code structure is good, so in XP you clean and update the code every time you work on it instead of a big redesign. It's built on 3 layers: 5 **values** 14 **principles** 24 **practices** Here’s why Beck believes we need all 3: **Values** set your direction, but can be vague. Anyone can claim to “value communication” and yet produce a thousand-page document. Is that really communication? Maybe. But if a quick daily standup achieves better results, then the action, not the document, demonstrates the true value.**Practices**, in contrast, are concrete. You either show up to the standup, or you don't. Values bring meaning to practices, but practices hold values accountable. Yet values and practices are worlds apart. Values are universal - practices are context-specific. **Principles bridge this gap**, guiding us on how to live our values through actionable practices. It's like planting marigolds near strawberries. The practice is planting them together; the principle is companion planting - choosing plants that complement and protect each other. ## The 5 Values** ** #### 1. Communication *Most problems in teams [and companies] arise from poor communication. Always ask: What communication fixes this problem now, and prevents it in the future?* There is a huge, huge gap between the leadership of companies and the engineers actually doing the work. The result is unrealistic expectations, layoffs, frustration, and burnout. One of my biggest challenges today is [explaining to business people why building software is still hard](https://www.manager.dev/newsletter/cursing-the-day-lovable-was-born). How do you take an executive with AI-psychosis and make sure they don’t make bad decisions that affect your team? It’s also true the other way - there is A LOT of pressure on the leaders of companies, especially startups. The boards demand change and adaptation, and they react. The best leaders are the ones who can communicate a sensible vision to the whole company, and get people onboard, instead of on the defensive. #### 2. Simplicity *Ask yourself, “What is the simplest thing that could possibly work?” * As the cost of code writing decreases, it becomes tempting to create monstrous architectures. Often the LLMs themselves guide you that way, and during planning sessions your scope increases and increases. #### 3. Feedback *XP teams constantly seek rapid feedback. The sooner you know, the sooner you can adapt.* Truer than ever. #### 4. Courage *Alone, courage can be dangerous; paired with other values, it empowers you to speak truths (communication), discard failing solutions (simplicity), and seek concrete answers (feedback).* EMs today need quite a lot of courage: Do you have the courage to initiate 1:1 conversations with senior leaders and explain where you think they are wrong? Do you have the courage to fight when your engineers are faced with unreasonable requirements? And the hardest - do you have the courage to not just agree with the constant complaints from engineers, but push back and find solutions together? #### 5. Respect *Respect underpins the other values. Without genuine care among team members and about their work, XP simply won’t work.* The one I miss the most. It became too common to not respect engineers and our craft - coming especially from people who have never done the job themselves. Worse, I also see engineers not respecting each other. Experienced ones not having any patience to mentor or teach, and less experienced ones throwing huge PRs of AI-written code to review. ## The 3 critical Principles The 5 values are great but vague. Now, we go one level down - what principles do we need to follow to stay true to those values? There are 3 that I wish to see much more of: #### Humanity Part of the challenge of team software development is** balancing the needs of the individual with the needs of the team. **The team’s needs may meet your own long-term individual goals, so they are worth some amount of sacrifice. Always sacrificing your own needs for the team’s doesn’t work. Engineers are human beings, with families, lives, and dreams. I can understand a failing business doing layoffs, but every time a profitable and growing company does massive layoffs, I feel something is deeply broken. I love [IKEA’s story](http://linkedin.com/posts/noemikis_ikea-replaced-8500-customer-service-jobs-activity-7465378794267119616-_NdV) - re-skilling 8500 support employees after releasing a chatbot (they eventually did some layoffs in office roles, but at least they tried). We are all learning our new profession as we go. A bit more empathy and patience can go a long way. #### Mutual benefit Mutual benefit is **the most important XP principle** and the most difficult to adhere to. Every activity should benefit all concerned. Extensive internal documentation of software is an example of a practice that violates mutual benefit (*you need to suffer for the future person).* It seems that companies stopped valuing basic things like teamwork. Everyone is under a lot of stress to perform better, to adopt AI, so they don’t stop to consider the impact of their own actions (or they just care less). For example, writing lengthy Slack messages using Claude that are impossible for other humans to read. Or opening huge vibe-coded PRs and throwing them at someone else to review. The very basic ‘Do as you would be done by’. #### Quality Quality is not a control variable. Projects don’t go faster by accepting lower quality. They don’t go slower by demanding higher quality. Pushing quality higher often results in faster delivery, while lowering quality standards often results in later, less predictable delivery. Quality isn’t a purely economic factor. **People need to do work they are proud of.** The amount of AI-slop out there is astonishing (both written and coded). 5 months ago, Gergely Orosz [covered it extensively](https://newsletter.pragmaticengineer.com/p/are-ai-agents-actually-slowing-us) (requires a paid subscription to read): I wish we could return to building things we are proud of. ### The rest of the principles All still very relevant. Quoted directly from the book: **Failure:** Fail instead of talk**.** This is not intended to excuse failure when you really knew better. When you don’t know what to do though, risking failure can be the shortest, surest road to success.**Economics:** Somebody has to pay for all this. Software development that doesn’t acknowledge economics risks the hollow victory of a “technical success”. Make sure what you are doing has business value, meets business goals, and serves business needs.**Self-Similarity:** Try copying the structure of one solution into a new context, even at different scales.**Improvement:** In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.**Diversity:** Every team has conflict. The question is whether they resolve it productively. Diversity is expressed in the practice of Whole Team, where you bring together on the team people with a variety of skills and perspectives.**Reflection:** Good teams don’t just do their work, they think about how they are working and why they are working. They analyze why they succeeded or failed.**Flow:** Deploy smaller increments of value ever more frequently.**Opportunity:** To reach excellence, problems need to turn into opportunities for learning and improvement, not just survival.**Redundancy:** Defects are addressed in XP by many of the practices (pair programming, continuous integration, sitting together). Some of these practices are certainly redundant, catching some of the same defects. You can’t solve the defect problem with a single practice.**Baby Steps:** What’s the least you could do that is recognizably in the right direction?**Accepted Responsibility:** Responsibility cannot be assigned - it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren’t. ## 24 practices across 4 categories And now to the practical. What does it mean by humanity and mutual benefit? I broke down the list of practices into 4 categories: More critical than ever Controversial Common sense Are still relevant? ### More critical than ever **1. Whole Team ** *Include on the team people with all the skills and perspectives necessary for the project to succeed. This is really nothing more than the old idea of cross-functional teams.* As everyone can do 80% of everything, different functions fight over who is ‘not needed’ anymore. PMs, designers, engineers - all feel they are the one who could take over. The definition of roles and the boundaries between them might erode, but the skills that come with each of them won’t. Learning how to be a good engineer/designer/product manager takes **years**. If you just outsource it to Claude, you’ll get very mediocre results. **2. Team Continuity** *Keep effective teams together. There is a tendency in large organizations to abstract people to things, plug-compatible programming units. Value in software is created not just by what people know and do but also by their relationships and what they accomplish together. * *By mostly keeping teams together and yet encouraging a reasonable amount of rotation, the organization gets the benefits of both stable teams and of consistently spread knowledge and experience.* I really hate when engineers are called ‘resources’. “We need more resources for this project”. No, you need more people. You can’t just move engineers around expecting them to contribute like machines. As every EM knows, building an [excellent team](https://www.manager.dev/newsletter/okay-vs-excellent-engineering-teams) takes a lot of time and effort. Relationships matter, and doing reorgs and mixing everyone up has a huge impact on performance. **3. Shrinking Teams** *As a team grows in capability, keep its workload constant but gradually reduce its size. This frees people to form more teams. When the team has too few members, merge it with another too-small team.* But in most companies, it’s crazy for an EM to ‘give up’ on good engineers. You can always find more work to do, and you care less about the best thing for the company. There is a tough balance between team continuity and shrinking teams, so I would hesitate to break down existing high-performing teams - but I would definitely start smaller. **4. Energized Work** *Work only as many hours as you can be productive and only as many hours as you can sustain.* Oh man. It’s absurd that 0% of the efficiency we got from better LLMs translated into improvements in our own lives. In a logical world, you would expect that if you can do 2X more, you’ll at least get some of the benefit by working ~10% less. Nope. We are under more stress, working more hours, and trying to always catch up. **5. Real Customer Involvement** *Make people whose lives and business are affected by your system part of the team. Visionary customers can be part of quarterly and weekly planning. They can have a budget, a percentage of the available development capacity, to do with as they please. * *No customer at all, or a “proxy” for a real customer, leads to waste as you develop features that aren’t used.* In the last few weeks, my engineers and I started doing 1:1 calls with customers, making it weekly with some of them. It’s been an amazing experience. It’s not the same as having a customer as part of the team, but it’s much better than having 3 layers between us and the customers. ### Controversial Ok, now to the tricky practices. **1. Pair Programming** *Write all production programs with two people sitting at one machine. Pair programming is tiring but satisfying. Most programmers can’t pair for more than five or six hours in a day. After a week like that, they are ready for a relaxing weekend away from work.* The ‘all’ part is where XP ‘shines’. I’ve done some pair programming (especially with junior engineers), but I don’t think that ALL production code should be written like that. It’s exhausting. Especially with LLMs, people don’t like others looking at how they prompt, it’s very uncomfortable. Also, LLMs provide some of the benefit if used effectively. What worries me is that many engineers work solely with Claude, and the communication and learning inside the teams suffer. We need to find some middle ground here. **2. Code and Tests** **Only** *Maintain only the code and the tests as permanent artifacts. Generate other documents from the code and tests. Rely on social mechanisms to keep alive the important history of the project.* Here too, ONLY is the problem. Critics mention that no documentation and ‘word of mouth’ can be a disaster for many projects and companies. We can see it with LLMs - we still need md files, skills and rules, and not just let it run on your codebase and figure out the same things all over again. 3. **Incremental Design ** *Invest in the design of the system every day. Strive to make the design of the system an excellent fit for the needs of the system that day. When your understanding of the best possible design leaps forward, work gradually but persistently to bring the design back into alignment with your understanding.* The extreme part here is not to do thorough design upfront, to not waste your time. With LLMs, it’s way easier to do proper design - the challenge is just to scope it down and not be tempted to implement huge monsters needlessly. 4. **Test-First Programming** *Write a failing automated test before changing any code.* This one I’m not sure about. I haven’t tried it with LLMs myself, and I’ve read conflicting testimonials. I do know that it’s very hard to make sure LLMs write good tests (and not change them just to make them green). ### Common sense There are 7 pretty standard practices: **Single Code Base**: There is only one code stream. You can develop in a temporary branch, but never let it live longer than a few hours.** Daily Deployment:**Put new software into production every night.** Ten-Minute Build:**Automatically build the whole system and run all of the tests in ten minutes.** Continuous Integration:**Integrate and test changes after no more than a couple of hours.** Root-Cause Analysis**: Every time a defect is found after development, eliminate the defect and its cause. The goal is not just that this one defect won’t ever recur, but that the team will never make the same kind of mistake again.**Negotiated Scope Contract**: Write contracts for software development that fix time, costs, and quality but call for an ongoing negotiation of the precise scope of the system.**Shared Code:** Anyone on the team can improve any part of the system at any time. ### Still relevant? And 8 that were drastically changed (especially with remote work and LLMs): **Stories:** Plan using units of customer-visible functionality. “Handle five times the traffic with the same response time.” “Provide a two-click way for users to dial frequently used numbers.”**Weekly Cycle:** Plan work a week at a time.**Quarterly Cycle:** Plan work a quarter at a time. Once a quarter reflect on the team, the project, its progress, and its alignment with larger goals.**Slack:** In any plan, include some minor tasks that can be dropped if you get behind.**Incremental Deployment:** When replacing a legacy system, gradually take over its workload beginning very early in the project.**Sit Together**: Develop in an open space big enough for the whole team.** Informative Workspace:**An interested observer should be able to walk into the team space and get a general idea of how the project is going in fifteen seconds.**Pay-Per-Use:** Versus paying per version, or upgrade ## Final words Phew, that was a long one! Thanks for reading. As I’m trying to figure out the new practices, I like to think about how they stand up to the principles and values. For example, let’s take 2 from a [recent article](https://www.manager.dev/newsletter/3-things-top-1-teams-do-differently): No mandatory code reviews - this one is definitely about mutual benefit. Code review became a big and painful bottleneck, and most engineers don’t enjoy it. Maybe we can find ways to keep the quality high without overloading engineers. Parallelism - if it’s possible to do 4-5 projects in parallel, does it mean you HAVE to? What about humanity? How does it impact your well-being? How can we balance improvement and adjustment with staying humane? I’d really love to read any replies with thoughts on the topic! ## What I enjoyed reading this week Kent Beck is still actively writing! He has a [popular newsletter](https://newsletter.kentbeck.com/). Here are some of my favorite reads: [90% of My Skills Are Now Worth $0](https://newsletter.kentbeck.com/p/90-of-my-skills-are-now-worth-0). ...but the other 10% are worth 1000x.[The Bet On Juniors Just Got Better.](https://newsletter.kentbeck.com/p/the-bet-on-juniors-just-got-better)Why genies can make hiring juniors more profitable, & what you need to change to get there. You can also listen to a great [recent podcast episode](https://newsletter.pragmaticengineer.com/p/how-kent-beck-shapes-the-software) with him.