Demon JHM: Final boss of Morgan's Raid

I stopped by the lab to see if any of the 3:15 Studio team members needed anything, and the room was empty except for this.

I think I have to go rewrite the design document now.

Contemplating creative inquiry: a call for partners

One of the unique features of Ball State is the Virginia Ball Center for Creative Inquiry, known locally as "the VBC." The center supports seminars that: explore the connections among the arts, humanities, sciences, and technology; create a product to illustrate the interdisciplinary study; and engage the community in a public forum. The faculty and students who spend a semester at the VBC are completely committed to the project: the faculty member is relieved of all other teaching and university service responsibilities, and the students earn full-time credit for their participation. The seminars themselves are held off the main body of campus, in the beautiful and inspiring Kitselman Center.

I am considering applying to run a seminar in the next academic year, having talked the possibilities over with a few key people, including my department chair and the director of the center. A VBC seminar would be the natural evolution of my work on game design and development. All of my previous projects share a common shortcoming, namely that they have been shoehorned into 3-credit experiences under conventional university scheduling constraints. A VBC seminar is an opportunity to collaborate with students in a legitimate studio environment. In practical terms, we would really be an indie game studio.

I would like to use the seminar to create a game, created by following principles of agile software development. The two missing specifics are the community partners and the game itself. One compelling idea is to build upon my experience with the Morgan's Raid project to make another explicitly educational game for school-age children, potentially on the Underground Railroad. I already have collaborators and potential community partners for such a project, and creating software for K-12 has a high impact factor. Another option is to make something subversively educational. I agree with Raph Koster's theory that fun and learning are intrinsically tied, and it would be a great design exercise to make something superficially "simply fun" that, in fact, teaches 21st-century values.

This post is both a reflection and a call for partners. If you are part of an organization that has a compelling story to tell, or are in the games industry and want to explore strategic partnerships on community-focused developments, or you have a crazy idea that just might work, let me know. You can leave comments here of course, or you can email me (firstname.lastname at gmail). VBC application materials are due at the end of the calendar year, so there's time to bounce ideas around.

Thanks for reading. By the way, if you're a BSU student who will be around next year, think about participating and spread the word. I want the cream of the multidisciplinary crop!

Two Sprints with 3:15 Studio

We are now two sprints into the CS315 game programming class. I have not updated this blog as often as I intended, but I suppose that means I've been busy, which may even imply that I've been productive. The advantage of being healthy in a house full of sick people is that everyone else is sleeping, and I still have the energy to do some writing.

I am a little surprised to see I haven't actually written much about this class since before the semester started. We are in the middle of the fifth week of the semester, but let me start by explaining what happened in the first week.

One week of training

The students were introduced to the "course" by being told that it was not a conventional course at all. Rather, the students were in an orientation week for their positions working for 3:15 Studio, and their project was the implementation of a game based on Morgan's Raid. They were told that the orientation and training would last one week, and we'd move from there right into production. I was also explicit in saying that they were expected to work ten hours per week. This is something I've started telling all of my classes, based on the arithmetic that 40 hours per week is "full time" and 12 credit hours is "full time." With this class, though, it was not a recommendation to allocate that much time but a statement that this was the amount of work required. That is, from day one, this was presented as a situated learning experience, in which the students comprise one studio under my direction.

The rest of the first meeting consisted of introducing the game design, the stakeholders, and the historical context. The students were given a quick introduction to Mercurial and the MercurialEclipse plugin, and they were shown how to upload an image to a shared repository. Their first assignment, then, was to upload a portrait to a shared repository to help us get to know each others' names.

The second day (Wednesday) was a breakneck introduction to test-driven development, entity system architectures, pair programming, and Scrum. This was done in a lecture-oriented style, primarily as a means to maximize throughput. It was expected — and experience has shown — that not much of this was retained by the students, but it did help them build a mental framework of what level of rigor was expected. This resulted in the studio size decreasing from thirty to twenty-five, which I see as a positive step: students who were not willing to make the investment elected to choose another course. (It is an unfortunate phenomenon that, even at the 300-level, students mistake "Game programming" as a light and fun elective, when in fact, it is grueling and fun.)

The third and final meeting of the week (Friday) was mostly devoted to team formation and task allocation. Based on the number of registered students, I directed them to form four teams. The teams were formed primarily based on pre-existing social networks, at least according to my informal observations. At one point, there were three complete teams formed, but a headcount revealed that two students had not actually been incorporated into a team. Two of the teams shed members to join these two to be the final team, whom I will reference later as "that team I mentioned before."

For the first sprint, I wanted to give the students an "easy win" in order to build morale, and I wanted to ease them into Scrum, entity systems, and TDD. Based on this motivation, I set up a product backlog consisting of user stories that were all at the task level. That is, I had pre-sliced problems into tasks achievable by pairs of students. These were, in a sense, not proper product backlog items, since many had to do with software architecture and not anything that has value to the stakeholders, but to me this was a reasonable accommodation in my circumstances.

Sprint One: Two weeks

The first sprint was a success. All of the teams delivered their product backlog items (PBIs) modulo some miscommunication and minor revisions. Most of the tasks were fairly straightforward implementation tasks, the sort that would take me under an hour, but that I expected the students to take much longer since the learning curve was so steep. It's worth mentioning that the team I mentioned before happened to pick up the most difficult of these tasks. Given that the team was made up of a hodgepodge of students as opposed to a motivated group of friends, I was concerned as to how they would handle it, but this team came together in an exemplary way to solve their problems. (More on that in a later blog post, perhaps.)

There was a case around the middle of the sprint where some students broke the build — did I mention we're also using CruiseControl for continuous integration? I took the opportunity to shame them on the studio mailing list, and in that message, reminded everyone to be careful about what they code they push. I emailed these students privately and thanked them for being good sports about being the first to break the build, dooming them to be my sacrificial lambs for the good of the team. I knew these guys, and I knew they could take it. Good job, men. Since then, the only real "breaking" of the build has dealt with images being too large and non-portable Java code that works on only some operating systems.

The production portion of the sprint ended on a Thursday, and the next day we held a combined Sprint Review and Sprint Retrospective. This is really a place where the University's scheduling system is a challenge, since we had to do both in the space of 50 minutes. We could have used more time, but we made the most of the time we had. The Sprint Review revealed one of the major weaknesses of the product backlog design: because the PBIs were primarily architectural, I was the only one of the three Product Owners who could appreciate that progress had been made. The programmers and I were delighted just to get a window open with anything in it, but I think my collaborators expected a little bit more. I assured them that this was a necessary step to get the students up to speed.

The Sprint Review was amazing. We had two timeboxes: ten minutes to discuss what went well, and ten minutes to discuss what could be improved. We could have kept on going with our list of successes, and I could feel the excitement and morale in the air. As for the things to improve, many were very simple to address. We left the meeting on a high — helped by Concannon's chocolate chip cookies. One of the important tips I got from Clinton Keith's book was to take the time to celebrate at the end of a sprint, but with a mix of under- and over-age students, cookies seemed like the safest bet.

After this meeting, I met with my co-PI and we reprioritized the product backlog. Moving into the next sprint, we consciously revised the PBI format to deal strictly with those things that add value to the product owners.

These are the burndown charts for the four teams for Sprint 1.

I used Scrum a few semesters ago in game programming, and since then I've studied it more and been applying it with more care. However, my recollection is that it took us several sprints to get anything approaching the level of steadiness shown in some of these burndown charts. Some of the skips are interesting, since they show places where teams thought they had finished their tasks, then found that someone else pushed code that broke theirs or overwrote theirs—casualities of learning Mercurial—and then had to do clean the repository and get their solutions back in place.

Sprint 2: A 1.5-week short sprint

Sprint two ended today, and it was a short sprint due to weekend conferences: both me and the other lead investigator on the project would be away, and so we couldn't do a two-week sprint as planned. Instead, we decided to have Sprint 2 be a short one followed by a slightly longer Sprint 3.

I had overestimated the diligence of my students when, the weekend before the Sprint Planning meeting for Sprint 2, I emailed some comments on the revised product backlog and sprint backlog formats. As mentioned above, I revised the product backlog into items that required slicing by the students as opposed to pre-sliced tasks, and so I had also revised the Sprint Backlog format so that a PBI could be copied in and individual tasks listed below it. At 2pm we started the Sprint Planning, and it quickly became clear that the students had not appreciated this difference. Teams quickly started committing to PBIs, before they had taken the time to see that these were much heavier PBIs that needed breaking down. I hoped they would see this, but when I saw that teams were also changing the sprint backlog format to match the old one, I interrupted and explained what they should be doing: pulling down a PBI as a team, breaking it into tasks, committing to and estimating for those tasks, and then only committing to another PBI if there was excess capacity within the team.

The unfortunate result of this was that, rather than having a contiguous block of high-priority PBIs selected for the sprint, it was a bit of a toss-up. There was not time in our 50-minute timebox to start over, and so some rather important items were left unclaimed. Also, the teams shied away from high story point PBIs for fear of complexity in a short sprint, and I'm not sure that was unwise.

I felt a little more tension this sprint as more students had to use pieces created outside their team. Also, as I worked with teams, I noticed the overall quality of the code was getting worse. It's not so bad as to be unredeemable, but there are some code smells that would make a seasoned professional reach for a handkerchief. The problem is, of course and again, that it's a team of novices who cannot recognize code smells.

Even though the production was supposed to stop yesterday, I helped one team pull a last-minute victory before the Sprint Review and Retrospective today. The review went well, and my other two Product Owners agreed that it was good to see something actually working, rather than just looking at code that only I could appreciate. There were a few more loose ends this sprint: not all of the PBIs were completed according to their conditions of satisfaction, although this was fairly minor. One teams had committed to PBIs on the product backlog that it had neglected to copy to the team's Sprint Backlog, but I think they were embarrassed enough at this that they would not do it again. Much of this was fallout from the rough Sprint Planning meeting.

During the Sprint Retrospective, the students were much more pensive. No longer were they chomping at the bit to shout out the first positive thing that came to mind: instead, their contributions were more considered. This is natural, I think, and it shows a maturation of the studio. I was glad to see that inter- and intra-team communication, although mentioned as a success in Sprint 1, still was listed here, because communication is the key to keeping this studio together and making the project succeed.

We are currently discussing via our mailing list a few ways to address shortcomings in the system. One of the positive outcomes of this is that now, I think the students are all hungry for more information about software design and refactoring. They are feeling the real pain of real software development. This is very different from other teaching experiences—even my other class—where I have tried to teach the solution without the students really feeling the problem. It looks like we'll have some Community of Practice meetings in which I will lead code reviews or refactoring/redesign sessions. The students are hungry for it, and that should help them absorb some rich ideas.

Because I have them, here are the Sprint 2 burndown charts. They are in the same team order as the previous, so feel free to compare. My only significant comment about them is that, despite the fact that the teams were slicing up PBIs themselves for the first time—and many of them have never done this and never worked on a team before at all—these are still remarkably steady.

Onward to Sprint 3

While I am at the 2010 Consortium of Computing Sciences in Colleges Midwest conference, my students will be responsible for running the Sprint Planning meeting for Sprint 3. I have sorted out the highest priority PBIs, though I still need to do some cleaning up further down the backlog (which, incidentally, currently contains about 85 PBIs). I am confident that they will do a fine job in my absence.

This has been a fantastic teaching opportunity for me. I have invested more time and emotional energy into this project than any other venture since my doctoral dissertation, and I think the students appreciate being involved in this experience. My one niggling fear is that the whole experience cannot be replicated without expending this herculean effort each time, but I will leave sustainability of immersive learning for another writing.

A parenting reaction to a teaching problem

Something happened in CS222 today that surprised me. Specifically, I did something that surprised me. More specifically, I did something twice that surprised me. What did I do? I scolded my students.

I always have students close the door to the classroom since it's a noisy hallway. I have mentioned to the students many times that they should not come in late, because it is disrespectful to me and to their peers. I try to be transparent about my pedagogy, my constructivist teaching philosophy, and the idea that knowledge is created within a community of practice. Today, I was in the middle of a brief lesson on seemingly innocuous programming language features that, when misused, can lead to wicked bugs, when a student came into class late. It was about 8 minutes into class, and I cracked, pointing to him and shouting, "You need to stop coming to class late. It's driving me crazy!" Honestly, I don't know if that particular student had come in late before or not, but I was so irritated that I did not care. In retrospect, I hope "you" was interpreted in the plural, but I doubt that it was.

About seven minutes later, I had just finished my little impromptu lesson on the importance of using caution when modifying core language features (like Smalltalk's "new" method or operator overloading in C++), when a student let out a loud and bored-sounding sigh. I rolled with that one, saying something intended to imply my irritation. About three minutes later, the same voice let out the same sigh --- this time while I was in the middle of a demonstration --- and I lost it. I don't remember exactly what I said, but I know I pointed in that region of the room and commanded the person to stop it.

Needless to say, this did not set the right tone for the class. Later on, I told a funny story that involved repeatedly flipping off the classroom, and that seemed to cheer them up. Nothing gets students back like a little vulgarity.

In both instances, it was an immediate emotional pang that drove my reaction. It's the feeling I get when students dehumanize me or their classmates, treating the class as if they're watching a video. It's a feeling of being dehumanized and devalued. Further, it's a clear sign that the student is not trying to be part of a learning community. It's a terrible feeling.

Later on, I asked the students some questions about a piece of code I had just written, and none answered my question nor my request for questions about it. I knew that the non-participatory atmosphere was partially my own fault, so I had them form small groups that would be responsible for sharing either their best answer or their best question. As the students were working in small groups, it gave me time to start reflecting on what had happened, and I realized very quickly that I was treating these students --- the latecomer and the disinterested sigher --- the way I would treat my three-year-old son: I was scolding them, telling them to align their behaviors with accepted practice of politeness and social norms.

This was a personal revelation. In my ten-or-so years of teaching, I have had little trouble talking about technology and methodology, but I have had a much harder time talking about social norms. With a three-year-old, who is naturally testing his boundaries, I am now accustomed to monitoring his actions at home: when his antics shift from impish fun to dangerous or rude, it has to be nipped in the bud. This was exactly my reaction to the students in class: without even pausing to think about it, my "Dad Response" kicked in, and I scolded these students in pure authoritarian style.

As I continue to reflect on these actions and my reactions, I am having a hard time determining if I overreacted or not. Coming to class late is disrespectful to the whole learning community, and beyond that, it is very distracting. I made an example of the latecomer, and I like to rationalize my response as being a matter of fixing broken windows. I suppose the proof of the pudding is in the eating, and we'll see if students stop coming in late. If not, then it was neither worth embarrassing this one student nor worth establishing a negative atmosphere. Would it have been better to put off the day's lesson to have a roundtable discussion about why tardiness is rude, or why emitting sighs of ennui is impolite? I have a hard time imagining that to be the case. I am tempted to spend a few minutes on Thursday telling the students how I feel. Did they know that professors have feelings? It might be cathartic for me, but would it be a valuable use of our limited time together? Worse, would I just be preaching to the choir?