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?

Cool ideas here, Andy, and congrats – I did it once following the procedure, and felt like a chump afterwards. The big question that interests me is the third one, and you’ll soon understand why knowing where my head is lately.

I think the analogy of your son handing you a solution is clearly like the role a computer could play in learning. It provides answers in and of itself, but those answers are used to some other end beyond the solution in most situations that effectively use the computer in instruction.

I enjoy doing Sudoku, but the fact they exist and that I enjoy them depresses me in two distinct ways: a computer can generate a nearly infinite supply of them, and can solve them just as easily. Being handed a Sudoku solution teaches me very little about how to solve one. If, on the other hand, I’m given a single 3×3 square that is correct, it might give me insight to figure out the rest. A perfect hint, in other words, one that you know is part of the correct answer, allows you to continue experimenting knowing you have a life line. Sudoku and Rubiks share another easy fact in common that makes them too easy for a test driven solution – it is easy to know when you have completed it. This is not the same as for teaching a concept.

The only analogy I have for an easy candidate for test driven education is model-matching. You can tell by sight from a graph that a mathematical model matches data. A good/appropriate model can be made to fit any set of data thrown at it. I’m not sure other concepts in physics are clear enough to work with this.

I think if you carefully parse out the topics you’d like to get your students to grapple with, you could do this. I like the connection to computational stuff a lot.

One of the great things about your approach is that you should be able to apply it to a cube of any size. I learned how to solve a Rubik’s Cube with a method that involved matrix commutators, and once I learned how to apply it to a 3x3x3 cube, I had no problem using the same method to solve the 4x4x4 and 5x5x5 cubes. I don’t think the same could be said for memorized algorithms.

exactly! It’s fun for me to grab my son’s 2x2x2 and use a similar approach.

Hi Andy,

Ian’s test-driven approach to teaching is intriguing, and your Rubik’s Cube example helps me understand it more (congratulations on solving it, by the way). I am still hung up on what this would look like in a classroom, particularly in mathematics. I am skeptical that students have the tools to design such tests before knowing the material, although I will be excited to be proven wrong.

Bret

As Ian notes below, the key would be a test that makes sense, even before you know much about the material. For my theoretical mechanics students these days (see my newest post tonight ;) it would be something like “I can calculate the constraint forces that are necessary to hold a bead on a wire”. That’s a hard problem, with lots of approaches, but you don’t need a lot to know that you don’t know how to do it, if that makes sense.

Hi, Andy.

> 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.

Bingo. Absolutely. I think that would aid learning tremendously.

I also solved Rubik’s Cube by myself, way back in grad school, after being given a strategy hint that it was just group theory (by Douglas Hofstadter in his collection of essays called

Metamagical Themas). Sometimes, a meta-hint is far more valuable than a normal hint.Being able to futz with a pristine cube serves, I think, as a playground where you can try small experiments and easily see their results. Once our students have defined their self-tests, they’ll need an arena for developing their “solution” (knowledge) to pass them — an arena where they can get immediate, uncluttered feedback about what they’re trying out. (Analogy: Imagine playing with single commands on the MATLAB command line, rather than writing big complicated programs and then trying to figure out what went right and wrong.) What does this look like in physics? Um, maybe it requires hands-on stuff to explore, make simple predictions about, etc.?

I agree that the Modeling Instruction folks seem to have a lot going for them in this regard.

Pingback: Link March 2013 | SPACS