Extreme Programming Explained Quotes

“Responsibility cannot be assigned; it can only be accepted. If someone tries to give you responsibility, only you can decide if you are responsible or if you aren't.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Saying that programmers should just accomplish twice as much doesn't work. They can gain skills and effectiveness, but they cannot get more done on demand. More time at the desk does not equal increased productivity for creative work.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Given the choice between an extremely skilled loner and a competent-but-social programmer, XP teams consistently choose the more social candidate. The best interviewing technique is to have the candidate work with the team for a day. Pair programming provides an excellent test of technical and social skills.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“In software development, “perfect” is a verb, not an adjective. There is no perfect process. There is no perfect design. There are no perfect stories. You can, however, perfect your process, your design, and your stories.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“the XP strategy is "design always.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“McConnell writes, "In ten years the pendulum has swung from 'design everything' to 'design nothing.' But the alternative to BDUF [Big Design Up Front] isn't no design up front, it's a Little Design Up Front (LDUF) or Enough Design Up Front (ENUF)." This is a strawman argument. The alternative to designing before implementing is designing after implementing.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“The XP philosophy is to start where you are now and move towards the ideal. From where you are now, could you improve a little bit?”
― Kent Beck, Extreme Programming Explained: Embrace Change

“I've sat through far too many "crying in the beer" sessions where all the energy for change was dissipated in the intensity of the complaining. Once you see an idea for improvement that makes sense to you, do it.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“No matter the circumstance you can always improve. You can always start improving with yourself. You can always start improving today.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Software development is a game of insight, and insight comes to the prepared, rested, relaxed mind.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Sit Together Develop in an open space big enough for the whole team. Meet the need for privacy and "owned" space by having small private spaces nearby or by limiting work hours so team members can get their privacy needs met elsewhere.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Pair programmers: Keep each other on task. Brainstorm refinements to the system. Clarify ideas. Take initiative when their partner is stuck, thus lowering frustration. Hold each other accountable to the team's practices. Pairing”
― Kent Beck, Extreme Programming Explained: Embrace Change

“If there are forms of testing, like stress and load testing, that find defects after development is "complete," bring them into the development cycle. Run load and stress tests continuously and automatically.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Beta testing is a symptom of weak testing practices and poor communication with customers.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“If you have a month to plan a project in detail, spend it on four one-week iterations developing while you improve your estimates. If you have a week to plan a project, hold five one-day iterations. Feedback cycles give you information and the experience to make accurate estimates.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Without planning, we are individuals with haphazard connections and effectiveness. We are a team when we plan and work in harmony.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Change always starts at home. The only person you can actually change is yourself. No matter how functional or dysfunctional your organization, you can begin applying XP for yourself. Anyone on the team can begin changing his own behavior. Programmers can start writing tests first. Testers can automate their tests. Customers can write stories and set clear priorities. Executives can expect transparency. Dictating practices to a team destroys trust and creates resentment. Executives can encourage team responsibility and accountability. Whether the team produces these with XP, a better waterfall, or utter chaos is up to them. Using XP, teams can produce dramatic improvements in the areas of defects, estimation, and productivity.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Practices by themselves are barren. Unless given purpose by values, they become rote.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“One example is the concept that vulnerability is safety. The old habit of holding something back in order to be safe doesn’t really work. Holding back that last 20% of effort doesn’t protect me. When my project fails, the fact that I didn’t give my all doesn’t actually make me feel better. It doesn’t protect me from a sense of failure that I couldn’t make the project work. If I do my very best writing a program and people don’t like it, I can still feel justly good about myself. This attitude allows me to feel safe no matter the circumstance. If how I feel is based on an accurate read on whether I did my best, I can feel good about myself by doing my best.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Simplicity only makes sense in context. If I’m writing a parser with a team that understands parser generators, then using a parser generator is simple. If the team doesn’t know anything about parsing and the language is simple, a recursive descent parser is simpler.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“... no matter what the client says the problem is, it is always a people problem.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“If you want people to take your advice, you need to solve more problems than you create.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“It’s not my job to “manage” someone else’s expectations. It’s their job to manage their own expectations. It’s my job to do my best and to communicate clearly.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“The difference between what I think is valuable and what is really valuable creates waste.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“XP always keeps the system in deployable condition. Problems are not allowed to accumulate.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Incremental design—We invest in the design every day, but we have the additional constraint that we need to keep our APIs stable.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“There is only one code stream. You can develop in a temporary branch, but never let it live longer than a few hours. Multiple code streams are an enormous source of waste in software development. I fix a defect in the currently deployed software. Then I have to retrofit the fix to all the other deployed versions and the active development branch. Then you find that my fix broke something you were working on and you interrupt me to fix my fix. And on and on. There are legitimate reasons for having multiple versions of the source code active at one time. Sometimes, though, all that is at work is simple expedience, a micro-optimization taken without a view to the macro-consequences. If you have multiple code bases, put a plan in place for reducing them gradually. You can improve the build system to create several products from a single code base. You can move the variation into configuration files. Whatever you have to do, improve your process until you no longer need multiple versions of the code.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Folk wisdom in software development teaches that interfaces shouldn't be unduly influenced by implementations. Writing a test first is a concrete way to achieve this separation.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“Trust energizes participants. We feel good when things work smoothly. We need to be safe to experiment and make mistakes. We need testing to bring accountability to our experimentation so that we can be sure we are doing no harm.”
― Kent Beck, Extreme Programming Explained: Embrace Change

“However, most defects end up costing more than it would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business, and lost development time.”
― Kent Beck, Extreme Programming Explained: Embrace Change