This week I was inspired by this intriguing post by my friend Ian Beatty. He talks about what it might be like to use a test-driven development process for teaching. Here’s the short version of what I got from that: In programming, you can write a test to check all the features you want. You can do this before you actually start to build the feature, and the test will let you know when you’re done. It’ll also help you determine whether new features break old features. It was suggested that we use it last summer when we started building the physics problem database for the global physics department, but I balked because I felt it would disrupt our workflow too much. Now I’m wondering if that was a mistake. How is that connected to teaching? Well, Ian talks about how maybe we could ask students to determine what they would like to be able to do with their soon-to-come physics knowledge (that would be the test), and when they can do it, they’ve learned the material.
When I read his post, I was intrigued, but then something happened this week that helped me see his points more clearly. I solved the Rubik’s cube.
That’s right, I solved it! A few different times in my life I’ve sat down and read the manual to memorize the moves necessary to complete the puzzle, but this time I solved it. And I’m pretty proud of that. This post is about how I did it (don’t worry, no gory details) and how that might connect to Ian’s ideas.
The basic plan I used was to make sure that if I achieved anything (like a completed side or a completed row), I would then do things that I knew wouldn’t screw that up. A few things were not useful, like spinning an unsolved row, but a lot were really interesting. I found I could move a middle block from the bottom row to the middle row with the right orientation if I just moved a top corner and then moved it back, hence maintaining the top side and the top row. For the middle row, that was pretty easy, but then I had to do the bottom row, which, if I got it solved, would automatically solve the bottom side.
To solve that bottom row, I just started doing the two main things I knew wouldn’t screw up the top side and top row (moving corners and switching middles). I’d move things, and then figure out how to fix the stuff I had already “solved.” When I’d get it back to the original situation, I’d check what I’d done to the bottom row. I found I could twist corner pieces, swap middle pieces, and flip middle pieces (all in the bottom row). Then I’d just write all that down. Then I’d look at the bottom to figure out what needed to be done, hoping that the tools I’d just developed would have the flexibility to do it. And, after an evening’s worth of work, it worked!
I do need to mention one caveat about this work: My son knows how to follow the manual algorithms to solve the cube. There were many times when I would ask him to do it so that I could then see when one of my “tools” did to the bottom row. This was very valuable.
So how is this test-driven development? Well, I set the test to be “make sure the top side and top row are left unchanged.” Then I’d monkey with stuff, always checking that test to discard useless maneuvers and write down useful ones. Then, I repeated the process with the new test: “make sure the middle row stays solved.” Note that I knew what the test meant and how to check it, even before I figured out useful ways to do pass it. That’s what test-driven development seems to be all about.
Now to the teaching analogy. Here it is, baldly: The solution to the cube is some physics content you want to teach. The algorithms in the manual are like the equations we hand out. Solving it my way is like the Modeling curriculum (where students are guided to investigate the models useful in describing motion). As for test-driven development, Ian suggests that the analogy would be that “making sure the top doesn’t get screwed up” becomes:
“design self-tests that will let you know when you can predict an object’s position at any future time, given the object’s initial position, velocity, and (constant) acceleration.”
A student should be able to understand what passing that test would look like even if she doesn’t know how to go about it.
Some hanging threads I’m not sure what to do with:
- My “solution” is much slower than my son’s, but I’m more proud of mine than he is (we’ve had that conversation). It would seem that the teaching analogy would like this. We would want our students to have pride in their self-derived approaches, even if we (secretly) know that there are more efficient ways to do the calculation.
- What’s the analogy to the fact that my son could “reset” the cube whenever I needed it, effectively handing me a finished product on demand that I could futz with?
- My son loves to solve the cube. He’s timing himself and he even bought a 2x2x2 to play with. I’m kind of done with it now, mostly because my approach is so slow (the bottom row, especially, takes dozens if not hundreds of moves). Hmmm, actually, it kind of sounds fun to do it again right now, but I think I’m just wondering if I can remember my own moves. Not sure what to think about that.
So what do you think? Here’s a few questions for you to help me with:
- What do you think about test-driven development for teaching?
- What about this analogy between the cube solution and teaching?
- What is the analogy to my son handing me a completed cube?
- What is the analogy to urging me to keep futzing until I find a more efficient approach?