Getting students in CS222 thinking about SRP and reasons to change

It has been challenging to determine which aspects of CS222 to maintain and which to drop this semester. In a normal semester, we would have done more in-class code review, more live programming, and more discussion of human-centered design; this semester, I have pivoted toward encouraging teams to make sustained effort on their projects and to meet with me to discuss their progress. There is a sense in which it is more project-focused, but there's another sense in which it is less project-centered: we have not been able to use the projects themselves for as many fruitful discussions as I would normally like.

I have tried to change some of the in-person activities into distributed, asynchronous exercises for the teams to complete. This past week, I put up what I thought was a clever assignment to help the teams think more critically about the Single Responsibility Principle (SRP). I know that thinking in terms of good object-oriented design is hard for them, and SRP is the rule to which we always return. I have emphasized—even before the switch to online—that the "responsibility" of SRP is a responsibility to someone. This has been a useful perspective to me, gleaned from watching lectures by Robert C. Martin (RCM). The assignment, then had two parts: to watch one of RCM's presentations and then do an SRP analysis activity:

For Friday, Apr. 10:

• Watch this presentation on the Single Responsibility Principle. In the presentation, he talks frequently about SQL, which is a language for interacting with relational databases. His point is not about databases per se but about dependencies generally. It would be fine, for example, to think about making data requests over the Web—as we did in the two-week project—when he talks about SQL and databases. Indeed, when he says that “databases should be a detail”, you can think about JavaFX as being in the same category: an implementation detail that belongs on the periphery, not at the center.
• Work with your team to analyze the classes in the current build of your final project. For each class, identify to whom it is responsible; that is, identify its reasons for change, using the framework that Martin established in the video. Of course, we want this to be singular, but in practice, they may not be. Determining whether each has one responsibility or more is an intended outcome of this assignment. Document your findings in your team document and submit a link to the corresponding section.

I added that clause about SQL because most of my students would not have seen nor heard of SQL at this point in the curriculum. In the second part, I used essentially the same verbiage I have been using all semester to talk about SRP.

I was surprised when I reviewed the assignment submissions that nobody met my criteria of satisfaction. Indeed, none of them talked about people nor roles in their discussion of responsibilities at all. All of them talked about the classes in their program as being responsible for certain things ("This is responsible for creating a URL," "This is responsible for comparing playing cards," etc.) but not about responsibilities to people in a theoretic organization. I had a bit of a doubt when I wrote the question that they might struggle with this since they may not have a good frame of reference for how organizations function. What I did not expect is that they would also completely miss the part about identifying reasons for change. Despite this being explicit in the question, something I discussed multiple times in class, and a central point of the recorded lecture, none of the four teams addressed this in their submissions at all.

In response to having read and commenting on their submissions, I wrote up the following announcement for them on Canvas this morning. It may help to know that of the four projects, two involve reading online data sources about the NBA, one is a card game using conventional playing cards, and one is a D&D character generator.

It seems that everyone had trouble with Friday's (4/10) assignment. This announcement provides some additional clarifications. It's the kind of thing that would work better as a conversation than a lecture, so as always, feel free to post questions in the comments below this announcement.

First, make sure you watch the required video. Listen carefully to what RCM is saying about responsibilities and change. We're not reinventing the wheel here: we're following what he has to say about it. Listening to a talk like this is like reading a good book: you have the understand each piece, each sentence, each idea. Give it your full attention. If you don't understand it, go back and listen again, the same way you would go back and read a difficult sentence or paragraph in text. Just because the author or speaker keeps going doesn't mean you have to! When (not if) you encounter something you don't understand, then you switch to research mode: check your notes, write an essay, ask a question, find other sources. This is the scholarly way that you should understand as part of the university education process.

Once that's done, recognize that RCM says that responsibilities are people, but what he really means by that is roles in the organization. In a large organization, there is specialization; in a small organization, like our teams, there has to be cross-functionality. Also, since all team members co-own the code, it would not be right to say "This code is Jim's responsibility," because that's not true: the code is collectively owned, so it's all of your responsibility.

What RCM is talking about is reasons for change. What role in an imagined organization would request changes?

To help you out, here are some ideas you can draw on:

• A change to the user-interface could be requested by the user-interface designer.
• A change to the code that generates connections to your data source (e.g. URLs) could be requested by the database administrator (DBA)
• A change to the domain model could be requested by:
• In a game, the game designer
• In a productivity application, the business manager. (This is the role that potentially has the most variability in title, but I'll go with this one for now. The main idea is that it's making decisions about the core business logic: the pure model-layer of the application.)

With that in mind, look again at the current state of your projects. For each class, why would it have to change, and who would make that request? For example, rearranging the elements of the UI or changing the flow of interaction would be the UI designer. Changing the data source because you don't have a license to use the one you had been using would be the DBA. Adding another suit to a deck of cards or changing the racial bonuses for halflings would be the game designer, while changing the definition of what constitutes a basketball team would be the business manager.

For what it's worth, I've never given this particular assignment in asynchronous form before: it's been an exercise we've done in class. It's interesting to me that people had trouble with it, because if you had trouble with it now, that implies that perhaps you didn't really understand SRP when we first covered it months ago. I encourage you to think about this, because it has strong connection to our essential questions.

I encourage the teams to resubmit the 4/10 assignment. Working through this will help you gain a better understanding of OOP in general and SRP in particular. It will arm you to be able to discuss OOP in a much more clear and pointed way than many people can. For example, I see a lot of discussion in my game development circles of people discussing the role of OOP in game development; the truth is, they have very shallow understanding of what OO really is. Then, of course, they fight about it, because it's the Internet.

The second paragraph is really about how to watch a lecture. I suspect many of them don't really know how to do this in the way that they also don't know how to read for understanding. They may know how to skim and how to have a video playing while doing something else, but it is clear from their lack of questions that they don't really know how to read-for-understanding in any serious sense. Knowing that, it made me think that they probably don't know how to listen for understanding either. In fact, I'm sure they don't, since I have seen them listen to lectures before and fall into the "I will remember this" fallacy even when I explicitly point it out.

I decided to share this here in part to try to follow the "no wasted writing" rule. I don't think the problem I encountered is localized or idiosyncratic. However, I also wanted to leave my future self some breadcrumbs. I am not always opposed to the idea that students should have an assignment that I expect them to stumble on the first time. In fact, research shows this is a better way for them to learn then to have them simply do something easy. However, the next time I give this kind of assignment, I think I will have to provide more scaffolding around the idea of "a software development organization." That's probably out of the reach of people who are still trying to figure out how to program. It might be interesting to take this assignment and spin it narratively: to name these people in the organization, provide examples of the kinds of things they would ask for changes about, and then have the students write their own stories based around changes to their projects. In particular, this might help get them thinking about what "reason for change" really means, since I suspect many of them lack the maturity to understand that real software is not just fire-and-forget. The nine-week final project in CS222 helps get them to understand this, but it's a journey.

I also wanted to share this because I wonder what you, the reader, thinks about the way I have described the roles in a software development organization. Are these good titles to get the students thinking about? I intentionally omitted technical management, who would ask for unit tests or refactoring, because that's already a part of the required methodology—which you wouldn't know from looking at three of the four projects, but that's a topic for another day.