What do you think?
Rate this book
EXTREME PROGRAMMING
Kent Beck's eXtreme Programming eXplained provides an intriguing high-level overview of the author's Extreme Programming (XP) software development methodology. Written for IS managers, project leaders, or programmers, this guide provides a glimpse at the principles behind XP and its potential advantages for small- to mid-size software development teams.
The book intends to describe what XP is, its guiding principles, and how it works. Simply written, the book avoids case studies and concrete details in demonstrating the efficacy of XP. Instead, it demonstrates how XP relies on simplicity, unit testing, programming in pairs, communal ownership of code, and customer input on software to motivate code improvement during the development process. As the author notes, these principles are not new, but when they're combined their synergy fosters a new and arguably better way to build and maintain software. Throughout the book, the author presents and explains these principles, such as "rapid feedback" and "play to win," which form the basis of XP.
Generally speaking, XP changes the way programmers work. The book is good at delineating new roles for programmers and managers who Beck calls "coaches." The most striking characteristic of XP is that programmers work in pairs, and that testing is an intrinsic part of the coding process. In a later section, the author even shows where XP works and where it doesn't and offers suggestions for migrating teams and organizations over to the XP process.
In the afterword, the author recounts the experiences that led him to develop and refine XP, an insightful section that should inspire any organization to adopt XP. This book serves as a useful introduction to the philosophy and practice of XP for the manager or programmer who wants a potentially better way to build software. --Richard Dragan
Topics covered: Extreme Programming (XP) software methodology, principles, XP team roles, facilities design, testing, refactoring, the XP software lifecycle, and adopting XP.
240 pages, Paperback
First published October 5, 1999
380 people are currently reading
6142 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 218 reviews
September 20, 2019
While I've been aware of extreme programming (XP) for decades, I've never really subjected myself to a comprehensive review of its practices and techniques. As far as I could tell, it involves test-driven development, team co-location, pair programming, and possibly a few other practices.
In recent years, Agile software development has become such a washed-out term that it's no longer useful if you want to communicate how to develop software. Scrum is more well-defined, but I no longer feel aligned with its values of two-week sprints, daily stand-ups, sprint planning meetings, etc.
While I'm aware of the Agile Manifesto, I decided to read about XP from its inventor to see if there was something I'd missed all along. I'd heard that XP was a more prescriptive practice with clearly laid-out steps. Not that I wish to work within a rigid system, but sometimes, constraints liberate, and it can be enlightening to learn from the experience of others.
It's possible that XP started out as a more non-negotiable set of rules about what to do and not to do, but in this, the second edition of the book, there's few absolutes left. Kent Beck discusses the philosophy and principles of XP, as well as some practices that he recommends, but nothing is mandatory. That makes much sense, but also exposes XP to the risk that people might adopt it for show, like 'Scrum-but'.
The book contains much sensible advice, but it's from 2005, and there's little that's new. The exception is chapter 14, Designing: The Value of Time, which is essentially pure gold. I found myself cheering the text, playing close attention to every nuance, and writing down useful quotes. That chapter made reading the book worthwhile to me, but it isn't enough to pull my rating up to four stars. It does, however, ensure a solid three-star rating.
In recent years, Agile software development has become such a washed-out term that it's no longer useful if you want to communicate how to develop software. Scrum is more well-defined, but I no longer feel aligned with its values of two-week sprints, daily stand-ups, sprint planning meetings, etc.
While I'm aware of the Agile Manifesto, I decided to read about XP from its inventor to see if there was something I'd missed all along. I'd heard that XP was a more prescriptive practice with clearly laid-out steps. Not that I wish to work within a rigid system, but sometimes, constraints liberate, and it can be enlightening to learn from the experience of others.
It's possible that XP started out as a more non-negotiable set of rules about what to do and not to do, but in this, the second edition of the book, there's few absolutes left. Kent Beck discusses the philosophy and principles of XP, as well as some practices that he recommends, but nothing is mandatory. That makes much sense, but also exposes XP to the risk that people might adopt it for show, like 'Scrum-but'.
The book contains much sensible advice, but it's from 2005, and there's little that's new. The exception is chapter 14, Designing: The Value of Time, which is essentially pure gold. I found myself cheering the text, playing close attention to every nuance, and writing down useful quotes. That chapter made reading the book worthwhile to me, but it isn't enough to pull my rating up to four stars. It does, however, ensure a solid three-star rating.
September 10, 2016
An explanation of the extreme programming methodology. The main thesis of the book is that it does not make sense to try and predict things that can't be predicted. Instead, Kent Beck proposes a methodology that embraces changes instead of fighting them or trying to predict everything into detail. The main points of the methodology are:
- pair programming - all code is written in pairs (on a single computer); this leads to a higher quality of code being written, as the person who is not writing has actually time to think about what's going on; also, the pair should change often so that people can learn from each other and everyone has at least basic familiarity with each part of the code,
- flexible planning - always do what is most important at the time, pick your goals every day; the customer should be on the team to help guide the decisions,
- design for change - do not treat any part of the project (including the specification) as fixed, always be ready to change them when necessary,
- code (and tests) are the documentation - or at least the only documentation that is up to date; write them in such way that they can be easily used as such,
- unit testing - automated testing of everything is essential for delivering working code (and also serves as a documentation of the code)
While you don't have to agree with this approach as a whole or with some parts of it or it might not work in your environment for some reason. But you should read the book anyway if only to broaden your views and perhaps find inspiration to try new things.
- pair programming - all code is written in pairs (on a single computer); this leads to a higher quality of code being written, as the person who is not writing has actually time to think about what's going on; also, the pair should change often so that people can learn from each other and everyone has at least basic familiarity with each part of the code,
- flexible planning - always do what is most important at the time, pick your goals every day; the customer should be on the team to help guide the decisions,
- design for change - do not treat any part of the project (including the specification) as fixed, always be ready to change them when necessary,
- code (and tests) are the documentation - or at least the only documentation that is up to date; write them in such way that they can be easily used as such,
- unit testing - automated testing of everything is essential for delivering working code (and also serves as a documentation of the code)
While you don't have to agree with this approach as a whole or with some parts of it or it might not work in your environment for some reason. But you should read the book anyway if only to broaden your views and perhaps find inspiration to try new things.
October 30, 2019
I staretd reading it after a lot of recommendations but it wasn't gone up to the standards. Maybe it's just me, but I was expecting more.
August 1, 2014
If you want to learn the principles of XP, this is THE book. If you want to learn the practice of XP, there are better alternatives.
The ideas and motivation of XP are explained clearly and concisely. It's a short read, but fairly convincing. However, if you learn better from examples, this book does not have enough real world stories to really see XP in action.
The book is full of great quotes:
XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.
Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn't change, because change is going to happen; the problem, rather, is our inability to cope with change.
No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a garden
As Will Rogers said, “It ain't what you don't know that gets you in trouble. It's what you know that ain't so.”
If members of a team don't care about each other and what they are doing, XP won't work. If members of a team don't care about a project, nothing can save it.
In software development, “perfect” is a verb, not an adjective.
Quality isn't a purely economic factor. People need to do work they are proud of.
Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn't give you time to drink your coffee.
Put new software into production every night. Any gap between what is on a programmer's desk and what is in production is a risk. A programmer out of sync with the deployed software risks making decisions without getting accurate feedback about those decisions.
Silence is the sound of risk piling up.
He picked a powerful metaphor for his teaching, Scientific Management. When picking descriptive names, it helps to pick a name whose opposite is unappealing. Who could possibly be for “unscientific” management?
Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales. No one in engineering is responsible for quality.
The ideas and motivation of XP are explained clearly and concisely. It's a short read, but fairly convincing. However, if you learn better from examples, this book does not have enough real world stories to really see XP in action.
The book is full of great quotes:
XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.
Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn't change, because change is going to happen; the problem, rather, is our inability to cope with change.
No book of gardening, however complete, makes you a gardener. First you have to garden, then join the community of gardeners, then teach others to garden. Then you are a garden
As Will Rogers said, “It ain't what you don't know that gets you in trouble. It's what you know that ain't so.”
If members of a team don't care about each other and what they are doing, XP won't work. If members of a team don't care about a project, nothing can save it.
In software development, “perfect” is a verb, not an adjective.
Quality isn't a purely economic factor. People need to do work they are proud of.
Automatically build the whole system and run all of the tests in ten minutes. A build that takes longer than ten minutes will be used much less often, missing the opportunity for feedback. A shorter build doesn't give you time to drink your coffee.
Put new software into production every night. Any gap between what is on a programmer's desk and what is in production is a risk. A programmer out of sync with the deployed software risks making decisions without getting accurate feedback about those decisions.
Silence is the sound of risk piling up.
He picked a powerful metaphor for his teaching, Scientific Management. When picking descriptive names, it helps to pick a name whose opposite is unappealing. Who could possibly be for “unscientific” management?
Having a separate quality department sends the message that quality is exactly as important to engineering as marketing or sales. No one in engineering is responsible for quality.
November 13, 2016
Kent Beck is one of the most influential person in our industry. Patterns, refactoring, TDD, XP. Our industry would never be like what we know it without him. His pragmatic view is awesome, his experience is tremendous.
But I think that this book is just a good one. Just good, but not great. Kent is concise, focused and very deep. But I think he left too much on the reader. Maybe this is just my personal perspective, but I felt that I've missed design consideration from the first edition of this book.
Even that the book seemed just OK, I still will recommend it to every modern developer: this was super interesting journey in the past, to see how agile was born and how it's different from what we see and use today.
But I think that this book is just a good one. Just good, but not great. Kent is concise, focused and very deep. But I think he left too much on the reader. Maybe this is just my personal perspective, but I felt that I've missed design consideration from the first edition of this book.
Even that the book seemed just OK, I still will recommend it to every modern developer: this was super interesting journey in the past, to see how agile was born and how it's different from what we see and use today.
June 10, 2021
Yeah yeah, I know what you're going to say. Trust me I've had it from everyone who's seem me reading my copy of Extreme Programming Explained. Let me just clear this up: extreme programming is nothing like this ...
On the contrary, the process Kent Beck describes as extreme programming sounds like one of the most relaxing, sustainable and rewarding software development frameworks I've heard of. It is of course an ideal, but it seems realistic to be able to approach this ideal. I feel confident in this because I have experienced most of the necessary parts in different teams I've worked in.
To set the maturity bar extremely high, Beck doesn't begin with quick fixes to turn your software team around but starts with the kinds of values extreme programming is designed around. These values sound quite inoffensive and obvious: communication, simplicity, feedback, courage, respect. However, as any software developer or indeed anybody working in an office setting can agree, they are often forgotten or even consciously foregone. Beck suggests that a company has to embody these values or at somebody high up in the organisation has to want them embodied, in order for extreme programming to be a good fit.
Since values are very wibbly wobbly timey wimey and the bridge from values to practices can tenuous, Beck then sets out some principles to act as a bridge. These include also very inoffensive ideals such as: improvement, quality and reflection. However there were a few here that I found interesting. An example was the principle of 'flow'. Not the positive psychology kind of flow but a more abstract principle of ensuring that all software tasks should happen in one continuous motion without big discrete events. Another example, which I am already using by name at work, is 'baby steps'. Always take the smallest step possible to get to an outcome, in order for a high-quality whole to emerge.
Lastly following on from the principles is the largest section of the book: practices. These are far less idealistic steps to follow, probably with high appeal to the average engineer. However I would recommend any reader to reflect harder on the values than the practices, since they really form the backbone about why you would even want to follow the practices. Like if you don't care about communication and feedback, why would you pair programme? If you don't care about humanity or economics, why would you plan?
So besides test-driven development and pair programming, is there anything extra that's interesting? Firstly, Beck advocates for the time spent on design and adding value to be proportional. This sounds incredibly controversial for most software teams, but even from a business perspective I can see the argument. Another interesting practice is the root-cause analysis. Beck believes that with test-driven development the rate of defects in a software system will tend towards zero. So when a defect does occur, it doesn't just need to be fixed but also the cause of the defect needs to be fixed. A developer is encouraged to go a layer deeper to keep the defect rate low.
Overall I would recommend it to any developer who realises their job expands to more than just engineering. It is a set of practices for delivering value through software and for feeling great as a team while making software. Of course not every set of practices fits every context, but you should speculate anyway with regards to your own.
On the contrary, the process Kent Beck describes as extreme programming sounds like one of the most relaxing, sustainable and rewarding software development frameworks I've heard of. It is of course an ideal, but it seems realistic to be able to approach this ideal. I feel confident in this because I have experienced most of the necessary parts in different teams I've worked in.
To set the maturity bar extremely high, Beck doesn't begin with quick fixes to turn your software team around but starts with the kinds of values extreme programming is designed around. These values sound quite inoffensive and obvious: communication, simplicity, feedback, courage, respect. However, as any software developer or indeed anybody working in an office setting can agree, they are often forgotten or even consciously foregone. Beck suggests that a company has to embody these values or at somebody high up in the organisation has to want them embodied, in order for extreme programming to be a good fit.
Since values are very wibbly wobbly timey wimey and the bridge from values to practices can tenuous, Beck then sets out some principles to act as a bridge. These include also very inoffensive ideals such as: improvement, quality and reflection. However there were a few here that I found interesting. An example was the principle of 'flow'. Not the positive psychology kind of flow but a more abstract principle of ensuring that all software tasks should happen in one continuous motion without big discrete events. Another example, which I am already using by name at work, is 'baby steps'. Always take the smallest step possible to get to an outcome, in order for a high-quality whole to emerge.
Lastly following on from the principles is the largest section of the book: practices. These are far less idealistic steps to follow, probably with high appeal to the average engineer. However I would recommend any reader to reflect harder on the values than the practices, since they really form the backbone about why you would even want to follow the practices. Like if you don't care about communication and feedback, why would you pair programme? If you don't care about humanity or economics, why would you plan?
So besides test-driven development and pair programming, is there anything extra that's interesting? Firstly, Beck advocates for the time spent on design and adding value to be proportional. This sounds incredibly controversial for most software teams, but even from a business perspective I can see the argument. Another interesting practice is the root-cause analysis. Beck believes that with test-driven development the rate of defects in a software system will tend towards zero. So when a defect does occur, it doesn't just need to be fixed but also the cause of the defect needs to be fixed. A developer is encouraged to go a layer deeper to keep the defect rate low.
Overall I would recommend it to any developer who realises their job expands to more than just engineering. It is a set of practices for delivering value through software and for feeling great as a team while making software. Of course not every set of practices fits every context, but you should speculate anyway with regards to your own.
November 9, 2018
eXtreme Programming 2.0.
Actually, it's a complete rewrite of the first edition.
Actually, it's more like reinventing XP. Kent Beck is adjusting XP so we can benefit from his additional five years of XP experience. The first XP was squarely aimed at programmers; this new version should appeal to everyone involved in software development. The practices have been updated: some have been dropped, some are new. He recommends a much more gradual introduction if you want to move to XP, instead of the strong push from the first edition. He is also much more explicit about ways to customize XP to your circumstances.
Like Tom DeMarco's Peopleware and Alistair Cockburn's Agile Software Development, he reminds us that software is written by people. But he goes further, showing how XP brings back humanity to those who practice it.
Still a quick read and very inspirational. Plus, the bibliography at the end has many of my favorite authors and titles.
Actually, it's a complete rewrite of the first edition.
Actually, it's more like reinventing XP. Kent Beck is adjusting XP so we can benefit from his additional five years of XP experience. The first XP was squarely aimed at programmers; this new version should appeal to everyone involved in software development. The practices have been updated: some have been dropped, some are new. He recommends a much more gradual introduction if you want to move to XP, instead of the strong push from the first edition. He is also much more explicit about ways to customize XP to your circumstances.
Like Tom DeMarco's Peopleware and Alistair Cockburn's Agile Software Development, he reminds us that software is written by people. But he goes further, showing how XP brings back humanity to those who practice it.
Still a quick read and very inspirational. Plus, the bibliography at the end has many of my favorite authors and titles.
March 8, 2021
It was pretty ok.
April 15, 2018
subjectively: i feel like this book is straight to the point, without absolutist claims. It provides a nice thinking framework, and clarifies the knowledge i may already had by putting it into a clear framing.
Objectively, to me it provided
- some very clear (pain)points which can be frequently missed in how the team works and communicates, on how it applies some processes, and how it does its work on a daily basis
- a very good preliminary toolbox from which I can draw ideas on how to handle all kinds of situations within the team during the development process. Of course this toolbox is not complete, but the purpose of it is to provide a basic set of concepts from which I can derive my own approaches
Objectively, to me it provided
- some very clear (pain)points which can be frequently missed in how the team works and communicates, on how it applies some processes, and how it does its work on a daily basis
- a very good preliminary toolbox from which I can draw ideas on how to handle all kinds of situations within the team during the development process. Of course this toolbox is not complete, but the purpose of it is to provide a basic set of concepts from which I can derive my own approaches
April 27, 2017
As a novice programmer who hasn't had much experience working in a team, much less working in a team that practices XP, I think this book introduced me to a lot of things on real team project management as a programmer as well as a manager, as much as the book does in introducing me to XP itself.
The explanations are really easy to understand and sometimes fun, especially in the early chapters. I really like the steering-a-car analogy on how a development process should be done.
However, again as a novice programmer, I believe I could not fully make sense of a lot of the practices, or the rationale behind the practices, for I find it hard to relate to any practical experience in a software team. Probably best right before or during practice as an software engineer that adopts XP.
Lastly, despite my last comment, I think it is still a recommended read for beginner programmers, let alone experience programmers, that are adopting XP. I realized as I went through my reading that "Hey, I think now I finally have something substantial to ask about during interview, you know, like continuous integration, how long is the iteration, does your team adopt XP and how is like if you do etc."
The explanations are really easy to understand and sometimes fun, especially in the early chapters. I really like the steering-a-car analogy on how a development process should be done.
However, again as a novice programmer, I believe I could not fully make sense of a lot of the practices, or the rationale behind the practices, for I find it hard to relate to any practical experience in a software team. Probably best right before or during practice as an software engineer that adopts XP.
Lastly, despite my last comment, I think it is still a recommended read for beginner programmers, let alone experience programmers, that are adopting XP. I realized as I went through my reading that "Hey, I think now I finally have something substantial to ask about during interview, you know, like continuous integration, how long is the iteration, does your team adopt XP and how is like if you do etc."
December 16, 2022
This book is almost twenty years old and still its' ideas, values and principles are so powerful.
Do not plan too far into the future, focus on what it is important now. Be close with your customers, gather feedback and adapt. Have high standards, write tests, focus on quality. Create a culture with flat hierarchies where knowledge is shared across the team; everybody elevates and complements the other. Never stop learning.
I would not implement everything from the book, but the author also has a YouTube talk (Extreme Programming 20 years later by Kent Beck), where he revoked some of his writings for example on estimation. He said just don't bother with that and that's what I thought while reading. :D
The field of programming is ever changing and fast paced and still there are pieces like that, that hold so many good thoughts and practices which we can implement into our daily work 20 years later.
While I honestly cannot completely categorize the way we work, I would say we adopt a lot of practices described in this book and I think it helps!
Try it, if you are curious on how to deliver good software fast without having a lot of meeting and management overhead and instead focusing on the part that is important: developing the things that are really important and bring value to the customer (like it is written in the Agile Manifesto).
PS: here is the YouTube talk ((https://www.youtube.com/watch?v=cGuTm...))
Do not plan too far into the future, focus on what it is important now. Be close with your customers, gather feedback and adapt. Have high standards, write tests, focus on quality. Create a culture with flat hierarchies where knowledge is shared across the team; everybody elevates and complements the other. Never stop learning.
I would not implement everything from the book, but the author also has a YouTube talk (Extreme Programming 20 years later by Kent Beck), where he revoked some of his writings for example on estimation. He said just don't bother with that and that's what I thought while reading. :D
The field of programming is ever changing and fast paced and still there are pieces like that, that hold so many good thoughts and practices which we can implement into our daily work 20 years later.
While I honestly cannot completely categorize the way we work, I would say we adopt a lot of practices described in this book and I think it helps!
Try it, if you are curious on how to deliver good software fast without having a lot of meeting and management overhead and instead focusing on the part that is important: developing the things that are really important and bring value to the customer (like it is written in the Agile Manifesto).
PS: here is the YouTube talk ((https://www.youtube.com/watch?v=cGuTm...))
August 12, 2019
I decided to read this book because I was working with a team where "the usual" practices didn't seem to be helping in their context. I am so glad I did! So many nuggets of wisdom and new ideas to try, especially in the more technical space. I'm a Scrum Master, so there were some (very few) areas where Scrum/XP didn't really align, however, they seemed largely complementary. (Which isn't surprising seeing as both are founded on the Values and Principles of the Manifesto for Agile Software Development). This is a good one to read and also to keep on the shelf for future reference.
April 25, 2021
The book isn't revolutionary after two decades, however, it's a good sign there is hope for Software Development. Nowadays, the majority of XP's habits are in place. We leverage from those practices without even knowing their roots. If you are up with IT trends (principles), like Scrum, Agile, TDD, pair programming, you probably won't learn too much. On the other hand, it's good to know the history and how the Agile movement started.
For me, the most valuable thing was the catch the scientific approach and taking a journey from values to practices through a principles bridge with the author.
For me, the most valuable thing was the catch the scientific approach and taking a journey from values to practices through a principles bridge with the author.
February 4, 2018
The book is not "only for software engineers" or "a technical book" as some think, but a reflection on a full methodology. XP has remained as the technical complementary part of other so-called agile methodologies that obviate that code has to be built, but started with the intention of being complete.
After reading the book now I see how Kent thought about planning, estimate, prioritise and maintain the pace, always focusing on the coding part of the equation, but taking into account the business part.
Some reflections are still good, but time has passed and it has to be read with its context, as a reference of a way of thinking from 1999 (or 2004, the second edition).
Only reading the commented Bibliography, to understand the sources for Kent thoughts, resulted interesting: even "The Princess Bride" is there!
After reading the book now I see how Kent thought about planning, estimate, prioritise and maintain the pace, always focusing on the coding part of the equation, but taking into account the business part.
Some reflections are still good, but time has passed and it has to be read with its context, as a reference of a way of thinking from 1999 (or 2004, the second edition).
Only reading the commented Bibliography, to understand the sources for Kent thoughts, resulted interesting: even "The Princess Bride" is there!
February 1, 2023
I honestly don’t know what to add to this book. It’s a great piece about what principles go behind successful software development. You can apply these practices one by one, but when looking at the whole book, it’s genuinely about being open, honest, and working together.
This book is still relevant today. Many books have already been written about these ideas in the last 20 years, but the author has some great stories to back him up.
The best metaphor for software development in my opportunity is at the beginning of the book, where the author compares software development to driving a car.
Great book
This book is still relevant today. Many books have already been written about these ideas in the last 20 years, but the author has some great stories to back him up.
The best metaphor for software development in my opportunity is at the beginning of the book, where the author compares software development to driving a car.
Great book
October 5, 2009
Although I didn't always agree with the author's conclusions, I loved this book. The five-star score is a rating of the book, not XP itself. The book does a wonderful job of tieing practices back to principles and values. XP practices and the reasoning behind them are explained in enough detail that you can work them into your teams starting now. I think this is the book's main goal, and it has been reached.
The book is not without flaws. The author makes a number of assumptions about people and projects that I do not believe to be universally true, and these assumptions lead to suggestions that I truly believe would put many teams down the wrong path. In some cases I've seen the same values, goals, and principles lead to practices that the book disdains, yet they had a better end results than XP's methods ever could have. Every one of these disagreements I had with the book boils down to a miscalculation of personality, communication, and motivation. I strongly suspect the author assumes that his particular social style is the "right" way to be and the best way to work, and as a result he occasionally fails to see the validity of alternative implementations of the same principles.
In spite of the complaints I still think this book deserves five stars. I got a lot of great ideas for new things to try. Even when a particular suggestion didn't click for me, the principles behind the practice gave me a context in which to come up with ideas of my own. In my opinion that's where the book's greatest value lies, in its philosophy that encompasses all of your process choices and gives you a context in which to evaluate what you could do differently and why. I won't be implementing XP in its canonical form - I wasn't converted - but the solid framework in which XP is couched has given me a good basis to think about improvements my own teams can make.
The book is not without flaws. The author makes a number of assumptions about people and projects that I do not believe to be universally true, and these assumptions lead to suggestions that I truly believe would put many teams down the wrong path. In some cases I've seen the same values, goals, and principles lead to practices that the book disdains, yet they had a better end results than XP's methods ever could have. Every one of these disagreements I had with the book boils down to a miscalculation of personality, communication, and motivation. I strongly suspect the author assumes that his particular social style is the "right" way to be and the best way to work, and as a result he occasionally fails to see the validity of alternative implementations of the same principles.
In spite of the complaints I still think this book deserves five stars. I got a lot of great ideas for new things to try. Even when a particular suggestion didn't click for me, the principles behind the practice gave me a context in which to come up with ideas of my own. In my opinion that's where the book's greatest value lies, in its philosophy that encompasses all of your process choices and gives you a context in which to evaluate what you could do differently and why. I won't be implementing XP in its canonical form - I wasn't converted - but the solid framework in which XP is couched has given me a good basis to think about improvements my own teams can make.
March 31, 2016
Great read if you want to be a developer that solves business, organization and software problems.
Being able to notice, analyze and solve problems outside the code base is part of software engineering.
"Extreme Programming Explained" is the right book for anyone to learn how to do that.
I found every chapter immensely useful although I may have read most of the values and principles in other books or blog posts. The XP scaling and roles is something that the book explained better.
The book chapters length may feel a bit too short if you're used to longer and far stretched chapters, but that's not really a bad thing.
The one thing that I find lacking is the closure in the Section 2. The conclusion felt rushed and almost didn't feel like pointing you in the right direction.
A cheatsheet like closure e.g "here are X,Y,Z things you should try and apply now with your team". I wished the book steered the reader a little bit more, but that's just me.
Being able to notice, analyze and solve problems outside the code base is part of software engineering.
"Extreme Programming Explained" is the right book for anyone to learn how to do that.
I found every chapter immensely useful although I may have read most of the values and principles in other books or blog posts. The XP scaling and roles is something that the book explained better.
The book chapters length may feel a bit too short if you're used to longer and far stretched chapters, but that's not really a bad thing.
The one thing that I find lacking is the closure in the Section 2. The conclusion felt rushed and almost didn't feel like pointing you in the right direction.
A cheatsheet like closure e.g "here are X,Y,Z things you should try and apply now with your team". I wished the book steered the reader a little bit more, but that's just me.
January 1, 2011
A very good read that introduces the topic of Extreme Programming extremely well.
This book does a great job of conveying the practices, principles and values of XP to its target audience. Its style should be familiar to those who have read Kent Beck's other books - it gets right to the point, doesn't repeat itself very much and is split into chapters where they make sense without any artificial bloating of chapters to make them 'the right size' (several chapters are only 2 sides, for example).
It all adds up to a very engaging book that acts as a great introduction to the Extreme Programming ethos. The only reason I gave it 4 stars instead of 5 is because I felt it didn't quite match up to the same level as TDD: By Example, but it is still an essential read for anyone interested in improving their development skills and wants a starting point.
This book does a great job of conveying the practices, principles and values of XP to its target audience. Its style should be familiar to those who have read Kent Beck's other books - it gets right to the point, doesn't repeat itself very much and is split into chapters where they make sense without any artificial bloating of chapters to make them 'the right size' (several chapters are only 2 sides, for example).
It all adds up to a very engaging book that acts as a great introduction to the Extreme Programming ethos. The only reason I gave it 4 stars instead of 5 is because I felt it didn't quite match up to the same level as TDD: By Example, but it is still an essential read for anyone interested in improving their development skills and wants a starting point.
April 20, 2023
First, it's a classic book that has had an enormous influence on the IT industry. Although the content has been digested and processed with tons of articles, videos or books, I feel that there is still a value in reading the original paper.
However, I must admit that I didn't get anything special, nothing I would describe as being innovative or enlighting. Both, the technical methods of XP (TDD, pair programming, continuous delivery) and non-technical ones (including business people in the software lifecycle etc.) are actually covered and explained better in other books. If I read it 15 years ago then I would probably be more satisfied :)
In the end, this is not a must-read for experienced developers who are familiar with Agile and XP technical concepts. Nevertheless, once again, this is a classic position - I appreciate how much it has given to the IT world.
However, I must admit that I didn't get anything special, nothing I would describe as being innovative or enlighting. Both, the technical methods of XP (TDD, pair programming, continuous delivery) and non-technical ones (including business people in the software lifecycle etc.) are actually covered and explained better in other books. If I read it 15 years ago then I would probably be more satisfied :)
In the end, this is not a must-read for experienced developers who are familiar with Agile and XP technical concepts. Nevertheless, once again, this is a classic position - I appreciate how much it has given to the IT world.
November 3, 2018
Very good book that is explaining the main principles, practices and values of Extreme Programming (XP) that makes the software development faster and brings excellence and good quality to the end product. The examples are simple, the book is easy for reading and is inspiring. The main core in the process of XP are pair programming, test driven development, incremental design, deployment and planning, work separated in development cycles and customer interaction. The team aim to achieve perfect communication, regular feedback, simplicity in the development work, respect and value each other. It's worth reading in my modest opinion.
July 4, 2024
This was probably a big deal when it came out but I graduated in 2015 and every job I’ve had follows most of this stuff already. It’s talked about like something that’ll blow your mind once you grok it but I think the whole industry has already grokked this book. It did help me understand why no one understands what product we’re building and how it mostly doesn’t matter because it’s ‘agile’ to iterate and as long as it’s better this year than last year we’re all gonna keep our jobs.
August 10, 2009
Interesting read even if you don't know anything about coding. Don't let the lack of quotes belie this book. There was nothing that jumped off the page but it was all good. Short and too the point too.
Quotes:
"One way a test can pay off is when a test works that you didn't expect to work. Then you better go find out why it works, because the code is smarter than you are."
Quotes:
"One way a test can pay off is when a test works that you didn't expect to work. Then you better go find out why it works, because the code is smarter than you are."
December 19, 2012
I read parts of this many years ago and I decided to give it a thorough read-through. Even though it's the first edition, it's still interesting. Agile (mostly Scrum) has definitely developed further from these ideas but the basics are here. And there are plenty of good reminders too. Gets a bit hand-wavy at times but I can overlook that.
February 24, 2018
This book describes many believes in software development I hold.
In the world of silver bullets, buzzwords and markitecture, this book has become more relevant than never. A fundamentally important book on how software should be delivered – values, principles, and practices.
It not only covers technical aspects of XP but also often forgotten ones, like courage and respect.
In the world of silver bullets, buzzwords and markitecture, this book has become more relevant than never. A fundamentally important book on how software should be delivered – values, principles, and practices.
It not only covers technical aspects of XP but also often forgotten ones, like courage and respect.
March 13, 2018
I read it all, mainly because I had to. I really could care less about all of the anecdotes the author shared throughout the book. Kent, not to sound mean or anything, but no one cares about the fact that you had a Polish jelly donut around Easter 1996.
December 11, 2013
An easy read and a very influential book as so many of Kent Beck's ideas. I recently found a nice blog about this book as well : http://blog.8thlight.com/uncle-bob/20...
September 23, 2021
Easy to read, with smaller chapters.
With very practical and applicable points.
With very practical and applicable points.
December 22, 2023
Good but also simplified without much depth and knew and practiced 90% of it already. If it could better teach these lessons that come with experience, that would be an awesome book. Too easy for someone to read this, parrot things without really getting it, and then end up in a state where words like “agile” don’t actually mean anything and are actually potentially a red flag for inexperienced/incompetence haha.
Cool to see that what was effective then is still effective now, although sort of sad to see that the common team dynamic problems still are the exacts same problems today at top sw crafting skill companies like Apple and Google. I would have hoped things had improved more with these lessons making there way further into the program management mainstream and the way companies get technical work done, but they really have not. But also inspiring to improve and make it better. I enjoyed the section on that, “improving yourself and influencing others”. But if it still sounds like the high priority great idea and this was 30 years ago, maybe the delivery of that idea is the problem. Not sure. Part of it for sure is the human experience: it’s never worth it to improve something technical in the short term if it costs trust and harms the relationship for getting future things done. The book did a great job talking about that aspect and how most every problem is ultimately a people problem if you ask enough whys.
I’m very curious in how to better deliver these learnings and why it really hasn’t caught on as much as it should. Most teams I work with are still divided in the way they get work done, they don’t test their code and waste everyone’s time, many people haven’t ever tried TDD, many people see pair programming as a 50% reduction in productivity, and so much time is spent talking and upfront planning the best solution when in that same time an MVP of two of the solutions could have been built to bring meat to a real discussion.
There’s a great section (ch 14) about the time value of money in this book, something everyone knows, but the degree of articulation and granularity and simple solutions for various common topologies of time being wasted was exceptionally well written. I’m sure I will be using one of those diagrams to ground a point in a future meeting this year 🤓
If you’re familiar with Toyota lean manufacturing, pair programming, TDD, 5 whys, and everything is ultimately a people problem not a technical problem, then you’ll also not gain much from this book.
Still, it was fun to read, especially given the time period and how much has solidified since then, at least for people who have read the agile manifesto and practiced it, read the lean startup and practiced it, learned TDD and practiced it, have experienced the net win of pair programming, etc.
I was expecting more absolutist opinionated advice which I tend to enjoy as it makes it easier to really get a feel for the advantages as well as being easier to critique, especially like it when opinionated advice comes with the author’s added critique of when the simplified advice breaks down. The book was well balanced and not absolutist to my surprise, especially given the “extreme programming” name.
I was also expecting more depth. The TDD section I was expecting to be more insightful, and it was barely a page long, which could only make sense to someone who already gets it. From everyone I’ve taught that went from knowing nothing about TDD to realizing how cool and useful it is, including myself, the process took weeks of learning and practicing. Learning and improving my testing/agile/lean skills, most notably TDD being an easy way to execute on that, has been my not so secret weapon for my rise in productivity, and I’ve had a great time sharing and helping others undergo that same epiphany.
The main reason I picked this up was because of how meaningless terms like agile, fail fast, MVP, and lean have become, being used optically to label practices that are far away from the original label when it comes to execution. I was curious to see the original XP, and it too is spot on!
Overall it is a solid book, but I question its value in teaching people who don’t already know the concepts. It’s too easy to read this then start repeating the buzz words as if the individual and team’s end execution has really changed and grown for the better. Hard to pick up these lessons without living them, and short of that having more depth in the sections that details someone else living them. But still a great reflection guide that might give enough to go learn in depth if the problem and solution resonate.
Cool to see that what was effective then is still effective now, although sort of sad to see that the common team dynamic problems still are the exacts same problems today at top sw crafting skill companies like Apple and Google. I would have hoped things had improved more with these lessons making there way further into the program management mainstream and the way companies get technical work done, but they really have not. But also inspiring to improve and make it better. I enjoyed the section on that, “improving yourself and influencing others”. But if it still sounds like the high priority great idea and this was 30 years ago, maybe the delivery of that idea is the problem. Not sure. Part of it for sure is the human experience: it’s never worth it to improve something technical in the short term if it costs trust and harms the relationship for getting future things done. The book did a great job talking about that aspect and how most every problem is ultimately a people problem if you ask enough whys.
I’m very curious in how to better deliver these learnings and why it really hasn’t caught on as much as it should. Most teams I work with are still divided in the way they get work done, they don’t test their code and waste everyone’s time, many people haven’t ever tried TDD, many people see pair programming as a 50% reduction in productivity, and so much time is spent talking and upfront planning the best solution when in that same time an MVP of two of the solutions could have been built to bring meat to a real discussion.
There’s a great section (ch 14) about the time value of money in this book, something everyone knows, but the degree of articulation and granularity and simple solutions for various common topologies of time being wasted was exceptionally well written. I’m sure I will be using one of those diagrams to ground a point in a future meeting this year 🤓
If you’re familiar with Toyota lean manufacturing, pair programming, TDD, 5 whys, and everything is ultimately a people problem not a technical problem, then you’ll also not gain much from this book.
Still, it was fun to read, especially given the time period and how much has solidified since then, at least for people who have read the agile manifesto and practiced it, read the lean startup and practiced it, learned TDD and practiced it, have experienced the net win of pair programming, etc.
I was expecting more absolutist opinionated advice which I tend to enjoy as it makes it easier to really get a feel for the advantages as well as being easier to critique, especially like it when opinionated advice comes with the author’s added critique of when the simplified advice breaks down. The book was well balanced and not absolutist to my surprise, especially given the “extreme programming” name.
I was also expecting more depth. The TDD section I was expecting to be more insightful, and it was barely a page long, which could only make sense to someone who already gets it. From everyone I’ve taught that went from knowing nothing about TDD to realizing how cool and useful it is, including myself, the process took weeks of learning and practicing. Learning and improving my testing/agile/lean skills, most notably TDD being an easy way to execute on that, has been my not so secret weapon for my rise in productivity, and I’ve had a great time sharing and helping others undergo that same epiphany.
The main reason I picked this up was because of how meaningless terms like agile, fail fast, MVP, and lean have become, being used optically to label practices that are far away from the original label when it comes to execution. I was curious to see the original XP, and it too is spot on!
Overall it is a solid book, but I question its value in teaching people who don’t already know the concepts. It’s too easy to read this then start repeating the buzz words as if the individual and team’s end execution has really changed and grown for the better. Hard to pick up these lessons without living them, and short of that having more depth in the sections that details someone else living them. But still a great reflection guide that might give enough to go learn in depth if the problem and solution resonate.
This entire review has been hidden because of spoilers.
February 23, 2018
I am an engineering manager who has been working on converting my team to more agile methodologies in the last year. In reading about agile, Extreme Programming also is frequently mentioned, so I thought it behooved me to go to the source and learn what XP is actually about.
On the plus side, the book does a good job on clearly laying out the values, principles, and practices of Extreme Programming. I feel that I have a more clear idea in my head of what is meant by this term, and how it relates to an entire world-view of how software development should happen in the ideal.
Fundamentally I don't disagree that many of the practices he presents do in fact lead to more efficient and better (as in, cleaner code, faster deployment, and fewer bugs) software development. I also agree with the basic values and principles that he lays out. In fact, I agree quite strongly with some of them, such as the fact that software development is ultimately about constant change, that communication is crucial, and that programmers are people and we have to recognize their humanity.
However, I have two major issues with the book. The first is in the tone. Kent Beck comes across as extremely dogmatic: everything he presents is with the tone of "this is the only best way, period." For example, at one point he writes: "Write stories on index cards and put the cards on a prominent wall. Many teams try to skip this step and go straight to a computerized version of the stories. I've never seen this work." My immediate reaction to this implication that it is impossible to succeed with *only* computerized stories is "well, *** you, my team only has computerized stories and it's working just fine."
The lack of allowance for any sort of variation or nuance in how processes are applied made me feel resistant to his ideas overall, even if there are some things I could use. I also feel like this dogmatic tone is at odds with the principle of "humanity." One of the things that is implied to me in recognizing the humanity of the engineers is that they should therefore have agency over their work and the processes they are involved in. The larger implication is that there is no such thing as a one-size-fits-all process because people are different. This idea is not addressed or discussed at all in the book.
My second issue with the book is the lack of concrete examples. I felt this the most in the chapters on test-driven development and design. I felt that the ideas presented were high-level and vague (with completely useless, vague, hand-drawn graphs to accompany them) and I had a hard time connecting them to the actual real projects I work on and seeing how they could apply.
It is possible that I am not the primary target audience for this book. I get the impression that it developed out of large corporations where software development is sluggish, has many issues, and is geared towards custom software and meeting customer requests. I have no doubt that bringing in this approach to those types of places could make a huge difference. However, I work at a web-based product company, with professional visual designers, high-quality QA, and overall already efficient processes. I do not plan to try to introduce any specific changes to my team as a result of reading this book, but rather just continue down the path we are on of exploring agile approaches and defining together effective processes unique to our needs.
On the plus side, the book does a good job on clearly laying out the values, principles, and practices of Extreme Programming. I feel that I have a more clear idea in my head of what is meant by this term, and how it relates to an entire world-view of how software development should happen in the ideal.
Fundamentally I don't disagree that many of the practices he presents do in fact lead to more efficient and better (as in, cleaner code, faster deployment, and fewer bugs) software development. I also agree with the basic values and principles that he lays out. In fact, I agree quite strongly with some of them, such as the fact that software development is ultimately about constant change, that communication is crucial, and that programmers are people and we have to recognize their humanity.
However, I have two major issues with the book. The first is in the tone. Kent Beck comes across as extremely dogmatic: everything he presents is with the tone of "this is the only best way, period." For example, at one point he writes: "Write stories on index cards and put the cards on a prominent wall. Many teams try to skip this step and go straight to a computerized version of the stories. I've never seen this work." My immediate reaction to this implication that it is impossible to succeed with *only* computerized stories is "well, *** you, my team only has computerized stories and it's working just fine."
The lack of allowance for any sort of variation or nuance in how processes are applied made me feel resistant to his ideas overall, even if there are some things I could use. I also feel like this dogmatic tone is at odds with the principle of "humanity." One of the things that is implied to me in recognizing the humanity of the engineers is that they should therefore have agency over their work and the processes they are involved in. The larger implication is that there is no such thing as a one-size-fits-all process because people are different. This idea is not addressed or discussed at all in the book.
My second issue with the book is the lack of concrete examples. I felt this the most in the chapters on test-driven development and design. I felt that the ideas presented were high-level and vague (with completely useless, vague, hand-drawn graphs to accompany them) and I had a hard time connecting them to the actual real projects I work on and seeing how they could apply.
It is possible that I am not the primary target audience for this book. I get the impression that it developed out of large corporations where software development is sluggish, has many issues, and is geared towards custom software and meeting customer requests. I have no doubt that bringing in this approach to those types of places could make a huge difference. However, I work at a web-based product company, with professional visual designers, high-quality QA, and overall already efficient processes. I do not plan to try to introduce any specific changes to my team as a result of reading this book, but rather just continue down the path we are on of exploring agile approaches and defining together effective processes unique to our needs.
February 5, 2020
This book helped change the way that software development is generally practiced, from the leadership to the programmers, from the business to the design. It is important to note that this book has been delivered in two very different editions. The first edition in 1999 set the direction while the second edition in 2005 brought insight out of several years of experience in an updated text.
What’s so “extreme” about Extreme Programming? First, it advocates a practice called “pair programming” – programming in teams of two and sharing the burden of writing and debugging the code. Second, it advocates a heavy use of automated testing and writing those tests at the beginning of a new feature, not at the end. It also advocates the practice of continual integration – making many small deployments instead of one big deployment. This practice, 15 years after publication, is adhered to in most development shops.
What I like most about this book is that it flattens the landscape. Instead of having hierarchies and bureaucracies, it brings responsibility to everyone on the team. This is especially true in my industry, medical research. It’s in touch with the evolving dynamics of the workplace. Careers should not be a race to the top but a continual development of skill. Lean production techniques, concepts of continual improvement, and shared responsibility are all consulted in suggesting how to handle the business of software. The purported results are substantially reduced software defects (i.e., improved quality) and slightly reduced development time (i.e., reduced cost).
While these ideas were cutting-edge in 1999 (and still not widely practiced in 2005), they are expected in most software shops in 2020. Thus, this book is to be consulted as a vestige of history rather than a set of new ideas to implement. It’s still interesting, relevant, and inspirational because of the revolution it sparked. I read this book as a way to think through the practice of test-driven development. It helped me with that practice and continues to catalogue what good software development consists of. Interestingly, these skills have developed into Agile practices and more recent DevOps trends. Writing about these topics should now be consulted for state-of-the-art.
What’s so “extreme” about Extreme Programming? First, it advocates a practice called “pair programming” – programming in teams of two and sharing the burden of writing and debugging the code. Second, it advocates a heavy use of automated testing and writing those tests at the beginning of a new feature, not at the end. It also advocates the practice of continual integration – making many small deployments instead of one big deployment. This practice, 15 years after publication, is adhered to in most development shops.
What I like most about this book is that it flattens the landscape. Instead of having hierarchies and bureaucracies, it brings responsibility to everyone on the team. This is especially true in my industry, medical research. It’s in touch with the evolving dynamics of the workplace. Careers should not be a race to the top but a continual development of skill. Lean production techniques, concepts of continual improvement, and shared responsibility are all consulted in suggesting how to handle the business of software. The purported results are substantially reduced software defects (i.e., improved quality) and slightly reduced development time (i.e., reduced cost).
While these ideas were cutting-edge in 1999 (and still not widely practiced in 2005), they are expected in most software shops in 2020. Thus, this book is to be consulted as a vestige of history rather than a set of new ideas to implement. It’s still interesting, relevant, and inspirational because of the revolution it sparked. I read this book as a way to think through the practice of test-driven development. It helped me with that practice and continues to catalogue what good software development consists of. Interestingly, these skills have developed into Agile practices and more recent DevOps trends. Writing about these topics should now be consulted for state-of-the-art.
Displaying 1 - 30 of 218 reviews