Archive for March, 2010

Education discussion in Linchpin

March 20, 2010

Clearly, I’ve been introspective about both the specifics of my teaching and the general properties of higher education. I was feeling like I had found some closure internally, when I sat down last night to read a bit of Seth Godin‘s Linchpin. Two nights ago, I had read a few pages on education, and I was so struck by them that I set my bookmark back intentionally to read them again. I don’t remember ever doing that before, for what it’s worth.

From page 39:

We’ve been taught to be a replaceable cog in a giant machine.

We’ve been taught to consume as a shortcut to happiness.

We’ve been taught not to care about our job or our customers.

And we’ve been taught to fit in.

None of these things helps you get what you deserve.

That’s reasonable, and it echoes what I believe about striving for excellence, about “good enough” simply not being good enough. He goes on to say [p44]:

Teaching people to produce innovative work, off-the-chart insights, and yes, art is time-consuming and unpredictable. Drill and practice and fear, on the other hand, are powerful tools for teaching facts and figures and obedience.

Again, I agree. I read this paragraph over and over again, and it is sobering. He continues [p47]:

What should they teach in school? Only two things:

  1. Solve interesting problems.
  2. Lead.

Right-on. However, then he extrapolates:

The idea of [computing a hypoteneuse] by rote, of relentlessly driving the method home, is a total waste of time.

Now, I’m not so sure that Godin and I are talking about the same thing. While it’s true that most people do not need to memorize the Pythagorean theorem in order to succeed in every day life, this ignores one of the most important aspects of a liberal education: that it trains the mind to think deeply about problems. I came across a compelling argument recently (though I cannot remember where) that said that the point of K-12 math is not to teach mathematical skills, but to hone the learner’s ability to mentally manipulate complex and abstract concepts.

Taking the Pythagorean theorem as an example, it may be true that there are diminishing returns in “relentless” repetition, but on the other hand, it takes 10,000 hours to be an expert. If we want students to be able to even conceive of higher mathematics (i.e. to gain any insight beyond novice or advanced beginners), would they be able to do this without practice? I’m not so sure.

I can’t help but think about Math and Computer Science together here. My Calculus professors in college were traditional mathematicians who made us do volumes of exercises, the same exercises the students before had done. I suppose I learned some Calculus at the time, although now I can only remember the very basics of differentiation and integration, and I certainly don’t remember “series” except by name. Honestly, I don’t really remember clearly what they are for.

My Computer Science professors were, by and large, mathematicians also. (It was a Mathematics and Computer Science Department while I was there.) Our assignments were very similar: build up something non-novel that is a little step above what we built before. Thinking about data structures, I remember binary search trees since we used them again and again as examples, and they are conceptually simple. I remember the names of red-black trees and AVL trees, but I could never build one now without either searching the Web or essentially re-inventing it. That is to say, I don’t have any working knowledge of either advanced data structure aside from knowing that they’re balanced trees.

Also, I am OK with this. I brought up a similar point in a curriculum committee meeting once, and some of my colleagues seemed to think I was nuts, that I didn’t mind not remembering “fundamental” Computer Science ideas. However, it hasn’t stopped me from solving interesting problems, as Seth Godin puts it.

The question remaining for the scientifically inclined is: would I still be able to solve interesting problems without the physical changes in my brain brought about by years of mathematics practice? Several studies in CS education point to time-on-task as a major factor in success, suggesting that motivation works only in that it encourages fruitful practice.

I have been enjoying Linchpin, but this discussion of education is not as black-and-white as the author portrays it, not according to recent research on the science of teaching and learning. Adopting Dreyfus’ terms again, it’s one thing for an expert to spend his/her time solving interesting problems, but novices still need rules and scaffolding to move up the skill acquisition ladder.


Criticism and Teaching

March 19, 2010

Yesterday, I had an interesting juxtaposition of events. In the early afternoon, my students in 345/545 gave their status reports. Immediately afterwards, I went to a colleague’s class — a graduate course in architecture — to help review status reports there.

In my own class, the students had previously set goals for what they would accomplish before Spring Break. I think the teams had set (mostly) set reasonable goals, although several of them struggled with the concept of measurability. (As in, the goals had to be measurable.) The point of Thursday’s status reports was to briefly address how well the teams had progressed in meeting their goals.

While some of the teams had met their goals, I was overall disappointed with the progress. Some teams clearly misunderstood that there was no expectation in the schedule for work over Spring Break — although it was an opportunity to make up for lost or mismanaged time. Some of the teams have been struggling with the same technological issues since the beginning of the semester, and this is inexcusable. Fighting against the technology, there will be no progression into the deeper topics of HCI that I want students to explore through their projects.

However, I did not tell them this. I was mostly quiet during the status reports, offering little nuggets here and there. My thinking at the time was that the public shame of having missed even rudimentary self-imposed deadlines, and the peer pressure from their colleagues, would be enough to force them to move forward. In retrospect, I’ve been acting this way for weeks, and I’m not sure that this has been the right course.

I moved from this class to a colleague’s, in which I was one of several faculty and staff members who were providing feedback on entrepreneurial innovative ventures. Th best part was the discussion following the presentations. Without naming any names, I’ll say that I was vocally critical of one of the presentations. During the presentation, I recorded a page of criticisms. When we got to Q&A, I tried to gently address the shortcomings of what was presented, though I probably addressed only half of the items I had written down (and none about the dreadful infographics). I was fair, I think, and firm. Yet, perhaps not firm enough: the real problem was that the presenters had an idea but not a plan. Ideas are a dime a dozen: implementation is what defines success. However, I tried to criticize what was presented rather than the process I perceived; I did not want to come across as a jerk with an axe to grind when invited into another’s classroom. However, when the professor himself gave his closing comments to the team, he articulated very clearly what was really the essence of my piecemeal criticism: the problems of the team’s process itself rather than the specifics of their presentation.

As I reflected on this — and discussed it with my wife over dinner — I feel like I was two people yesterday afternoon. In my own class, I was standoffish, not even writing down the many and valid criticisms that could (and probably should) be levied on my students. My wife put it well when she suggested that I should have said, “It goes without saying that your work is unacceptable.” The problem is, I don’t know if it actually went without saying, or if my students are blissfully ignorance of their impending doom should they fail to pick up the pace.

Conversely, in the afternoon, I was diving into specifics, leveraging the critical power of the unknown professor to try to pry the best ideas out of these students who I don’t even know.

And this makes me wonder if this is the essence of the problem. I have gotten to like my 345/545 students, and I want them to succeed. I don’t really know how much criticism I can hit them with and have them still be inspired, rather than becoming disenchanted. I am reminded of a story that Hal Abelson told me about his mobile application development class: when one of the students listed “lack of time” as a risk, one of the professors suggested he either drop the course or deal with it. That’s tough love — I respect that, but sometimes I have a hard time doing it. I wonder if maybe I have coddled my students too much, given them a false sense of accomplishment where, in fact, I complain to my wife almost every night that I am concerned about their lack of progress in their projects.

From this cogitation, I have come up with two actionable ideas. First, the teams should be smaller. My initial vision for the course was that students would be inspired to take the initiative to explore the rich landscape of HCI, and that each would bring unique talents to bear on the success of the project. This has not happened, and I can’t help but blame The System: my students are being asked to do too many things in one semester for them to be able to focus on learning. (Learning in higher education?! No time for that. (That’s the topic of another post.)) As it turns out, some of the teams are just too big, and it opens up the possibility for miscommuncation, mismanagement, and blamesmanship in completely unproductive ways. If I cannot change the system, I can mitigate the problem with smaller teams, I suspect. The confounding corollary is that then I would have about twice as many projects and teams to keep track of, which would be very difficult for me, and again I can’t help but blame The System.

The second action item is to specify milestones for the second half of the semester. Some of the teams are doing an exemplary job of managing themselves, but many still have not seemed to hit stride in this respect. By giving some concrete milestones, I am wedging myself in as a manager in a way I was hoping to avoid, but it seems to be the lesser of two evils. Figuring out where these milestones should go will be a topic for this weekend’s consideration and Monday’s work.

A third idea, on which I may or may not take action, is that I may need to create more explicit rubrics for my students to let them know what I think about how they are doing. They are right now conducting peer evaluations, using a painstakingly-designed rubric. I could adapt this to let them know how I see their team work, presentation skills, technical progress, and understanding of key HCI concepts. I suppose I should first set up their milestones, and then figure out how to best give them the feedback I think they need.

Moving forward, I am going to try to be more cognizant of my own feelings with respect to the critical feedback I give my students. If I’m not giving them the criticism they need, then I’m not doing my best job for them. I will try keeping some notes about my feelings and fears as I observe these status reports, and hopefully that will guide me.


As always, my wife is a font of wisdom. How she does so with the chaos of two young boys, I cannot fathom. In any case, in conversation with her I realized that I was probably trying a little bit too hard to try to undo the effects of years of brainwashing from our culture and ridiculous industrial educational system, and accomplishing this in half a semester may have been a little optimistic. This forces me to acknowledge my own fears, that if I comply with the system — as my students (potentially subconsciously) want — I will forget what it is that is so fundamentally broken about the system itself.

Design Thinking and the Ephemerality of Software

March 16, 2010

I recently read Richard Buchanan’s Wicked Problems in Design Thinking (Design Issues, Vol 8, No 2, 1992, pp5-21) on the recommendation of my esteemed colleague Mahesh Senagala. The article frames design as a liberal art, partially drawing on design as an approach to wicked problems. The arguments for the inclusion of design thinking as an necessary liberal art are compelling, but I was already in that camp before reading the article. What I found more interesting about this paper from 1992 was the omission of software design as a design category.

Buchanan categorizes the areas explored by design into four areas, and the terms and examples are his:

  1. symbolic and visual communications: graphic design, typography, advertising, book and magazine production, scientific illustration, photography, film, television, and computer display
  2. material objects: form and visual appearance of everyday products as well as the “physical, psychological, social, and cultural relationships between products and human beings.”
  3. activities and organized services: logistics, decision making, strategic planning
  4. complex systems or environments for living: systems engineering, architecture, urban planning

The author uses the shortened phrase “signs, things, actions, and thought” to refer to these four areas impacted by design thinking. It is worth noting that the author acknowledges that these are not separate fields of study, and that any significant design exercise will incorporate all four.

In the article, there is no treatment of software design, despite the fact that it had been studied within the Computer Science and Software Engineering disciplines for decades prior to this article’s publication. I scribbled a few notes in the margins, wondering if the author meant to include software design as part of systems engineering, since he does not extrapolate. (It’s also worth noting that Buchanan addresses the inherent problem in the word “design,” that different people use it to mean different things. Here, I am talking about the “internal” design of software—how it works—not interaction or interface design.)

I posit that software design is significantly different from all other manifestations of design because when software has been fully designed, it exists. A significant corollary is that when software exists, it has been designed. Flaws in software implementation are evidence of errors (of commission or of omission) in its design. Recognizing the intangibility of software leads to its ephemerality, characteristic of modern continuous integration systems. An “instance” of software—a build—may only exist for milliseconds. Even if software design then is included in Buchanan’s characterization of system design, it is substantially different from architecture.

(I noticed that my argument echoes in software Anselm’s ontological argument for the existence of God. I don’t know if it’s a coincidence. Also, it reminds me again that “software architecture” is a misleading term, since software design is characteristically different than traditional architecture.)

I would be interested to know if the science of design literature contains subsequent work to Buchanan’s, and whether philosophies of design include “design of the intangible and ephemeral” within their ontologies.

Review: Ship It

March 7, 2010

I finished reading Ship It! yesterday, a book on effective software development. The book is an easy read, and like many of the books from the Pragmatic Bookshelf, it provides approachable and immediately-implementable advice. Personally, I love this approach: the book tells me where to look should I want to read more about the theory, but it focuses squarely on pragmatics.

I took several pages of notes while reading this book, mostly ideas to apply in my teaching and my mentoring of student projects, but some dealing with my own development. I have been using source code management software for about a decade, and I’ve been forcing my students to use it the last two years as well. However, I have no real experience with continuous integration. While I know enough not to break the build (and I advise my students likewise), I’ve never used a build server such as CruiseControl.

Similarly, I have used IDE build tools, and I’ve scaled up to ant for more complex builds (e.g. wrapping up multiple jars into one jar, signing it, and pushing it to a Web server with JNLP enabled), but I have never gone to the extent of automating the build outside of the IDE. Thinking back to last year’s Game Programming class, one of the problems we encountered was that about 1/4 the class was more comfortable in NetBeans than Eclipse. Thinking back on this and reflecting on the advice in Ship It, it would have made us more productive to factor out the build in an IDE-neutral way and let the students use what works for them. A potential complication here could be differences in the formatting of lines: I would hate to see huge repository changes just because someone did Ctrl-Shift-F in Eclipse — and I want them doing that for readability.

There is only brief mention in Ship It of Maven, and I’m not sure if that’s because it’s beyond the scope of their writing or if its a subtle way of reminding the reader to just start with ant and make decisions from there.

Two ideas strike me as recurring throughout the book. One is source code management: seriously, how does anybody live without this? I use it not only on my personal, single-developer projects, but also on all of my Documents folders. (Another with for text-based logical formatting over binary blobs, by the way.) The other theme is The List. Very simply, The List is a prioritized collection of all the things you need to do: features you need to implement, bugs you need to squash, risks to be mitigated, etc. It’s a very simple concept, but it’s good advice. After reading their introduction to The List, I decided to make a list of the things I need to do for work, so that I can start more rigorously estimating and prioritizing my time. Of course, the day I decided to do this was the day that I also had to coauthor an abstract. The good news is that the abstract was accepted; the bad news is that I still don’t have A List. More to the point, I wish the authors had given one or more examples of lists. I wonder if they have recommendations for specific ways to structure a list. For example, I started tinkering with putting one on Google Docs spreadsheet application, but its support for embedded text is not up to snuff (or I don’t know how to use it). Then I tried putting it into a simple document, but then I could not easily sort. It is circumstantial that I was looking into note-taking and list-making software for Android recently, and I didn’t find anything that matched the amorphous expectations that my brain seems to have.

The last section of the book provides a series of hypothetical problems along with suggestions for how to overcome them. I found this section to be the least valuable to me, since I am not actually a professional software developer. I find myself wishing that I had the kinds of problems that were described in this section, since it would imply that I have at least some semblance of reasonable conditions for software development. Ship It doesn’t deal with the kinds of problems I have as an academic, such as “I only see my developers for 75 minutes twice a week,” and “The promotion and tenure committee does not adequately recognize software development as scholarship.”

The appendices include links and brief descriptions of many pertinent software and process tools. I’m not sure how much lasting value such appendices have, since this information changes and can usually be found via Google, Wikipedia, etc. However, one appendix of particular value was a list of recommended readings, which included general reading on software development, recommendations for particular tools and environments, and even a section on leadership and skills. It’s funny that the authors of this book would recommend How to Win Friends and Influence People just days after one of my best friends recommended it to me; I suppose that means I should move it up the queue.

In summary, I enjoyed the book. A lot of the ideas within it should not be unfamiliar to software developers, but as one who is educating the next generation of software developers, it gives me a valuable list of topics to introduce into my courses. Highly recommended, even if you have to gloss over the last chapter as I did.

Here Comes 222

March 3, 2010

In Fall 2010, my department is introducing a new course, CS222: Advanced Programming. The role of this course is to bridge the introductory programming sequence with development-heavy upper-level coursework. It is in the cards that I shall be teaching the inaugural offering of CS222. I’ve been keeping my eyes open for ideas to incorporate into this class.

I’m reading and thoroughly enjoying Ship It, from the Pragmatic Bookshelf. In fact, I’m contemplating using it, The Pragmatic Programmer, and Effective Java as textbooks for the course, though I need to spend more time planning out how that might work. Ship It spends a chapter on Tracer Bullet Development, and I have already shared an overview of this methodology on the CS345/545 course blog. In writing that post, I came across an interesting article on Tracer Bullet Development vs. Extreme Programming by Martin Ankerl. The two approaches are significantly different, with TBD encouraging some upfront design (though accepting the agile principle that interfaces will change) and XP encouraging evolutionary design (primarily user story and test-driven).

Either of these are good candidates for CS222, in my opinion. An advantage of TBD, pointed out by Ankerl, is that it facilitates parallelization. I certainly want CS222 students to learn how to work in teams, and so having a methodology that makes it easy to break pieces off for different developers is very important. However, TBD also requires some savvy with design, and the students will be coming fresh out of CS2. Software design—in the software engineering sense—is not a major topic of CS222. Learning-by-doing is important, but there is a simple elegance to scenario-driven design in XP. Unit testing and test-driven development are elements that I would like to explicitly include in 222, and so that makes me lean towards XP.

Fall 2010 looks like a lifetime away from here, but I have started keeping more notes on what I’d like to do with 222. These include: effective use of the IDE; interactive debugging; test-driven development; scenarios and user stories; how to read technical books; and the differences between CS1/2-style programming and writing real software. I had thought about trying to get a GA to make this a real qualitative research study, but I don’t think I’ll have the time to get that together.

I’m happy to hear your thoughts in the comments below, kind reader. For BSU-affiliated folks, I am planning on soliciting feedback from current students (e.g. ask current juniors and seniors what they wish they had learned in their sophomore year regarding advanced programming topics) as well as alumni. I’ll probably use our nifty new Facebook group for that.