Jan. 7, 2011, 11:30 a.m.
posted by premod
Values, Principles, and Practices
What does it take to clearly communicate a new way of thinking about and doing software development? You can learn the basic techniques of gardening quickly from a book, but that doesn't make you a gardener. My friend Paul is a master gardener. I dig and plant and water and weed, but I am not a master gardener.
What are the differences between us? First, Paul knows more techniques than I do, and he's better at the techniques we both know. Technique matters because if you don't dig and plant things, you certainly aren't gardening. Call this level of knowledge and understanding practices, things you actually do. Practices are the things you do day-to-day. Specifying practices is useful because they are clear and objective. You either write a test before you change code or you don't. The practices are also useful because they give you a place to start. You can start writing tests before changing code, and gain benefit from doing so, long before you understand software development in a deeper way.
Even if I knew all the same gardening practices as Paul, I still wouldn't be a gardener. Paul has a highly developed sense of what is good and bad about gardening. He can look at a whole garden and get a gut sense of what's working and what isn't. Where I might be proud of my ability to correctly prune a branch, Paul might see that the whole tree should come out. He sees this not because he is a better pruner than I am, but because he has an overall sense of the forces at work in the garden. I have to work at what is simple and obvious to him.
Call this level of knowledge and understanding values. Values are the roots of the things we like and don't like in a situation. When a programmer says, "I don't want to estimate my tasks," he generally isn't talking about technique. He already estimates, but doesn't want to reveal what he really thinks for fear of providing a fixed point of judgement that will be used against him later. Better triple that estimate! Refusing to communicate estimates reveals something much deeper about how he sees the social forces in development. Perhaps he doesn't want to be accountable because he has been blamed unfairly in the past. In this case, the programmer values protection over communication. Values are the large-scale criteria we use to judge what we see, think, and do.
Making values explicit is important because without values, practices quickly become rote, activities performed for their own sake but lacking any purpose or direction. When I hear a programmer brush off a defect, I hear a failure of values, not technique. The defect itself might be a failure of technique, but the reluctance to learn from the defect shows that the programmer doesn't actually value learning and self-improvement as much as something else. This is not in the best interest of the program, the organization, or the programmer. Bringing values together with practices means that the programmer can perform a practice, in this case root-cause analysis, at effective times and for good reasons. Values bring purpose to practices.
Practices are evidence of values. Values are expressed at such a high level that I could do just about anything in the name of a value. "I wrote this one-thousand-page document because I value communication." Maybe yes and maybe no. If a fifteen minute conversation once a day would have communicated more effectively than producing the document, then the document doesn't show that I value communication. Communicating in the most effective way I can shows I value communication.
Practices are clear. Everyone knows if I've attended the morning standup meetings. Whether I really value communication is fuzzy. Whether I maintain practices that enhance communication is concrete. Just as values bring purpose to practices, practices bring accountability to values.
Values and practices are an ocean apart. Values are universal. Ideally, my values as I work are exactly the same as my values in the rest of my life. Practices, however, are intensely situated. If I want feedback about whether I'm doing a good job programming, continuously building and testing my software makes sense. If I want feedback when I'm changing a diaper, "continuously building and testing" is absurd. The forces involved in the two activities are just too different. To get feedback about my diapering job, I have to pick the baby up when I'm done to see if the diaper falls off. I can't test halfway through. The value "feedback" is expressed in very different forms in the two activities of diapering and programming.
Bridging the gap between values and practices are principles (see Figure). Principles are domain-specific guidelines for life. Paul's knowledge as a gardener exceeds mine at the level of principles as well. I might know to plant marigolds next to strawberries, but Paul understands the principle of companion planting where adjacent plants make up for each others' weaknesses. Marigolds naturally repel some of the bugs that eat strawberries. Planting them together is a practice. Companion planting is the principle. In this book I present the values, principles, and practices of XP.
This is the limit of what I can communicate in a book. It is a start but it isn't enough for you to master XP. 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 gardener.
So it is with XP. Reading this book won't make you an extreme programmer. That only comes with programming in the extreme style, participating in the community of people who share these values and at least some of your practices, and then sharing what you know with others.
You will benefit from studying and trying parts of XP. Learning to write tests before code is useful regardless of your values or the rest of your practices. However, there is as much difference between that and programming extreme as there is between my work in the garden and master gardening.