The merger came as a surprise to many of us on campus, so there is a lot to do beyond simply combining operating budgets and clerical staffs. I expect everything to work out fine in the end. Colleges of arts and sciences are a common way to organize universities like ours, both of the existing colleges contain good people and many good programs, and we have a dean especially well-suited to lead the merger. Still, the next eighteen months promise to deliver a lot of uncertainty and change. Change is hard, and the resulting college will be something quite different from who we are now. Part of me is excited... There are some immediate benefits for me and CS, as we will now be in the same college with colleagues such as Roy Behrens, and with the departments with whom we have been working on a new major in digital media. Multidisciplinary work is easier to do at the university when they fall under the same administrative umbrella.

We are only getting started on working toward the merger, but I've already noticed some interesting differences between the two faculties. For example, at the first meeting of the department heads in my college with a faculty leader from the other college, we learned that the humanities folks have been working together on a college-wide theme of internationalization. As part of this, they have been reading a common book and participating in reading groups to discuss it.

This is a neat idea. The book provides a common ground for their faculty and helps them to work together toward a common goal. The discussion unifies their college. Together, they also create a backdrop against which many of them can do their scholarly work, share ideas, and collaborate.

Now that we are on the way to becoming one college, the humanities faculty have invited us to join them in the conversation. This is a gracious offer, which creates an opportunity for us all to unify as a single faculty. The particular theme for this year, internationalization, is one that has relevance in both the humanities and the sciences. Many faculty in the sciences are deeply invested in issues of globalization. For this reason, there may well be some cross-college discussion that results, and this interaction will likely promote the merger of the colleges.

That said, I think the act of choosing a common book to read and discuss in groups may reflect a difference between the colleges, one that is either a matter of culture or a matter of practice. For the humanities folks, this kind of discussion is a first-order activity. It is what they do within and across their disciplines. For the science folks, this kind of discussion is a second-order activity. There are common areas of work across the science departments, such as bioinformatics, but even then the folks in biology, chemistry, computer science, and math are all working on their own problems in their own ways. A general discussion of issues in bioinformatics is viewed by most scientists as about bioinformatics, not bioinformatics itself.

I know that this is a superficial analysis and that it consists of more shades of gray than sharp lines. At its best, it is a simplification. Still I found it interesting to see and hear how science faculty responded to the offer.

Over the longer term, it will be interesting to see how the merger of colleges affects what we in the sciences do, and how we do it. I expect something positive will happen overall, as we come into more frequent contact with people who think a little differently than we do. I also expect the day-to-day lives of most science faculty (and humanities faculty as well) will go on as they are now. Letterhead will change, the names of secretaries will change, but scholarly lives will go on.,

The changes will be fun. Getting out of ruts is good for the brain.

While thinking about my 1000th post, I decided to take a look back at the other digits:

• 100: Strange Blogging Occurrences
• 10: Algorithmic Patterns
• 1: Joining the Fray

Number 100 refers to #99, a review of the Kary Mullis's Dancing Naked in the Mind Field. That article, in combination with the entries on algorithmic patterns and textbooks, seems pretty consistent with how I think about this blog: ideas encountered, considered, and applied. Looking at numbers 1 and 10 led to me to read over the monthly archive for July 2004. Revisiting old thoughts evokes -- or creates -- a strange sort of memory, one that I enjoy.

I hope that the next 1000 entries are as much fun to write.

My goal for February is steady running; my hope is to increase my mileage slowly but steadily into the mid-30s, where I like to be in the winter. My next big trip is planned for SIGCSE 2010 in Milwaukee, which has a river and a riverwalk. I love to explore new cities on foot.

If we can provide books on a general-purpose computer, we have so many options available. Kim mentions one: replacing graphics with animations. Rather than seeing a static picture of the state of some computation, they could watch the computation unfold, with a direct connection to the code that produces it. This offers a huge improvement in the way that students can experience the ideas we want them to learn. You can see this difference in examples Kim posted of his printed textbook and his on-line lecture notes.

Right now, authors face a challenging practical obstacle: the lack of a standard platform. If a book requires features specific, say, to an iPad or to Windows, then its audience is limited. Even if it doesn't but a particular computer doesn't provide support for some near-standard technology, such as Flash on the Apple products, then users of those products are unable to access the book their devices. It would be nice to have an authoring system that runs across platforms, transparently, so that writers can focus on what they want to write, not on compatibility issues.

As Kim points out, we can accomplish some of this already on the web, writing for a browser. This isn't good enough, though. Reading long-ish documents at a desktop computer through a browser changes the reading experience in important ways. Our eyes -- and the rest of our bodies -- need something more.

With the evolution of handheld devices toward providing the full computational power we see on the desktop, our ability to write cross-platform books grows. The folks working on Squeak, Croquet, Sophie, and other spin-off technologies have this in mind. They are creating authoring systems that run across platforms and that rely less and less on underlying OS and application software for support.

As we think about how to expand the book-reading experience using new technologies, we can also see a devolution from the other side. Fifteen years ago, I spent a few years thinking about intelligent tutoring systems (ITS). My work on knowledge-based systems in domains such as engineering and business had begun to drift toward instruction. I hoped that we could use what we'd learned about knowledge representation and generic problem-solving patterns to build programs that could help people learn. These systems would encode knowledge from expert teachers in much the way that our earlier systems encoded knowledge from expert tax accountants, lawyers, and engineered.

Intelligent tutoring systems come at learning from the AI side of things, but the goal is the same as that of textbooks: to help people learn. AI promised something more dynamic than what we could accomplish on the printed page. I have not continued in that line of work, but I keep tabs on the ITS community to see what sort of progress they have been making. As with much of AI, the loftiest goals we had when we started are now grounded better in pragmatics, but the goal remains. I think Mark Guzdial has hit upon the key idea is his article Beat the book, not the teacher. The goal of AI systems should not be (at least immediately) to improve upon the perfomance of the best human teachers, or even to match it; the goal should be to improve upon the perfomance of the books we ask our students to read. This idea is the same one that Kim Bruce encourages us to consider.

As our technology evolves in the direction of reasonably compact mobile devices with the full computational power and high-fidelity displays, we have the ability to evolve how and what we write toward the dream of a dynabook. We should keep in mind that, with computation and computer programming, we are creating a new medium. Ultimately, how and what we write may not look all that much like a traditional book! They may be something new, something we haven't thought of yet. There is no reason to limit ourselves to producing the page-turning books that have served us so well for the last few centuries. That said, a great way to move forward is to try to evolve our books to see where our new technology can lead us, and to find out where we come up short.

I'm always glad to see examples of fellow computer scientists with interests and accomplishments in the humanities. Just as humanists bring a fresh perspective when they come to computer science, so do computer scientists bring something different when they work in the humanities. Mason's background in AI could well contribute to how he approaches Odysseus's narrative. Writing programs that make it possible for computers to understand or tell stories causes the programmer to think differently about understanding and telling stories more generally. Perhaps this experience is what enabled Mason to "[pose] new questions to the reader about art and originality and the nature of storytelling".

Writing a program to do any task has the potential to teach us about that task at a deeper level. This is true of mundane tasks, for which we often find our algorithmic description is unintentionally ambiguous. (Over the last couple of weeks, I have experienced this while working with a colleague in California who is writing a program to implement a tie-breaking procedure for our university's basketball conference.) It is all the more true for natural human behaviors like telling stories.

In one of those unusual confluences of ideas, the Times book review came to me the same week that I read Peter Merholz's Why Design Thinking Won't Save You, which is about the value, even necessity, of bringing different kinds of people and thinking to bear on the tough problems we face. Merholz is reacting to a trend in the business world to turn to "design thinking" as an alternative to the spreadsheet-driven analytical thinking that has dominated the world for the last few decades. He argues that "the supposed dichotomy between 'business thinking' and 'design thinking' is foolish", that understanding real problems in the world requires a diversity of perspectives. I agree.

For me, Kakutani's and Merholz's articles intersected in a second way as I applied what they might say about how we build software. Kakutani explicitly connects author Mason's CS background to his consideration of narrative:

["Lost Books" is] a novel that makes us rethink the oral tradition of entertainment that thrived in Homer's day (and which, with its reliance upon familiar formulas, combined with elaboration and improvisation, could be said to resemble software development) ...

When I read Merholz's argument, I was drawn to an analogy with a different kind of writing, journalism:

Two of Adaptive Path's founders, Jesse James Garrett and Jeffrey Veen, were trained in journalism. And much of our company's success has been in utilizing journalistic approaches to gathering information, winnowing it down, finding the core narrative, and telling it concisely. So business can definitely benefit from such "journalism thinking."

So can software development. This passage reminded of a panel I sat on at OOPSLA several years ago, about the engineering metaphor in software development. The moderator of the panel asked folks in the audience to offer alternative metaphors for software, and Ward Cunningham suggested journalism. I don't recall all the connections he made, but they included working on tight deadlines, having work product reviewed by an editor, and highly stylized forms of writing. That metaphor struck me as interesting then, and I have since written about the relationship between software development and writing, for example here. I have also expressed reservations about engineering as a metaphor for building software, such as here and here.

I have long been coming to believe that we can learn a lot about how to build software better by studying intensely almost every other discipline, especially disciplines in which people make things -- even, say, maps! When students and their parents ask me to recommend minors and double majors that go well with computer science, I often mention the usual suspects but always make a pitch for broadening how we think, for studying something new, or studying intensely an area that really interests the students. Good will come from almost any discipline.

These days, I think that making software is like so many things and unlike them all. It's something new, and we are left to find our own way home. That is indeed part of the fun.

These days, I believe the key difference between practice, value and principle (something much debated at one time in the XP community and elsewhere) is simply how likely we are to adjust them if things are going wrong for us (i.e., practices change a lot, principles rarely). But none should be immune from our consideration when our actions result in negative outcomes.

To the list of practice, value, and principle, pragmatists like Peirce, James, Dewey, and Meade would add knowledge. When we focus on their instrumental view of knowledge, it easy to forget one of the critical implications of the view: that knowledge is contingent on experience and context. What we call "knowledge" is not unchanging truth about the universe; it is only less likely to change in the face of new experience than other elements of our belief system.

Caputo reminds us to be humble when we work to help others to become better software developers. The old pragmatists would concur, whether in asking us to focus on behavior over belief or to be open to continual adaptation to our environment. This guidance applies to teaching more than just software development.

Perhaps this is why a particular passage from an entry on urban planning policy at The Urbanophile keeps coming to mind. It offers a lesson for urban policy based on the author's reading of Dietrich Dörner's The Logic of Failure (a new addition to my must-read list):

The first [lesson] is simply to approach urban policy and urban planning with humility and rich understanding of the limits of what we can accomplish. This I think is desperately needed. There are so many policies out there that are promoted with almost messianic zeal by their advocates.

One person's messianic zeal, unfettered from reality, is a dangerous force. It can wear out even a resolute team; when coupled with normal human frailty, the results can destroy opportunities for progress.

Another passage from the same blog has had a more personal hold on me of late:

People with talent, with big dreams and ambitions, want to live in a place where the civic aspiration matches their personal aspirations.

Sense of place and sense of self are hard to separate. This is true for cities -- the great ones capitalize on the coalescence of individual and communal aspiration -- and for academic departments.

When we consider the full effect of the Internet, as Shirky does in his essay, we think of its effect on the ability of individuals to share their ideas widely and to connect those ideas to the words of others. From the perspective of a computer scientist, I think of programming as a form of writing, as a medium both for accomplishing tasks and for communicating ideas. Just as the Internet has lowered the barriers to publishing and enables 8-year-olds to become "global publishers of video", it lowers the barriers to creating and sharing code. We don't yet have majority participation in writing code, but the tools we need are being developed and communities of amateur and professional programmers are growing up around languages, tools, and applications. I can certainly imagine a YouTube-like community for programmers -- amateurs, people we should probably call non-programmers who are simply writing for themselves and their friends.

Our open-source software communities have taught us not only that "collaboration between loosely joined parties can work at scales and over timeframes previously unimagined", as Shirky notes, but other of his lessons learned from the Internet: that sharing is possible in ways far beyond the 20th-century model of publishing, that "post-hoc peer review can support astonishing creations of shared value", that whole areas of human exploration "are now best taken on by groups", that "groups of amateurs can sometimes replace single experts", and that the involvement of users accelerates the progress of research and development. The open-source software is a microcosm of the Internet. In its own way, with some conscious intent by its founders, it is contributing to creation of the sort of Invisible College that Shirky rightly points out is vital to capitalizing on this 500-year advance in man's ability to communicate. The OSS model is not perfect and has much room for improvement, but it is a viable step in the right direction.

All I know is, if we can put the power of programming into more people's hands and minds, then we can help more people to have the feeling that led Dan Meyer to write Put THAT On The Fridge:

... rather than grind the solution out over several hours of pointing, clicking, and transcribing, for the first time ever, I wrote twenty lines of code that solved the problem in several minutes.

I created something from nothing. And that something did something else, which is such a weird, superhuman feeling. I've got to chase this.

We have tools and ideas that make people feel superhuman. We have to share them!

Due to an unexpected but welcome uptick in enrollment across the department, I will also be team-teaching a 10-week course on Cobol. We are one of the few CS programs that still try to offer Cobol, and when our attempt this time resulted in a class large enough to run, we didn't want to cancel it.

01  SWITCHES.
    05  EOF-SWITCH              PIC  X          VALUE "F".
        88  AT-END-OF-FILE                      VALUE "T", "t".

It's been a long time since I have spanned two such different languages in the same semester. I'll have to resist the urge to implement curried paragraphs in Cobol, though try to replicate Cobol's Data Division magic in Scheme might be fun. It will certainly underscore just how different a couple of Cobol's features are from what students encounter in modern languages. It will be interesting to see how my time thinking about Cobol will affect what I say and do in Programming Languages.

All groups have their internal politics. Some political situations are short-lived; others are persistent, endemic. We are no different, and maybe even above average. (Someone has to be!) Political struggles take time and energy. They steal focus.

I think everyone in our group desires to be great. Unfortunately, that's the easy part. For a group to achieve greatness, individuals must work together in a common direction. In our group, it is hard to build consensus on a shared vision. I don't pretend that once we share a vision that greatness will come easily, but it's hard to get anywhere unless everyone is trying to go to the same place -- or at least is using the same criteria for progress.

As for me, in my role as department head, I have not always found -- or created -- the will, the energy, or the tools I need to help us move confidently in the direction of greatness. So, at times, we seem to settle, working locally but not globally.

This train of thought reminds me of a couple of comments James Shore made about stumbling through mediocrity in the context of agile software development:

The emphasis [in the software world] has shifted from "be great" to "be Agile." And that's too bad. As much as I like it, there's really no point in Agile for the sake of Agile.

The point is to be great, or perhaps more accurately, to do great things. Agile approaches are a path, not a destination.

I want to work with people who want to be great. People who aren't satisfied just fitting in. People who are willing to take risks, rock the boat, and change their environment to maximize their productivity, throughput, and value.

One of the things that has surprised me so much about group dynamics since I joined a faculty and perhaps more so since I've been in the position of head is the enormous role that fear plays in how individuals work and interact with one another. It takes courage to take risks, to rock the boat, and to change the environment in which we live and work. It takes courage to be honest. It takes courage to take an action that may make a colleague or supervisor unhappy.

Without courage, especially at key moments, opportunities pass, sometimes before they are even recognized.

I have experienced this in how I interact with others, and occasionally I observe it how colleagues interact with me and others. I never thought that this would be a major obstacle on my path to greatness, or my department's.

(For what it's worth, Shore's second passage also describes the kind of students I like to work with, too. If it is hard for experienced adults to have this sort of gumption, imagine how much tougher an expectation it is to have of young people who are just learning how to step out into the world. Fortunately, as teachers, we have an opportunity to help students grow in this way.)