In my Fall Term course, Computer Networks, I experimented with designing the course around a central question: should the Internet be considered a public utility or a private good? Students produced reflections at the start and end of the term around this question: the start of the term’s reflection focusing on how they understood the question at present, and the end of the term’s reflection utilizing evidence from the course to demonstrate how their answer did (or did not) evolve.*
The experiment proved so successful that I now plan to do this in as many courses as I can. I like how it focuses the students, succinctly, on the core of what we’re learning and reminds them that what they learn in this course has broader impacts beyond the content. At the same time, the central question helps me focus on what’s really important in the course, which helps me make decisions about what content to include or exclude, what to triage, and how to structure course activities.
This spring, I’m teaching Software Design — the same course I taught a year ago. Software Design is an interesting course in that we cover a lot of ground and a number of seemingly disparate topics loosely united by the theme of “these are things we think our majors should know about how to write effective software”. Things like: how to work effectively in teams. Best practices in function and class design. Code style and commenting. A bit of user interface design and accessibility. How to shepherd a project from idea to deployment. Iterative design. Ethics. Design patterns.
I’ve worked with my colleagues who also teach this course regularly over the past couple of years to streamline the story the course tells. I came up with a “layer cake” diagram to show the students how the topics unite and where various concepts fall in these layers. In my “week in review/weekly preview” videos last spring, I included this diagram to indicate what layer(s) we’d hit the previous week and in the coming week. I think this went a long way towards making the course feel less disjointed to the students.
And yet…this didn’t quite get us all the way to where I wanted to be. There’s still a lot going on in that model. Plus, I feel strongly that a huge part of “writing effective software” involves ethical and social reflection. How might this software cause harm, intentional or otherwise? Whom does this leave out? When, and why, might we choose not to bring a piece of software into the world? Do our teams embrace and interweave diverse perspectives and life experiences? In what ways can software development be an act or a practice of social justice?
So, back to the central question. Given all that’s going on in this course, what should that central question be?
The answer I settled on:
I’d like to use the same initial/final reflection assignment I used in the fall, which means I’ll need to shuffle around the first week’s deliverables (not a huge deal) and modify the current reflection I have students do at the end of this course (where they reflect on the process of software development they experienced over the term). And I think this question lends itself well to a first-day-of-the-course activity framing the course for students. (It’s more holistic than the exercise I’ve used forever, which has students reflect on examples of good and poor design in software and systems they use and work through the design outline of a mythical system.)
More importantly, I believe the question tightly ties in those ethical and social justice issues that I want students to grapple with. It reinforces the idea that software design and development is not a neutral activity. We don’t have the luxury of NOT critically examining ALL the things we bring to the process: our biases, life experiences, world views, identities, and beliefs. And this critical examination is as much a part of the software development process as using GitHub effectively, or writing solid unit tests, or constructing tightly cohesive functions, or gathering requirements.
I’m interested, and eager, to see how this experiment plays out — and I’m already looking forward to my students’ initial and final reflections on this central question.
*In a nod to universal design and flexibility, students chose the modality for this reflection. Many wrote a classic essay, some recorded videos, and others produced and narrated slide decks. My rubric accounted for these various modalities.
One thought on “Extending the “central question” experiment to Software Design”
Thanks for sharing this, Amy! I’m putting this in OmniFocus to consider the next time I teach software design.
LikeLiked by 1 person
Comments are closed.