Earlier this year, a colleague and I had the honor of being guest lecturers at The University of Waterloo. The topic was Test Driven Design. Looking back, I hope the class learned as much as I did giving the lecture.
We hear this all the time in college, but participation really does make or break a lecture. There were two sections meeting the day we lectured. The first had a slight delay in arriving, but also relied on a fixed presentation. We considered that the material was too lightweight, but not knowing how much TDD-exposure to expect from the students, we went with it.
The first lecture was mostly fine. There were some questions and responses from a few students, but no amazing revelations.
In the three hours between classes, we held true to our agile roots by retooling a bit. We added a mocking section to our FizzBuzz example, with the aim of letting the class choose their own adventure. When asked, the class unanimously wanted to move on to mocking instead of more FizzBuzz.
A Spark of Honesty
We went into the second section expecting a bit less participation than the first, hearing that this was a quiet class. Fortunately we got a spark from a student who declared that features don’t always ship, and writing tests for them is an unjustifiable waste of time.
Why was this exactly the spark we needed?
Because it actually happens with seasoned and new developers who are being introduced to TDD. By getting out a real criticism of the technique, we can address it out in the open. I relayed my experience, my colleague relayed his, and then the spark caught fire — a student in the back of the class shared her experience from a co-op.
Features changing are just a fact of life, and the benefits you’re going to get from writing tests are always worth it, in my experience.
All in all, the first lecture was one where we shared information about test driven design. By iterating on the materials before the second lecture, we were able to create an environment tailored to the people in the room. Always provide a fork.