I’ve been reading ‘Extreme Programming Explained – Embrace Change’, by Kent Beck (@kentbeck). If you’ve read it too, you’re probably thinking: “it’s an old book, you should’ve read it years ago”, and I agree. But if you didn’t I can only say: you should.
Even if you’re working on a software development team but are no programmer; XP Explained does not contain any (as in ‘zero’) code samples, and it’s really about how to develop software as a team.
And what better way is there to inspire than by listing up some favorite quotes.
XP is an opportunity […] to realize that maybe you’ve been fine all along and just hanging with the wrong crowd.
In software development, “perfect” is a verb, not an adjective.
Quality is not a control variable.
When you’re sick, respect yourself and the rest of your team by resting and getting well. […] Coming in sick doesn’t show commitment to work, because when you do you aren’t helping the team.
If you need to work on an idea alone, go do it. […] When you’re done exploring, bring the resulting idea, not the code, back to the team.
Planning is a form of necessary waste.
In any plan, include some tasks that can be dropped if you get behind.
You can count on gravity. Software has few such certainties. The ten-minute build is as close as we get.
Any guess about what parts of the system *need* […] to be tested introduces the risk of error.
Team programming isn’t a divide and conquer problem. It’s a divide, conquer, and integrate problem.
Test-first programming addresses many problems at once.
Change begins with awareness.
Trust your nose about what you need to improve next.
Maintain only the code and the tests as permanent artifacts.
Any gap between what is on a programmer’s desk and what is in production is a risk.
Planning in XP is an activity, not a phase.
A plan in XP is an example of what *could* happen, not a prediction of what *will* happen.
The hum of conversation is a sign of health. Silence is the sound of risk piling up.
Whichever units you use, hours or points, you will need to deal with the situation where actual results don’t match the plan.
In XP, testing is as important as programming.
Unfortunately, design in software has been shackled by metaphors from physical design activities.
Even if this is the umpteenth variation on a theme, there is always a better way to design the
The question is not *whether* to design, but *when* to design.
Far from “design nothing”, the XP strategy is “design always”.
I discover the need for design investment by spotting duplication.
If you are confronted with a big pile of mud, you can still begin improving the design.
Why is Taylorism important for software engineering? No one walks around a development shop with a clipboard and a stopwatch.
“Continuous” learning is not continuous.
So the question, “Is my team extreme?” There isn’t a binary answer.
And last but not least:
The key to XP is integrity, acting in harmony with my true values.