Explaining TDD to your baker

When we present Test-Driven Development and its benefits, we often encounter resistance. This is normal. TDD challenges people's mental models about what testing means. Of course we explain them that Test in TDD has a very loose connexion with what people understands as the testing phase. Sadly enough, this argument doesn't lead us anywhere most of the times.

TDD is hard to explain if you don't show a TDD session on the spot. It's even harder if your audience doesn't code for a living. A typical situation: as an XP coach, I often have to answer to various stakeholders (middle managers, QA people, users' representants, etc.) why the coders' team is so (newly) hooked on "testing". How to explain them what we are doing, when they only have remote ideas about what automated tests and refactoring are? When they barely understands software making process? How can I be both precise and right to the point, careful that I am about not wasting their time and attention?

Let's turn the knobs to 11: pretend you are my baker and I'm trying to explain you my job as a TDD coder. You have no idea what it takes to build a piece of software, let alone what requirements are. How would I go?

Remember your time at school. Professors teach you stuff, and you take exams. Exams' primary function is to validate your knowledge about what the professors taught you. If you answer correctly to the exam's questions, you pass the exam and we know your teacher has done a good job. Now we all know too that passing the exam doesn't actually mean you know everything the professors taught you, but merely the subjects relating to the questions. This is why I used to hate exams -- I had to learn much more than what I had to know to answer the questions. If only I knew the questions first...

When I build software, I will get paid when the software does what my client wants -- that's the ideal, at least, but as my baker you don't have to care about the other, nastier cases. When you sell me bread, I agree to pay you because the bread you sell me meets some quality standards that I value. When I ship you a piece of software (let's say, to help you with your accounting), you agree to pay me because you value the quality standards my piece of software meets. Same thing. Well, actually not. While it is very easy to evaluate the quality of a piece of bread, it isn't quite so with a piece of software. Actually, evaluating the quality of a piece of software at shipment is as hard as evaluating the knowledge of a student after a semester of class. Why? Because in both cases you would have to do an enormous amount of verification to test the pupil's knowledge -- or the functional capacity of the shipped piece of software. You don't have time for that, so you write an exam with few questions, and you hope that the software will pass the examination. As many coders, I used to hate this moment, because I had to do so much work, just to pass the few checks you'll do. If only I knew in advance the checks you're about to make, my life would be easier, and I'd get paid the same, for much less work... On the other hand, if I only worked so that the few checks you'll make pass, the software would probably not be very useful.

So this is what I do. Before shipping the software, I demand you what checks you're about to make. Actually, I'll ask you even before starting building anything. I believe in fair business, so I'm okay with you telling me all the checks you'd like to make. You don't have to tell me all at the beginning, that's ok, as long as I have enough checks I can work on. In return, I'll provide you a tool that'll make it possible to you to perform all the checks you told me you'd like to make. Think of it as a standardized exam. If we standardize the protocol for asking and answering question, the pupil can answer many, many questions and an (automated) program can determine quickly what the pupil's level is. I'm turning myselft into a teacher, the software into a pupil. And you're becoming the stakeholder that has a vested interest into the pupil's knowledge. Since I know in advance specifically what the pupil must know, I just have write the exam first, teach them what they have to do to pass the exam and actually make them pass the exam to validate their knowledge. We call that testing the software, because it's just like a teacher testing their pupils.

That's it. You don't have to be my baker anymore, and I can do my coach talk again. When you have to explain what TDD is without showing a TDD session, don't attempt to change your audience's mental model about what testing is. Instead, make sure they use another mental model they already have -- testing in TDD is the same as school testing. And it's not so much about evaluating what the pupil knows that it's about evaluating the teacher's job.