Over the Thanksgiving break, I bought one non-food item: a real book, printed on dead trees, and purchased from a brick-and-mortar store (albeit one in a brand new development with a “Main Street” that really isn’t a Main Street at all).

The book is Michael Pollan’s A Place of My Own, which I approach with both interest and trepidation as one who is partway through the process of designing and building a new home. I was surprised to find connections with software development and with my enterprise at Whitman.

A paragraph in the first chapter starting my musing. Pollan is explaining his decision to build his house with his own two hands, despite having neither experience with nor aptitude for building. He writes:

Of course I knew something about gardening. And while it seems to me building has some striking things in common with gardening–both are ways of giving shape to a landscape; of joining elements of nature and culture to make things of usefulness and beauty; of, in effect, teasing meaning from a tree—the intellectual and physical abilities each discipline calls for could scarcely be more different. In the garden a casual approach to geometry, a penchant for improvisation, and a preference for trial and error over the following of directions will rarely get you into serious trouble. Building a house is another story. It seemed to me that the difference between gardening and building was a little like the difference between cooking (which I like to do) and baking (which I can’t), a difference that has everything to do with one’s attitude towards recipes. Mine has always been cavalier.

Reading this soon after waking in the early (okay, mid-morning) hours of Sunday, I was struck by a parallel to software development practices. We often speak of “building” software. Indeed, the traditional approach to large-scale software development is modeled after building or engineering: A process that moves sequentially through stages of articulating requirements, analysis, design, construction, testing, and deployment. This is commonly referred to as the waterfall model of software development, as the stages follow one after another in a cascade.

But around the time I was starting graduate school, a new model emerged in the Manifesto for Agile Software Development. The Agile philosophy has much in common with gardening: It approaches software development as an iterative process, with continuous improvement as its goal. Done well, each short iteration includes all of the traditional stages of software development. Agile practices are intended to respond to an ever-changing environment—not the weather, but changing technologies, needs, and opportunities. The approach recognizes that much is unknown at the beginning of design; we learn from making changes, observing the outcomes, and reflecting on how these outcomes meet or fall short of our goals.  Compared to a house or a bridge, software is fluid and malleable, easily changed. Indeed, many question whether software engineering is really engineering at all.

The Agile or “gardening” model has resonated with me since I first learned about it from my academic siblings, Bjorn Freeman-Benson and David Socha, who served as professional software engineers on the UrbanSim project where I did my dissertation work. Each time I’ve taught a class on software development, I’ve taught an Agile approach. I find it works well in the classroom: It requires students to set small, achievable goals. It provides them an opportunity to reflect and improve upon their decisions and processes.

At the same time, I encourage my students to consider the value of the waterfall or “building” model in one-shot or safety-critical applications where failure is not an option: pacemakers, space probes, air traffic control, and so on. Some things have to be designed before they are built. Some argue that even within the Agile approach, there is a need to do just enough design initially, to make well the choices that are hard to change later. I would agree.

I like to make things (in fact, that’s why I became a computer scientist) and I appreciate the need for building.  I like both baking and cooking, and I think I’m equally good at both. Yet, I more easily see myself as a gardener than as a builder. Part of my job as a teacher is to create things that are brand new, but more of it is tending, nurturing, curating, and revising. I am also, literally, a gardener. Last summer, I regretfully left behind my garden in Grinnell, and I’m already dreaming about the garden that Brooks and I will create in Walla Walla. My favorite things to do in the garden are planting and pruning. I love the process of designing as I go along, learning from the plants and the site—and most of all, from my mistakes. (My approach to plant selection is influenced more by Darwin than Mendel.) That said, we want to have an overall plan for our landscape design, a structure to improvise upon, to refine and adapt.

These musings eventually brought me to the topic of this blog. I’ve often spoken of “building” a new CS program at Whitman. But is an academic program something that can be built, or is the process more like gardening?

I can envision a moment in the future when I can say I have built the program: When I have hired colleagues, designed a curriculum, offered courses, recruited students, created a department. (Of course, all those things will be done with colleagues, not by myself alone.) At the same time, that moment might be hard to pin down, and the work certainly won’t be done.  We won’t get the curriculum or courses perfect the first time—indeed, there’s no such thing as “perfect,” only more or less effective for meeting particular goals—so there will always be revisions to make. As my friend and former colleague Henry Walker likes to say, what all successful programs have in common is that they are never satisfied. There will be more colleagues to hire, nurture, and mentor (I hope!). A thriving community and collegial relationships must be tended and cared for, or they will wither and die. So perhaps my job here is to lay the groundwork and grow a program.

In other news: I will be teaching a new section of CS 167 at 8 a.m. TThF. It’s nearly full at 29/30 students. Albert Schueller will be teaching the first section at 10 a.m. 17 students remain on the waiting list.

One section has 11 women and 19 men; the other has 14 women and 15 men. I hope to figure out how to carry that gender parity beyond the introductory course.

I got to guest-lecture in Yaping’s classes this week. I discovered I’m still learning about our new teaching labs and how they can be improved. That post remains next on my list!