Thanks Weave for supporting today’s article!
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 Weave. It gives you (and your engineers) visibility into the work process: prompt quality, one-shot success, code quality, and skills+tools usage.
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 by Kent Beck was in 2021. I accumulated years of ‘scrum-fatigue’, and started feeling that sprints were taking the joy out of building software. 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), 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
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. 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
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
Truer than ever.
4. Courage
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
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
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 - 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
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
The amount of AI-slop out there is astonishing (both written and coded). 5 months ago, Gergely Orosz covered it extensively (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
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
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 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
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
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
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
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
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
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
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:
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.
Here are some of my favorite reads:
90% of My Skills Are Now Worth $0. ...but the other 10% are worth 1000x.
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 with him.
