Back in grade school (long enough ago I don’t remember *which* grade), most of my classmates hated “word problems” — things like

That’s a paraphrase of a GMAT prep site (which I’m not criticising at all, since it’s exactly the sort of thing you need to be able to do for the GMAT (which I’m also not criticising at all)). When I started teaching introductory programming in the 1980’s, a lot of problems we set were of the same sort: Here’s a very simple problem you care nothing about that you have to solve in a particular way because there’s one basic technique we want you to learn. For the math-talented, solving the equations was easy, but they hated translating the words into the equations. For the math-impaired, the equations were boring or scary and the “story” wasn’t the least bit compelling.

I think we can do a lot better.

I’ve learned four relevant things since those days, which I can symmetrically and geekishly divide into two groups of two.

- First, I learned more about teaching. My employer’s Centre for Teaching and Learning exposed me to problem-based teaching and a variety of techniques about teaching with groups My kids’ schooling taught me about the difference between formative and summative assignments; you don’t have to use exactly the same kind of problem for learning as you do to for assessing.
- Second, I developed a personal view of why we “formalise” anything. I started teaching “requirements analysis”, which is kind of the same thing as word problems, on steroids, for software geeks. I also started describing software design techniques mathematically; part of my intended audience was better at the math and part at the software design, but I had to be comprehensible to each. In both contexts, you study a complex real-world problem, find parts that can be translated into math, manipulate the math to get a formal answer, then translate that answer back to a solution to the original problem.

A better approach boils down to this: Give a larger problem that requires investigative work. Get people to work in groups, preferably with a mix of talents in each group. Encourage brainstorming to come up with a variety of approaches. Have each group present their work to the class and discuss the strengths and weaknesses of each solution.

So if you’re teaching time-distance-rate problems, how about the following?

To someone who thinks they’re supposed to focus on solving equations and eliminate irrelevant detail, this is horribly over-complex. The thing is, in the real world anything interesting is even *more* complex. That very complexity helps motivate why we need math but also puts it into a context where other skills are also important — like digging up more facts by asking people questions, or deriving one equation for several closely related scenarios, or deducing plausible assumptions about someone’s average driving speed from their moving violations, or using a Famous Web Search Engine ( *New Scientist* ‘s trademark-avoiding phrase) to find the Highway 401 exit number for Division Street (and whether the OPP have radar that accurate). The problem-based approach appeals to our mental hardware for stories, shows both the math geeks and the math-impaired how math can be useful, and helps each group appreciate the other’s talents.

I can’t be sure, since I don’t teach the appropriate grade, but I think Mary and Martha’s problem would work a lot better than something about two generic people converging along a straight line.