How I explained TDD to a non-developer friend and got a job offer over tacos
A little while ago, the strangest thing happened. I was catching up with a lawyer friend. As we munched on tacos, I found myself trying to explain test driven development (TDD) to her. Easier said than done, seeing she’s had zero exposure to coding. But, there was a glass of water right in front of us… So I went from there.
A guy was sitting alone at the neighbouring table. He seemed to be listening in a bit too intently, which honestly, was kinda creeping me out. Finally, as we were getting the bill, he leaned over… and asked if I happened to be looking for a job.
😮 😮 😮 😮 I mean, thanks! But also… 😮
Apparently, he was very impressed with my TDD ramblings. Encouraged by such a positive review, I figured I should probably write down my water glass TDD analogy. Hence, this post.
The scenario
Back to the water glass. I asked my friend:
Imagine a restaurant owner wanted you to make them a thing people could drink from. How would you do it?
Option 1: The design cycle
You sketch a few ideas of something that holds water and has an opening to allow for drinking. You choose a few, show the client. Together you pick one. Then, you start thinking about details of designing and manufacturing, maybe you make a prototype and give it to people to test… at some point, you realise there’s an issue, e.g. the thing is too expensive to make. You go back to the drawing board and repeat the cycle until satisfied.
In this process you’re trying to solve every aspect of the design at once, so making small changes is hard. It can get overwhelming, stressful and frustrating. At some point you notice you can’t even keep track and are so confused about what you had and hadn’t considered in the latest iteration, you’re just crossing your fingers and hoping this version is fine.
You see, the problem seems trivial at first, but when you think about it a bit longer there’s a number of implied requirements. The thing should be waterproof. It should hold a good amount of liquid. It shouldn’t be too heavy. It should be easy to hold. It needs to be nice enough for a restaurant. Easy to wash. Easy to make. Probably cheap. Durable… And all you have to do? Hold the various requirements in your head, remembering to meet each one, while simultaneously letting your creative juices flow… Yeah, great.
Option 2: TDD
Consider instead this. You turn the requirements into “tests”: in essence a set of yes or no questions. You check in with the client to see if there’s anything you hadn’t thought about. For every test, you sketch/brainstorm something that will only pass that test. Needs to be waterproof? Ok, glass, bam. Needs to be easy to wash? Ok, simple shaped thing. Needs to be durable? Ok, make its walls thick. And so on and so on, until all your tests pass and a product emerges. You have a documented process of everything you’ve included in your design and you feel organised and in control.
Instead of being constantly replaced with new versions, your product has gradually evolved.
This being a creative endeavor, you may find you make a few different versions of the product (each passing all the tests) which you then show your client. Together you can refine and mix things up, all the while checking that your changes haven’t led to any test failing, thus knowing you still have a good, working product.
What’s even better, when the client comes back in 2 months to ask for another liquid container, this time geared towards hot drinks, you have a template of tests to start from. You just need to add the extra ones for heat-resistance. Despite the necessary heat-related changes, you can be confident your entire design is still ok: simply “run” all the tests to prove it.
Last but not least, when your role is taken over by someone else and they get asked to improve on the liquid container, they know exactly what you were thinking and can go from there. Or, if you get a team mate to help you in the design process it is easy to keep track of what has already been considered and what hasn’t.
Thoughts?
There you go — a general recap of how I explained TDD to my non-developer friend over tacos. I’ll be delighted if you let me know how what you think! Even more so, if you use it as an explanation tool yourself 😊
Or just leave a few claps, that’s cool too.
TDD in engineering
This strange story coincidentally ties in neatly with a topic I’ve lately been exploring and writing about here on Medium: bringing TDD to “traditional” engineering design. Check out:
