When Grinnell College announced that its relationship with the Posse Foundation would end, many folks at Whitman asked me what I thought or if I had any inside information. This post is not about that Posse.
Rather, it’s about my experiences with the Professor’s Open Source Software Experience (POSSE), an NSF-funded project that engages faculty from across the US in developing and deploying learning activities that engage computing students with humanitarian free and open source software (HFOSS).
I’m writing from the Philadelphia airport, having arrived the requisite two hours before my flight home to Walla Walla. (This is a long post, and I finished writing it on the plane and during my layover at SEATAC.) It’s an opportune time to reflect on what I’m taking away from the three-day workshop hosted by Drexel University and the preparatory activities that led up to it.
Why did I apply to participate in POSSE? Back in mid-April, I saw the announcement of the summer POSSE workshop on the SIGCSE email list. I was feeling stressed and overextended. One of the things I was feeling stressed about was the last big hole in our developing major curriculum: the software development course. I was feeling some pressure from potential project clients to make a decision about what kind of software development course I would teach. So the announcement got my attention.
I consulted with my Grinnell colleague Sam Rebelsky, who participated in POSSE in 2013. He found the experience valuable and encouraged me to apply. I respect his advice, so I did, and I was accepted.
Among my new colleagues, it seems clear that I have the strongest interest in teaching software development, or at least the most relevant experience. During my nine-year career at Grinnell, I taught three different versions of a software development course:
- Software Design in Fall 2007, which focused on object-oriented analysis and design, and included student-proposed projects implemented using Extreme Programming methods with TurboGears, a Web application framework written in Python;
- Databases and Web Application Design in Fall 2012, which was similar but introduced a more substantial study of agile software development and substituted Ruby on Rails for TurboGears;
- Software Development Principles and Practices in Fall 2014 and Spring 2015, paired with Team Software Development for Community Organizations in both semesters.
I developed the third version of the course as my Spring 2014 sabbatical project. A number of things were new about it:
- I found community clients for the software development projects. This was inspired partly by my prior teaching experiences, in which teams that had real clients performed better and learned more than those who did not. It was also inspired by a growing interest in service learning and my summer 2012 participation in a workshop about Purdue’s Engineering Projects in Community Service (EPICS).
- I split the project component of the course off from the traditional classroom experience, so that instead of having one, 4-credit course, there were two, 2-credit courses. The Principles course is a co-requisite for the Project course. Students may repeat the Project course for credit, creating opportunities for peer mentoring and deeper engagement with clients.
- The Project course is offered every semester to permit more-or-less continuous work on the community-based projects. This approach removes the pressure to complete projects within the artificial boundaries of the 14-week semester. It allows more room for students to f(l)ail, which can be a valuable learning experience. It also reduces the costs of any breakdown in communication between team and client.
- I adopted the Berkeley Engineering Software as a Service curriculum to gain more comprehensive coverage of software engineering topics than the previous two courses (though at the expense of some depth) and well-tested assignments with autograders.
- I recruited an alumni mentor for each project team. Mentors brought a deep knowledge of Rails and experience working with clients. Each team gets one mentor’s undivided attention (or at least, mentors not shared with other teams in the class). Also unlike the instructor, mentors also do not evaluate their teams. Even in the course of the first year, mentors became repositories of institutional memories about the projects they support.
I am proud of what I created and I was very sorry to leave it behind when I left Grinnell. (In fact, wanting to see this course through was the source of one of my most serious hesitations about leaving Grinnell.) I was very grateful that my colleague Sam Rebelsky was willing to take over the course.
But I don’t plan to replicate it at Whitman. To best support clients and students, the project course should really be offered every semester. I hesitated somewhat about foisting my course on SamR. He’s told me he’s struggled with some aspects of it because his personality and teaching style are not as well suited to the course as mine are. I’m not sure exactly what he’s referring to, but I trust him. I will need to be able to take leaves from teaching, and I don’t feel right about foisting a project course so tailored to my own teaching style onto a junior colleague.
There’s also a technological question. Walla Walla has an existing PHP-based ecosystem supported by Walla Walla Web Weavers. I haven’t yet broached the question of whether they would consider branching out into Rails.
So now I am searching for a new approach.
Fortunately, Whitman’s curriculum has a bit more flexibility than Grinnell’s. Grinnell limits each major to 32-credits, which typically means eight, 4-credit courses. (When we started offering software development as two separate, 2-credit courses, we also started offering some 2-credit electives.) By contrast, Whitman allows majors to require up to 36 credits, which provides the opportunity to require one more 4-credit course. Moreover, Whitman has 1-, 2-, 3-, and 4-credit courses, and the norm in the sciences is that the number of credits matches the number of class meeting hours. This adds additional flexibility.
My current thinking is to once again split the large team project into its own course, but in a different way. We have the flexibility to require both a 3-credit course on software development or design and a 4-credit senior capstone. I’m proposing the capstone will comprise 2 credits in the fall and 2 credits in the spring. In talking with Andy, I learned that Carleton also requires a capstone that spans multiple terms. This approach allows students time for a deeper engagement in a larger project than a single semester would allow, time to f(l)ail, and time to reflect on their learning. It allows me to support community clients with the capstone projects that I supervise, while not committing my colleagues to doing so.
I would first teach the software development course in Spring 2017. We would first offer the capstone in the 2017-18 academic year. I expect just 2-3 students in the first capstone offering—practically an independent study—but probably more like a dozen or so the second time around.
So now I’ve deferred the problem of the large team project experience. I am focusing for now on the 300-level, 3-credit, software development or design course. I want this to be something sustainable to teach, where I can reuse materials or pass them on to a colleague. Based on my explorations with the POSSE curriculum, I’m thinking about three possibilities.
First, I could teach with Allen Tucker’s Software Development: An Open Source Approach. I like this book because it addresses a range of software development topics, including software design (thought perhaps not exactly as i would teach it). Its driving examples are written in PHP, so it would directly prepare students to do work that fits into Walla Walla’s existing web technology ecosystem.
Allen taught a course based on his textbook at Whitman in Spring 2015, when he was a visiting professor. He engaged students in two client-driven projects, one supporting a Ronald McDonald House near his home in Maine, and the other supporting Walla Walla’s food bank. To enable students without much programming experience to complete these projects in one semester, it seems that he did most of the specification, design, and project management. This is work that must be done again for every offering, work that I am leery of. I also found my Grinnell students learned a lot from the unbounded nature of their projects, in which they had to interact directly with clients, do their own design (with the support of a mentor), figure out for themselves how to work together, and cope with the unexpected.
Fortunately, Allen’s textbook also addresses projects that are based in an open-source community, rather than serving a particular client. Before and during the POSSE workshop, I spent some time exploring Ushahidi, a PHP-based distributed mapping framework. It’s a mature project with a community that is very welcoming to students. I think I could augment Allen’s textbook with assignments based on Ushahidi.
One of the biggest lessons I take away from POSSE is that students can learn from open source software in so many ways beyond contributing code. In particular, open source projects provide a large body of code to read and experiment with. While some support may be required from the community, such engagement fits their mission and may opportunistically result in student contributions, code or non-code, during the semester or after.
(I also have some thoughts about how HCI students might contribute to open source projects through critique and design—but that is a topic to explore another time.)
Developing assignments for this course based on Ushahidi would be a pretty large investment on my part—probably as large as developing a client-based project, but hopefully more reusable.
Second, I could stick with the Engineering Software as a Service curriculum. It’s familiar to me. It’s a mature curriculum with a strong brand and a dedicated community of educators. The authors have convinced me that Rails is not an arbitrary choice of technology; it has excellent tool support for teaching good software development practices. Even if the local ecosystem is such that it doesn’t make sense to build a client-driven capstone project with Rails, students could apply what they learn about engineering software as a service to developing PHP applications.
POSSE could still help me with this approach. The curriculum sort of peters out, with the understanding that students will go on to carry out some kind of team project. In the Berkeley course, it’s a greenfield project for a local organization, but students could instead engage with an existing HFOSS project.
In particular, the curriculum includes some material on design patterns, but students never really apply that knowledge. Before that, there is an assignment that has students engaging with an open source project, Typo, to refactor some code, fix a bug, and add a new feature. But it isn’t an authentic engagement in that students work on a version of the project code that was forked several years ago. The project has since moved on.
Rather than having students work with Typo, and build patterns (or not) into their from-scratch project, students could understand, refactor, fix, and extend an active HFOSS project. I’ve got my eye on one in particular, a system for public deliberation named Loomio. This project connects with my dissertation work. It’s also something that, based on what I learned from my students’ HCI projects, I could imagine being used by the City of Walla Walla. In the course of working with POSSE, I realized that I am personally far more motivated by projects where I can look the clients in the eye.
Third, I could focus on software design. A few weeks ago I spoke with Steve McConnell, author of Code Complete and Whitman class of 1985. He dissected the Software Engineering body of knowledge for me, assessing what he sees as essential to a liberal arts computer science curriculum. The one thing he didn’t reject, he said, was software design. Myself, I wouldn’t completely throw out project management; being able to manage your own small projects is a valuable skill even if it isn’t particularly specific to computer science. But I agree that software design is the most essential software engineering skill to computer science. Software design principles, coupled with practices of automated testing and refactoring, are the most important things I’ve learned as a computer scientist from my three years of teaching software development courses. There is both a theory to software design and an art. Principles of software design have been developed over decades through empirical study and reflection on practice. When those principles are correctly and tastefully applied, the result is beautiful code.
At the POSSE workshop, I met Dale Skrien (Colby College), who not only teaches software design but wrote the textbook. The course he described at least superficially suits my teaching style and my would-be intentions for this course. He assured me that students should be able to learn Java without much difficulty, based on their prior experience with Python and C++. (I thought so, but it’s nice to be reassured.) I ordered an evaluation copy of his textbook while we were sitting side by side. He and I will be corresponding so that I can learn, perhaps borrow, from his course. If I adopted Dale’s curriculum, I can imagine we might collaborate on adopting or developing HFOSS-based activities.
I also discovered that a POSSE alumnus, Ben Coleman of Moravian College, has been teaching a software design course with Head First Object-Oriented Design and Analysis, which I used and loved in my first software design course but haven’t used since, and Head First Design Patterns, which I’ve long been intrigued by but never actually taught. I’m planning to reach out to him, as well, to learn how he is teaching his course.
Part of the POSSE workshop was to develop a learning activity involving open source software. I participated in the development of two such activities: installing and configuring Ushahidi, and applying a project’s coding conventions to critique project code. Why two activities? I wanted to explore a bit. And since I don’t know yet what class I am teaching, I didn’t feel fully committed to either one. It was still a useful exercise: I got to know some of the other participants, and I learned the process of developing a learning activity with the POSSE template.
My next steps are to explore a bit more: To dig into these three options and think about how they fit into the major curriculum as a whole, and to have more conversations with stakeholders in Walla Walla. I’m glad I’m doing this during the summer and not during the middle of the fall term when course proposals and textbook orders are due.
When the evaluation form asked what I took away from the workshop, the first thing I wrote was not anything about teaching or open-source software, but rather “Meeting people.” To name a few:
- I had introduced myself to Dale Skrien in the first IRC meeting. He caught my attention because I know his Colby colleagues Stephanie Taylor and Bruce Maxwell. It was wonderful to meet him in person and learn about his software design course. Now I know three-quarters of the Colby CS department.
- I met the entire Dickinson CS department, who had carpooled to the workshop together. I think I had met Grant Braught at SIGCSE sometime before, but not his colleagues. My former Grinnell colleague Marge Coahran had gone on to another visiting position at Dickinson, and it was really nice to meet more of her colleagues.
- I had a good conversation with Chris Murphy (UPenn) over lunch today about the role of external mentors in software development courses. We talked about organizing a panel on the topic.
- I had a good conversation about beer, whiskey, and teaching HCI with Stoney Jackson.
- I had some good conversations with Lori Postner on the walks between the Drexel campus and our hotel. With our shared UW experience, I feel I’ve known her for ages, but only now have I finally gotten to know her.
- It was also good to meet the rest of the POSSE leadership, who I had only met on IRC. Heidi Ellis for some reason reminds me of AJ Brush, who was one of my mentors in graduate school.
- My first and last conversations of the workshop were both with people from Red Hat headquarters in Raliegh, NC. I introduced Tom Callaway at the beginning of the workshop, and I shared an airport shuttle at the end with Gina Likins.
That I valued meeting people was no surprise to me. I realized about two years ago that I had graduated to the so-called hallway track of the SIGCSE Annual Technical Symposium. I find myself learning more from conversations than attending sessions, whether those are conversations with people I don’t know well who can offer me new perspectives on teaching computer science, or conversations with those who I know well and who know me well and can offer me new perspectives on myself. In fact, meeting all these wonderful new people convinced me I need to be at SIGCSE in Seattle this spring, even if I do go to another conference in the spring.
But what I wrote next was completely unexpected: I learned about POGIL.
On Thursday morning, Clif Kussmaul (Muhlenberg College) introduced us to Process Oriented Guided Inquiry Learning (POGIL). It was something I had heard of and kind of dismissed as yet another buzzword, but he presented some convincing evidence for its effectiveness. I was struck by his example activity as something I might like to do on the first day of my intro class (in lieu of the great peanut butter and jelly caper), or as an introduction to thinking critically about algorithm design later in the intro course.
And then he led a series of POGIL activities. The way Clif taught resonated with me in a way I have not experienced in years, if ever. POGIL is the epitome of the “guide on the side” approach to teaching: A carefully crafted series of questions designed to lead to insight, coupled with a deliberate delineation of roles to keep all students engaged, as well as active monitoring and intervention. It has elements in common with the workshop-style approach I learned by teaching Grinnell’s CS1 course. But I also saw myself trying to do something like POGIL in my 200-level course this spring, and doing it badly. (Well, at a “beginning” level at best.) I’d like to learn to do it as well as Clif does.
On Thursday I sat by Clif at both lunch and dinner. Thinking back, this was more fortuitous than deliberate. In one of our conversations, Clif told me there are annual POGIL workshops in the Pacific Northwest region. I looked at the schedule and saw there is one in Seattle in July. A little over-eager part of me wanted to see if I could get into it. But a moment’s reflection reminded me that my summer is full enough already, and next year will bring many new things to learn and develop. I’d like to plan on it for next summer.
In the meantime, Clif and some of his colleagues have shared a lot of POGIL activities for a range of CS courses. I hope there are some that will fit the courses I’m teaching. Designing and refining POGIL activities seems like an intensive, iterative process. I’d like the opportunity to try implementing the approach with some well-designed activities before I attempt to design activities of my own.
I also learned one simple, concrete technique from Clif that I can use right away. The purpose is to get students’ attention back after turning them loose on an activity, something I’ve always had difficulty with. The technique is to teach students that when you raise your hand, they should fall silent and raise their hand as well. It’s a brilliant distributed messaging algorithm: Students who receive your signal pass it on, so that students who are facing the other way receive the signal from students behind them, and students who are totally absorbed in the activity receive the signal from their groupmates. It’s so simple that the participants all learned it within an hour. It’s something I’d like to try in my first classes of the fall.
Looking back at my email about this workshop, Clif is who first responded to my application to participate. It’s funny to think that he might also be who I learned the most from. This feels big—something that might not just influence the design of one course, but that might be the next evolution in how I teach.
Last but not least (?), I got a new sticker for my laptop! I am highly selective, so this is a big deal.