Explaining TDD to a non-techie

I was explaining what was different about the agile approach to software to a non-technical person the other day, and I chanced upon an explanation that I kind of liked. She did, too, as it made sense to her.

So, this is the explanation I used:

Imagine you have to write a 10 page paper. One way of doing it would be to sit down and outline the whole thing carefully, and then write it. You don’t look back at any of it — you just write. Any editing that’s necessary will be done at the end. You’re proceeding along like this, about 1/2 to your deadline, happy as can be, because you know what you’re going to write, you know where you are in terms of page count (never edited though!), and then the news comes. Your project is being canceled, and you need to deliver right now!

So, what do you have now? You have a great plan for writing the entire paper (your outline), but you have 1/2 of your paper written. You’ve introduced your subject, began developing a few details, but haven’t come close to any solutions or recommendations yet. And you have some unknown amount of editing to do before your paper is even readable. Not a good place to be.

Or…

You could rough out the topics you wanted to cover first. Then you could write your first sentence. That sentence could express the most important thought of the entire paper. Not a lot of detail, no depth, not a lot of value, but it at least makes sense and makes your most critical point. Then you could write your second sentence, re-examining the first sentence to make the two sentences work together. Then you could write a little more, editing as you go, and so on. When you’re writing a paper like this, the paper is always finished as far as the quality of the writing currently existing goes, it just might not explore the subject in enough depth. And as you go further into the project, you are adding depth and details to a complete paper, reorganizing as you go. And when that magic day comes when your project is canceled, you’re left with a complete paper, edited and ready to go.

That explanation made sense to her, and everybody left happy 🙂

— bab

 

Now playing: Rush – Exit…Stage Left – Xanadu

3 thoughts to “Explaining TDD to a non-techie”

  1. Interesting. This reminds me of how I was taught a memo should be written (things you learn in a tech writing class in college). The prof described it as you’re on a pay phone on a street corner and you’re on the phone with the recipient. There’s an 18-wheeler bearing down on you and you need to communicate the most important information quickly. So the subject line should capture the most critical information. Then, after you’ve done that, you realize that the truck is a little further away than you thought, so you write the first paragraph. You get the idea.

    I hadn’t thought of moving that idea to a paper, but then, most of the papers I’ve written were in academia, not for the business world.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.