A Seven-Step Primer on Soft Systems Methodology

I'm currently TAing for CSC2720H Systems Thinking for Global Problems, a graduate-level course on systems thinking. In class today we talked about soft systems thinking (SSM), an approach which uses systems thinking to tackle what are called "wicked problems". I thought I'd outline one approach to SSM, as it's useful to CS education research.


Step 1: Identify the domain of interest

Before you can research something, you should first decide what your domain is. What topic? What system are you studying? For example, "teaching computer science" could be your starting point, as could "climate change".

Chances are you're looking at a wicked problem. Conklin's definition of wicked problems are that:

1. The problem is not understood until after the formulation of a solution.
2. Wicked problems have no stopping rule.
3. Solutions to wicked problems are not right or wrong.
4. Every wicked problem is essentially novel and unique.
5. Every solution to a wicked problem is a 'one shot operation.'
6. Wicked problems have no given alternative solutions.

Because you're looking at a domain which doesn't have a clear definition or boundaries, you'll first want to immerse yourself in the domain. One trick is to draw "rich pictures", which are essentially visualized streams of consciousness.

You should also think about what perspectives you bring into this domain. What biases and privileges do you have going into this? Why are you interested in this domain? What do you have to gain or lose here?

Highlights from ICER 2013

A few weeks back, I attended ICER 2013 at UC San Diego. Afterwards, I went up to San Francisco and had some adventures there (and at Yosemite), and then spent time in Vancouver seeing friends before coming home.

ICER this year was a solid conference, as always. I liked that this year things reverted to having two minute roundtable discussions after every talk, before the Q&A. It makes for a much more engaging conference.

All hail the UCSD Sun God, who benevolently oversaw the conference.

My favourite talk this year was definitely Tom Park et al's "Towards a taxonomy of errors in HTML/CSS". HTML/CSS tends not to get studied in the CS ed crowd, and as Tom's talk illustrated, that's a big shame. HTML is for many people the first (and sometimes only) formal language that they encounter.

Bonuses and Software Projects

At today's CS Education Reading Group, one of our group members led us through an exercise about group work from "Students' cooperation in teamwork: binding the individual and the team interests" by Orit Hazzan and Yael Dubinsky.

It's an in-class activity to get students thinking about how they work together in software projects. Students are given a scenario: you'll be on a software team. If the project completes early, the team gets a bonus. How should the bonus be allocated?

1. 100% of the bonus should be shared equally
   
   
2. 80% should be for the team to share; 20% should go to the top contributor
3. 50% team, 50% individual
4. 80% team, 20% individual
5. 0% team, 100% to the individual who contributed the most

Comparing and contrasting algorithms is better than sequential presentation

In five days, I'll be heading to ICER 2013 in San Diego, where I'll be presenting a paper "Comparing and Contrasting Different Algorithms Leads to Increased Student Learning" (pdf here).

The findings in a nutshell: if you present two different approaches to solving a compsci problem side-by-side and have students compare them, the students will understand the problem better than if you present those approaches sequentially. And importantly, the students will be better transferring their understanding of the problem to similar problems.

Why is this notable? Because the sequential approach is pretty much ~95% of how we teach algorithms and data structures! Just this past term when teaching CS2 I did things this way: a unit on binary trees, then a unit on BSTs, then a unit on heaps. Yet the evidence we have here is that it's better to show algorithms/data structure variation in parallel.