Reflection on 345/545

It’s the end of the semester, and today were the final presentations in the HCI class. I am taking this opportunity to reflect upon this teaching experience, an attempt to articulate some of the joys and frustrations of this semester.

  • I am disappointed that none of the projects have been released on the Market. I suppose it’s a good thing for the students that I didn’t make this a requirement to get an A. I do not think that any of the teams even seriously looked into the distribution requirements, which makes me sad, because there are many interesting elements here, including application permissions, application signing, certificate management, and dealing with feedback from unknown and unexpected users.
  • I knew going into the semester that the vast majority of the students would not be able to adequately scope their projects, and so agility was built into the expectations. However, I did not fully account for the negative relationship between estimation inexperience and team size.
  • I suspect the results would have been better overall with smaller team sizes: this would have increased both accountability as well as motivation, since individuals would be needed. I tried to keep the number of teams relatively small so that I could keep track of each team and provide directed feedback. In retrospect, seven teams were too many for me keep track of anyway, and so having more teams would not have been a significant drain on my time. It would have complicated in-class presentations, but I suspect this would not have brought as much difficulty as benefit. (Many wise students suggested smaller team sizes in their reflections.)
  • The risk matrices were generally useful, but the MSF Team Model was not. From personal experience and the stories told in students’ reflections, it is clear that most students did not understand the meaning of the roles, and I suspect the “role” system caused more difficulty than was necessary. Students with no prior experience in significant team development projects have no useful mental framework for roles, and so, in retrospect, I should have predicted that they wouldn’t appreciate what the roles meant. Point in case: “testing” doesn’t mean anything to a student who has never tested anything. (The fact that students can go through the foundations courses and never discuss testing is a problem, and it’s being addressed by the introduction of 222.)
  • The teams suffered from communication breakdowns and uncertainty about tasks at a fine grain. The risks of the risk matrices were slightly too abstract for the students with no prior team or large-scale development experience to handle. I suspect one of the following would be preferable: (1) more rigorous management of the risk matrices, including more directed feedback from me about the appropriateness of risk articulation; or (2) a more quantitative, task-oriented project management technique such as the product backlogs of Scrum or the use of issue tracking software.
  • Having community partners was important, especially to the best students. Many of the students clearly learned important lessons from these interactions. Some of them were lessons I was also trying to convey, but it was much more effective to work with the ignore-the-professor-in-favor-of-outsiders phenomenon than it was to fight against it!
  • The reflections were worthwhile except that I needed to set stricter deadlines. I am not a fan of deadlines for such work, but they are needed for my own sanity, not for the students. Because I did not set explicit deadlines, I have been inundated by “reflections” the last two days. The astute reader can guess the quality of reflections that are being sent in right before the end of the semester. Hint: they’re not the ones I really enjoy reading, and I think they primarily why I have been so blue today.
  • Expanding on the previous point, it was very rewarding to read the reflections of the responsible students. By responding to their metacognitive essays, I felt like I was having a direct and positive impact on their individual learning, a great win for a constructivist. I realize that there are two potential complications in this: (1) there is a chance that better rhetoric is being rewarded over authentic-but-inarticulate reflections, and (2) a student who is savvy with emotional intelligence could manipulate me through these essays. I think either are acceptable costs. Regarding the first, writing is an extremely important skill that students should have anyway, and regarding the second, I think the best of the students are more honest than that.
  • Expanding on this point again, it was frustrating that some students still did not get the point of the reflections, or perhaps what metacognition is about. I am concerned that perhaps I did not articulate the requirements clearly enough, but with targeted individual responses, I’m not sure what else I could do aside from assigning them to do exercises out of Pragmatic Thinking & Learning.

There are some things I would change if I could do this course again, but mostly, I wish I could take all of my “A” students and with me and do some really great things. Unfortunately, the curriculum doesn’t work this way: this is a terminal class, and I have to let go. (Another reason I’m a little blue today.)

For any of the negative aspects of the course, I do believe that the students really did meet the learning objectives of the course. By and large, I think they understand better the role of humans in software development, both as users and as collaborators. For those who are not graduating (who are most), I look forward to watching them move through the curriculum and seeing if the course really had a measurable effect, especially as they take the capstone course— projects of which are often characterized by team trouble and bad user-interfaces!

Also, the design of the course met the primary constraint: the students were able to hit the ground running with a mobile application development project of their own design, while I was free to enjoy the birth and first few months with my second son. I wouldn’t want to do this every semester, but this one worked out fine.

Tags:

3 Responses to “Reflection on 345/545”

  1. Ian Crotty Says:

    As a student in the class, it saddens me that not everyone took the class seriously enough, or learned as much as I have. I found my experiences to be very rewarding. I feel almost that in a class of this size, tighter structure is required. There seems to be a fine line between how many people can be organized into a working, thinking entity, and becoming like herding cats. I feel that the larger the group of people, the harder it is to convey desires and ideas. Maybe this class would be better taught with a smaller selection. As you said, 7 large teams was too much. A class of half the size might yield a more positive outcome. Not to say I did not learn a lot from my time in the course. It just took a lot more thinking and reflection on the material for me to grasp the concept fully. It was almost as if there was a bit of static with each topic that needed to be filtered out in order to truly understand what was desired and what was being taught.

    • Paul Gestwicki Says:

      I agree that the experience was fundamentally good, but there was room for improvement. It was great having you in class, especially since you helped herd Deus Ex for me. One other thing I forgot to mention in my original post was that to help distribute the management, I should have had more well-defined communication paths for the project managers / tech leads. We might have been able to nip some more issues in the bud with a tighter communication among us.

  2. Writing, Scholarship, and Software « Paul Gestwicki's Blog Says:

    […] year. In Fall, I felt productive and I also felt that I was learning. In much of the Spring, I was frustrated. (Interestingly, as I look back at the past semester’s writing to pull out those […]

Leave a reply to Writing, Scholarship, and Software « Paul Gestwicki's Blog Cancel reply