What do you think?
Rate this book
Extreme Programming Explained: Embrace Change
“In this second edition of Extreme Programming Explained, Kent Beck organizes and presents five years’ worth of experiences, growth, and change revolving around XP. If you are seriously interested in understanding how you and your team can start down the path of improvement with XP, you must read this book.”
― Francesco Cirillo, Chief Executive Officer, XPLabs S.R.L. “The first edition of this book told us what XP was―it changed the way many of us think about software development. This second edition takes it farther and gives us a lot more of the ‘why’ of XP, the motivations and the principles behind the practices. This is great stuff. Armed with the ‘what’ and the ‘why,’ we can now all set out to confidently work on the ‘how’: how to run our projects better, and how to get agile techniques adopted in our organizations.”
― Dave Thomas, The Pragmatic Programmers LLC “This book is dynamite! It was revolutionary when it first appeared a few years ago, and this new edition is equally profound. For those who insist on cookbook checklists, there’s an excellent chapter on ‘primary practices,’ but I urge you to begin by truly contemplating the meaning of the opening sentence in the first chapter of Kent Beck’s book: ‘XP is about social change.’ You should do whatever it takes to ensure that every IT professional and every IT manager―all the way up to the CIO―has a copy of Extreme Programming Explained on his or her desk.”
― Ed Yourdon, author and consultant “XP is a powerful set of concepts for simplifying the process of software design, development, and testing. It is about minimalism and incrementalism, which are especially useful principles when tackling complex problems that require a balance of creativity and discipline.”
― Michael A. Cusumano, Professor, MIT Sloan School of Management, and author of The Business of Software “ Extreme Programming Explained is the work of a talented and passionate craftsman. Kent Beck has brought together a compelling collection of ideas about programming and management that deserves your full attention. My only beef is that our profession has gotten to a point where such common-sense ideas are labeled ‘extreme.’...”
― Lou Mazzucchelli, Fellow, Cutter Business Technology Council “If your organization is ready for a change in the way it develops software, there’s the slow incremental approach, fixing things one by one, or the fast track, jumping feet first into Extreme Programming. Do not be frightened by the name, it is not that extreme at all. It is mostly good old recipes and common sense, nicely integrated together, getting rid of all the fat that has accumulated over the years.”
― Philippe Kruchten, UBC, Vancouver, British Columbia “Sometimes revolutionaries get left behind as the movement they started takes on a life of its own. In this book, Kent Beck shows that he remains ahead of the curve, leading XP to its next level. Incorporating five years of feedback, this book takes a fresh look at what it takes to develop better software in less time and for less money. There are no silver bullets here, just a set of practical principles that, when used wisely, can lead to dramatic improvements in software development productivity.”
― Mary Poppendieck, author of Lean Software Development: An Agile Toolkit “Kent Beck has revised his classic book based on five more years of applying and teaching XP. He shows how the path to XP is both
― Francesco Cirillo, Chief Executive Officer, XPLabs S.R.L. “The first edition of this book told us what XP was―it changed the way many of us think about software development. This second edition takes it farther and gives us a lot more of the ‘why’ of XP, the motivations and the principles behind the practices. This is great stuff. Armed with the ‘what’ and the ‘why,’ we can now all set out to confidently work on the ‘how’: how to run our projects better, and how to get agile techniques adopted in our organizations.”
― Dave Thomas, The Pragmatic Programmers LLC “This book is dynamite! It was revolutionary when it first appeared a few years ago, and this new edition is equally profound. For those who insist on cookbook checklists, there’s an excellent chapter on ‘primary practices,’ but I urge you to begin by truly contemplating the meaning of the opening sentence in the first chapter of Kent Beck’s book: ‘XP is about social change.’ You should do whatever it takes to ensure that every IT professional and every IT manager―all the way up to the CIO―has a copy of Extreme Programming Explained on his or her desk.”
― Ed Yourdon, author and consultant “XP is a powerful set of concepts for simplifying the process of software design, development, and testing. It is about minimalism and incrementalism, which are especially useful principles when tackling complex problems that require a balance of creativity and discipline.”
― Michael A. Cusumano, Professor, MIT Sloan School of Management, and author of The Business of Software “ Extreme Programming Explained is the work of a talented and passionate craftsman. Kent Beck has brought together a compelling collection of ideas about programming and management that deserves your full attention. My only beef is that our profession has gotten to a point where such common-sense ideas are labeled ‘extreme.’...”
― Lou Mazzucchelli, Fellow, Cutter Business Technology Council “If your organization is ready for a change in the way it develops software, there’s the slow incremental approach, fixing things one by one, or the fast track, jumping feet first into Extreme Programming. Do not be frightened by the name, it is not that extreme at all. It is mostly good old recipes and common sense, nicely integrated together, getting rid of all the fat that has accumulated over the years.”
― Philippe Kruchten, UBC, Vancouver, British Columbia “Sometimes revolutionaries get left behind as the movement they started takes on a life of its own. In this book, Kent Beck shows that he remains ahead of the curve, leading XP to its next level. Incorporating five years of feedback, this book takes a fresh look at what it takes to develop better software in less time and for less money. There are no silver bullets here, just a set of practical principles that, when used wisely, can lead to dramatic improvements in software development productivity.”
― Mary Poppendieck, author of Lean Software Development: An Agile Toolkit “Kent Beck has revised his classic book based on five more years of applying and teaching XP. He shows how the path to XP is both
224 pages, Paperback
First published October 5, 1999
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 207 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.
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.
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.
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.
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.
October 7, 2021
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...
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.
May 12, 2020
Неплохая реклама экстремального программирования
Все как обычно встает в вопрос ожиданий. От книги с названием Extreme Programming Explained я ожидал довольно досконального объяснения техник экстремального программирования, описания как и почему они работают. Вместо этого я получил кучу информации формата "пишите сначала тесты потому что вы таким образом дизайните решение" или "занимайтесь парным программированием потому что это классно". Из интересного я здесь подчерпнул следующее:
- Если у вас назревает срач или большой аргумент можно залимитировать митинг 15 минутами и начать делать ХОТЬ ЧТО ТО. Это на самом деле не новость, я так с программированием делаю: когда не знаешь как назвать переменную назови ее как угодно, потом разберешься. В народе это известно как fail fast.
- Докапывания до источника косяка. Когда есть багуля, сначала мы пишем интеграционный тест который ее воспроизводит. Потом мы пишем юнит тест. Потом чиним багулю. Потом смотрим что прошел юнит тест, потом что интеграционный. Дальше мы начинаем последовательно спрашивать откуда эта багуля возникла, в формате "не подумал? а почему не подумал"
- TDD можно применять не только с юнит тестами. Можно начать делать фичу с написания Е2Е теста который будет заодно и спекой задачи служить. Мне сложно это представить в реальном мире (хотя бы потому что Е2Е нерабочее говно), но идея интересная.
Книгу можно посоветовать если вы никогда не слышали про экстремальное программирование, TDD, Pair Programming и вот это все. Мне сложно представить что такие есть в 2020 году, впрочем.
Все как обычно встает в вопрос ожиданий. От книги с названием Extreme Programming Explained я ожидал довольно досконального объяснения техник экстремального программирования, описания как и почему они работают. Вместо этого я получил кучу информации формата "пишите сначала тесты потому что вы таким образом дизайните решение" или "занимайтесь парным программированием потому что это классно". Из интересного я здесь подчерпнул следующее:
- Если у вас назревает срач или большой аргумент можно залимитировать митинг 15 минутами и начать делать ХОТЬ ЧТО ТО. Это на самом деле не новость, я так с программированием делаю: когда не знаешь как назвать переменную назови ее как угодно, потом разберешься. В народе это известно как fail fast.
- Докапывания до источника косяка. Когда есть багуля, сначала мы пишем интеграционный тест который ее воспроизводит. Потом мы пишем юнит тест. Потом чиним багулю. Потом смотрим что прошел юнит тест, потом что интеграционный. Дальше мы начинаем последовательно спрашивать откуда эта багуля возникла, в формате "не подумал? а почему не подумал"
- TDD можно применять не только с юнит тестами. Можно начать делать фичу с написания Е2Е теста который будет заодно и спекой задачи служить. Мне сложно это представить в реальном мире (хотя бы потому что Е2Е нерабочее говно), но идея интересная.
Книгу можно посоветовать если вы никогда не слышали про экстремальное программирование, TDD, Pair Programming и вот это все. Мне сложно представить что такие есть в 2020 году, впрочем.
March 17, 2022
This book describes the values of Extreme Programming, the principles that follow from these values, and the practices which align with these principles. It also expounds the philosophy of XP: where the ideas came from and why it works.
Beck describes a workplace which sounds almost utopian but is actually quite realistic and attainable. A fulfilling place to work that also fulfils the needs of the business.
XP largely focuses on how developers should work together, with less emphasis on the organisational structure or project/product management than e.g. Scrum. I think the ideas are sometimes less concrete but often more widely applicable than Scrum.
I think the ideas in this book are still highly relevant for helping us to build better software faster, more cheaply with fewer defects. Even if many of the practices are now fairly common, it’s useful to think about the justification for them so that we can practice them effectively. The values and principles of XP also help us to evaluate new practices.
In my experience, our industry is far from the ideal described in this book. I hope that reading this will help me to make some positive change. I’m sure if everyone read this and applied it, our industry would be far better off, for us developers, our employers and our customers.
Beck describes a workplace which sounds almost utopian but is actually quite realistic and attainable. A fulfilling place to work that also fulfils the needs of the business.
XP largely focuses on how developers should work together, with less emphasis on the organisational structure or project/product management than e.g. Scrum. I think the ideas are sometimes less concrete but often more widely applicable than Scrum.
I think the ideas in this book are still highly relevant for helping us to build better software faster, more cheaply with fewer defects. Even if many of the practices are now fairly common, it’s useful to think about the justification for them so that we can practice them effectively. The values and principles of XP also help us to evaluate new practices.
In my experience, our industry is far from the ideal described in this book. I hope that reading this will help me to make some positive change. I’m sure if everyone read this and applied it, our industry would be far better off, for us developers, our employers and our customers.
August 2, 2018
Great book about doing software development well. You may think it's a bit old, but its core concepts are still valuable. I believe it's still more suitable now then when it's released. Changes are happening in everywhere and every industries, embracing changes is the answer to our survival and growth.
Many people talk about Agile, CI/CD, Iteration, Incremental development ... but not sure they truly know path on doing those. Not sure they know about the values, principles and especially, the practises of doing those...
I've been involved with software development for about 10 years, with experiences in many area but still considered myself a noob. This book opens my eyes. It helps me answer questions above and lots more. It shows me that there's a way that you could build great software with happiness in a collaborative environment with collagues who willing to growth and learn with you.
Highly recommend to people who curious on building great software, managing dev team effectively, creating collaborative environment... Whoever cares about or involved with software development definitely should read this.
Many people talk about Agile, CI/CD, Iteration, Incremental development ... but not sure they truly know path on doing those. Not sure they know about the values, principles and especially, the practises of doing those...
I've been involved with software development for about 10 years, with experiences in many area but still considered myself a noob. This book opens my eyes. It helps me answer questions above and lots more. It shows me that there's a way that you could build great software with happiness in a collaborative environment with collagues who willing to growth and learn with you.
Highly recommend to people who curious on building great software, managing dev team effectively, creating collaborative environment... Whoever cares about or involved with software development definitely should read this.
Read
April 6, 2022Not rating the book because it was read for work as a reference book.
Personally, though, nothing about this book kept me engaged or awake. It worked wonders for getting me to sleep the last few weeks. But I am not one to get jazzed about development philosophy and methodology (another reason I’m not rating the book).
This second edition is now approaching twenty years old. Maybe it was extreme at the time, but many of the suggestions presented here were adopted by my team naturally based on their experience here and on other dev teams. That said, there were enough interesting tidbits here that I didn’t find it a waste of time, and I think some of the suggestions will prove beneficial for my team.
English major nitpick: Apparently the author followed the MLA guidelines for comma and semicolon use. The book uses semicolons between dependent clauses constantly; it’s insanely distracting. I don’t remember MLA being quite that idiotic in 2005, but maybe I chose to ignore that bit of MLA style and my profs did as well.
Personally, though, nothing about this book kept me engaged or awake. It worked wonders for getting me to sleep the last few weeks. But I am not one to get jazzed about development philosophy and methodology (another reason I’m not rating the book).
This second edition is now approaching twenty years old. Maybe it was extreme at the time, but many of the suggestions presented here were adopted by my team naturally based on their experience here and on other dev teams. That said, there were enough interesting tidbits here that I didn’t find it a waste of time, and I think some of the suggestions will prove beneficial for my team.
English major nitpick: Apparently the author followed the MLA guidelines for comma and semicolon use. The book uses semicolons between dependent clauses constantly; it’s insanely distracting. I don’t remember MLA being quite that idiotic in 2005, but maybe I chose to ignore that bit of MLA style and my profs did as well.
Displaying 1 - 30 of 207 reviews