October 31, 2004 4:38 PM

Running on the Road: Vancouver, British Columbia

(The third stop in the Running on the Road series. The first two were Allerton Park, Illinois, and Muncie, Indiana.)

As we chatted before his address to the OOPSLA Educators Symposium last week, Alan Kay said "Canadians really know how to do big cities." He's certainly right about Vancouver. It is a great place for a conference.

Do you see the little sail-like structures in the middle of the picture at the right? The tall building just to their left is the Pan Pacific hotel, which is where I stayed on my last two visits to British Columbia. It's a luxury hotel, more expensive than my taste for paying but just right for my taste for enjoying life.

Now, look to green patch near the middle of the photo. That is Stanley Park, a gem in the crown of urban parks. Among its many charms is a 10km seaside trail for running and biking, along with numerous roads and paths that criss-cross the wooded acres. It's the best place to run in the so-called north mainland of Vancouver.

Stanley Park

The 10km seaside trail is a wonderful run, flat and scenic. You'll run by and under a couple of small lighthouses that alert the bays many vessels to steer clear of the peninsula. You'll run past a couple of commemorative statues and even a children's park.

Add in the 1.25-mile jog from the Pan Pacific area to make a nice 8.5 miler. In previous trips, I've thrown in a second loop to make a 15-miler. Run the trails up to Prospect Point, far and away the highest point in Vancouver, to add some challenging hillwork to your workout. Some of those trails seem nearly vertical... Mix in some minutes running on the interior streets and trails of the park to craft a variety of runs up to the distance of your choice.

On my most recent trip, I continued my recovery from the Des Moines Marathon with three of the simple 8.5-milers, in 72, 70, and 78 minutes, respectively. They were my longest runs since the race, and that middle one was my fastest, too.

False Creek

False Creek is an inlet from the bay to the west of Vancouver, separating the north mainland of the convention center and Pan Pacific Hotel from the south mainland of commerce and residence. There is a an 8km loop around False Creek from the Burrard Street Bridge on the west around the inlet and back. I ran south down Burrard Street, which terminates less than a block west of the Pan Pacific, about one mile to the Burrard Street Bridge, to connect with the shore trail around False Creek. That all-urban connection is just about a mile long, with a few small hills making it interesting.

The photo to the left shows you what early morning runs through the city look like. You can even see this panaorama from the southeast corner of the False Creek loop.

I didn't know how to get straight on the loop after crossing to the south side of the bridge, so I ended up running a little bit more than planned around a Molson brewery and through some seaside businesses. Eventually I found the paved seawalk and began my big lap.

As I wrote earlier, this coastline run is a mix of urban park, pretty modern buildings, and occasional industrial spaces. It's not as undisturbedly scenic as Stanley Park, but it gives you a more complete sense of what Vancouver is.

With my fumbling around at the beginning of the loop, I ended up with a nice 72-minute run -- right in line with my other runs this week.

In my three trips to Vancouver, I've never had a chance to venture beyond the north mainland. The mountain view to the right hint at some of the other sights and activities to be had in this beautiful city. In the future, I hope to take in a cruise on the bay, hike in the mountains, visit other parts of the region -- and run all over place, of course.


Posted by Eugene Wallingford | Permalink | Categories: Running

October 31, 2004 4:15 PM

Software Development Fantasies

Don't worry. This entry is rated G, for general audiences.

The last session of the Onward! track at OOPSLA was a panel-turned-open-mike called Breakthrough Ideas. The idea was simple: Anyone could take the mike for four minutes or less and propose something that would, if true or made so by future development, fundamentally alter the way we use computers, program them, or view computation. The four-minute limit was strictly enforced in order to cycle through as many ideas as possible in the ninety minute session, and to prevent the inevitable rambling that ensues when some of us start talking about some idea yet ill-formed in our minds. The format can't eliminate rambling, only cut it off.

A few of the proposed ideas made me smile and want to think about them further:

  • programmed program death: build into each piece of code an expiration date or a dying process so that, at the appointed time, the code goes away. (So much for the Y2K problem!)
  • a Pulitzer Prize for wonderful code, code that is elegant, understated, understandable, beautiful. The genre categories might be application areas or, more likely, languages. In order to appreciate the beauty of most code, you have to speak the language.
  • program our computer tools to ask us questions, rather than waiting for us to fill in every details and, in the process, make mistakes.
  • programming on the model of a research professor: when you need a program, you delegate to a graduate student. What would that be like between me and my computer?
  • an oldie but a goodie: the whiteboard compiler.

    But maybe we are getting closer on this one... A poster on the Squeak list recently said that he now uses Squeak for much of his creative work. He can't throw his pencils and paper out quite yet, but he feels like he's getting closer. Alan Kay's talks certainly encouraged us to think about how we can make progress toward this goal.

Some other ideas immediately became questions in my mind, either because I didn't understand the proposal or because the proposal really was a question.

What would it be like to write software on the model of living organisms? Software these days has hard edges -- rigid interfaces -- that delineate the boundaries of each functional component, which does its job and nothing else. But biological systems have soft edges and seem to operate on the premise that components fail all the time. (See Brian Marick's body-as-kludge article.) Their components also differ from software in that, say, a liver consists of oodles of liver cells, none of which are a liver but which in concert act as a liver -- with primary and secondary and tertiary functions intermingled.

Finally, what would you do if you knew that one billion people would use your software? For starters, you would probably have to make the program multilingual down to its foundations... Or would you?

I think it's neat that some people think thoughts like these, and that at least a few of them are even actively pursuing answers...


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 30, 2004 11:44 AM

FrameGames!

Steve Metsker and Bill Wake led a fun games session at the Educators Symposium last week. Not only did we play four games, but Steve and Bill taught us a way to generate more games of the same sort. The games we played were instantiations of what they call frames, which work a lot like frameworks in object-oriented programming. Each frame is a partially-defined game, with the primary control rules built into the frame. To create a new game, you simply fill in the missing content on which the rules act. You can, of course, specialize or override one or more of the rules if that best suits your context.

As an example, consider the first frame we learned, Best Fit, which is adapted from the game Apples to Apples. Apparently, Apples to Apples has been a popular party game in recent years, though I hadn't heard of it. In Best Fit, the game master sets up the game by creating a set of five adjectives, say, "confusing", "underrated", "specialized", "inspiring", and "weird". Players break off into groups of five or so. They create twenty noun cards, say, the names of twenty famous computer scientists. (Can you name 20? That seemed to be a challenge for some folks at the symposium!) The name cards are shuffled and dealt to the players.

Play proceeds as a sequence of 'tricks' in which one of the adjective cards is revealed and each player plays the card from his or her hand that best fits the adjective. Players take turns sitting out of tricks and acting as judge -- which player has played the noun that best fits the adjective in play? Variations include allowing lobbying or not and disqualifying the last card played from judging (in order to encourage rapid recognition and a little excitement, I presume). Winning and losing the game is less important than the thinking that goes into playing nouns and judging fit. Though we didn't discuss debriefing the game, I imagine that doing so would give the class as a whole a chance to explore the content of the game at a deeper level.

From the teacher's perspective, the idea behind the frame is that the adjectives and nouns can be just about anything. We played a second instance in which the nouns were algorithms and the adjectives were big-oh classes and other characterizations of of algorithms. Creating a new game is as easy as choosing suitable nouns and adjectives from any area of study.

The second frame we learned is Envelopes, attribute to a fellow named Thiagi. In this game, three groups of five players or so each compete to produce the best answer to a question written on the outside of an envelope. The game master prepares three envelopes, each with a different question on the outside. In round one, each team is given an envelope, drafts an answer to its question, writes it on an index card or sheet of paper, and stuffs it into the envelope. For the second round, each team passes its envelope to another group, which does the same thing the first team did, without looking inside the envelope. In the third round, the envelopes are again passed to the group that has not yet seen the question. Instead of answering the question, this time the group takes the two answers from the envelope and judges which one is better.

Teams score points for having their answers selected as the winner. The game can consist of any number of rounds. Again, debriefing may well add learning value, as players explore why one answer was judged better than another or what the nuances in the question are. And, again from the teacher's perspective, creating new instances of Envelopes is as easy as drafting three questions that require some thought and that can lead to useful discussion of course material. Heck, three good midterm questions might do the job just fine.

Maybe I will break the tension of one of my classes later this semester with an instance of one of these games.

Bill said that he will post the slides of their presentation to us on his XPlorations web site soon.


Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

October 30, 2004 11:33 AM

My First Blog Rant

Okay, I don't think I've ever blogged just to vent my frustration with people in this world. The blogosphere is full of blogs that are nothing but. They wear thin really quickly. But if you ask my wife, she'll tell you that I save my rants for her weary ears.

Here is my first rant blog:

People, turn your #$!@%#^@*&$#*^@# cell phones off when you enter a public space.

I have had students' cell phones go off in my class, and I've been patient and generous in my assessment of the situation. They meant to turn them off, surely, or thought they had. I've heard them in theaters and in churches and at public talks. Each time, I wonder about the rudeness or inflated sense of importance that makes people think that they can impose on everyone else around them.

The final straws fell last week at OOPSLA when a cell phone went off during Alan Kay's keynote address -- and then twice during his Turing Award lecture! How rude, self-important, or utterly stupid do you have to be to let your phone be the second to ring during a historic lecture?

And what's worse, two of those people took the calls before leaving the room. Amazing.

I know that this rant is cliché these days. Everyone complains about cell phone users. I've been muttering about them under my breath for a while myself. But each man has his breaking point, and I'm at mine. The people whose phones interrupted Alan Kay's talks last week are lucky that the only thing broken was my temper, and not their phones.

Okay, I feel better now.


Posted by Eugene Wallingford | Permalink | Categories: General

October 30, 2004 11:26 AM

Knowing and Seeing

Brian Marick's talk on methodology work as ontology work sounds more forbidding than it is. His central point is this: whenever adopt a particular software development approach, or create a new one (that's the methodology part), we implicitly take on, or promote, a particular way of seeing the world (that's the ontology part). One implication of this is that communication between folks in different methodology camps -- say, XPers and more traditional software engineers -- is often difficult precisely because these folks see the world differently. They can look at the same project or team or testing scenario and see different things. To help such folks communicate better, you must often help them to build a common vocabulary, or at least recognize the names collisions in their individual vocabularies.

Coming to know is to change how we perceive the world.

Those of us in AI community came to learn this up close and personal through the 1970s, '80s, and early '90s. While many of us built useful and usable knowledge-based systems using techniques that codify knowledge in the form of rules or other explicit structures, we soon learned the limits of these approaches. Experts don't have rules for doing their job; they just do it. The same is true for everyday knowledge. You don't have an algorithm for determining whether you are tired. You merely know it.

Merely. In learning, you lose the rules and learn to see something new.

Another implication of this view is that we can often use perception to drive behavior better than rule-based prescriptions. Brian gave two examples:

  • Big Visible Charts are a better way for a team to know the bugs that need to be fixed than annotations in code like "TODO" comments.
  • JUnit's red bar/green bar metaphor is better than just a numeric output on a list.

As always, I liked Brian's talk for his broad scholarship and skills making connections. For example, I learned that scientists like research programs:

  • that have a "hard core", a small, tightly connected set of assumptions. This point echoed Alan Kay's love of "kernels" such as Maxwell's equations.
  • that work out consequences of their theories and 'ignore' counterexamples as potential refutation. That sounds counter to what we often learn about the falsifiability of scientific theories, but it is really a sign of a deep commitment to the simple idea that underlies a theory.
  • that make novel or surprising predictions which are subsequently confirmed. One such confirmation can often trump dozens of little counterexamples based on the details of a theory's explication.

We have a lot to learn from the philosophy of science.


Posted by Eugene Wallingford | Permalink | Categories: Software Development, Teaching and Learning

October 28, 2004 7:30 PM

OOPSLA Is Over

My access to wireless at OOPSLA is coming to a close. I have a few ideas burning in my mind to be written about, but they will have to wait until I have time while traveling home tomorrow. For now, let me just say good-bye to the conference.

At the beginning of his talk, which I wrote about earlier, Ward said: OOPSLA is about programming on the edge, doing practical things better than most.

In a panel on the second day, Ralph said that, in some ways, objects were just the excuse for OOPSLA, not the reason. The real reason was hanging around with people doing interesting things, especially people interested in talking about and studying real programs.

OOPSLA is a unique conference for the sort of people it attracts. I had the honor of lunching with David Ungar today, and he asked everyone, "What has inspired you this work? What do you want to rush home and work on?" The best thing you can say about a conference is that it does inspire you to hurry home and explore some new problem or approach, or write a new program. OOPSLA does that for me every year. I'll take time to write down tomorrow how OOPSLA has inspired me, but for now I can at least say that examples play a big role in my answer. Well, at least one of my answers.


Posted by Eugene Wallingford | Permalink | Categories: General

October 28, 2004 1:26 PM

Requiem for a Power Adapter

So, why didn't I post my last blog entry when written? I broke my G3 Powerbook's power adapter. As I was putting the laptop away after the OOPSLA 2005 planning BoF, I stretched the adapter end of the cord a bit too far, and the internal wire cable snapped.

Were I living in the 21st century and using any of the more recent PowerBook or iBook models, I would only have had to worry about charging up for the flight home. There are 1436 people at OOPSLA this year, and there must be 1000 Mac laptops here. With the maturity of Mac OS X, Apple has really made inroads into the technical community, at least some of the more advanced technical folks. If you can have a fully-featured Unix OS, a wonderful Apple interface on top, and out-of-the-box wireless, why not pay a few extra bucks and get the Mac?

But no, I am still using my 1999-era PowerBook, and its power adapter is incompatible with all more recent models. And I've only seen two other people using one here. Many folks I know prefer the stylish and sexy little silver disk of the older PowerBooks, with its compact cord winding. That is no consolation when a man has a single battery holding only a 40% charge, facing a day of conference and day of travel, and with a suddenly apparent reliance on his laptop, felt deeply within his bones.

So I retired to my room last night fretting about the future. In order to preserve the remaining juice in my PowerBook, I resorted to an ancient technology -- the phonebook -- in hope of finding an authorized Apple dealer within walking distance of my hotel, in a secondary hope that the dealer will have in stock a power adapter for my dinosaur.

The gods smiled on me. Perhaps it was a birthday gift for me. I found an entry for the Mac Station, a mile or so from the hotel. So I planned my morning around a jaunt in that direction.

After several days of beautiful sunshine, I awoke to a day of rain. I put in an 8.5-mile jog around Stanley Park, grabbed some breakfast, threw on a jacket, and headed out into the mist. The walk was worth twenty minutes, as I saw the edge of Vancouver's Chinese district, some of its banking district, and its impressive six-story public library. I arrived at 9:02 AM -- and found that the store opens at 10:00 AM. The gods may be friendly, but they have a sense of humor, too.

So I headed back to the library to fill the time reading Jutta Eckstein's new book. But the library opens at 10:00 AM, too, so I bought a soda and sat in a small cafe for a while.

Back to the Mac Station. I arrive right at 10:00 to find them opening the front gate. Inside -- and joy. They don't carry an OEM power adapter for my model, but they do have a third-party product in stock. The price is a bit steep for my tastes ($130 Canadian), but an addict will pay the price for his next fix. We tried it out in the store -- I'm overly cautious sometimes -- and it worked just fine. Relief.

I'm back at OOPSLA now, in an Onward! session of outlandish wishes. I'm on wireless. All is right with the world, at least for a few minutes.

My new power adapter isn't as pretty as my old one, and I'll miss that. I know that Windows and Linux folks are used to pedestrian, merely functional, boring at best and ugly at worst components, but I'll miss my silver disk.


Posted by Eugene Wallingford | Permalink | Categories: General

October 28, 2004 12:39 PM

The Experience of Programming

[ I wrote this last night but wasn't able to post it then. Why? Stay tuned. ]

After the Steve McConnell talk this morning, I went to three technical events:

  • an Onward! session on changing the experience of programming.

    Jonathan Edwards talked about example-centric programming, and in particular two tools he has built: EG, an Eclipse plug-in for integrating examples directly into code and the IDE, and subtext, a language for programming in an example-centric way. The neat idea here is one I've seen elsewhere, that text strings are not the right way to represent programs. A structured format offers some interesting possibilities for writing code.

    David Hovemeyer spoke about FindBugs, a static analyzer of Java programs that finds common bugs based on common bug patterns the authors have identified.

  • an Onward! panel on transforming the software lifecycle. It was entertaining in a way, but I have nothing to say about it.
  • a panel on whether software development is (math and science) or (arts and crafts). Engineering wasn't in the title, which upset a few folks. The panel was high-powered -- Robert Biddle, Martin Fowler, Dick Gabriel, Ralph Johnson, and Steve McConnell -- and there was some interesting stuff said, especially by Biddle on English literature -- but mostly it didn't give insights that haven't been given before at many events of this sort. The key lesson is something I blogged a couple of weeks ago: Metaphors can both help and limit us in our discovery. Use with care.

The evening has been BoFs. The first was for the Domain Driven Design community. Eric Evans published the marvelous book of this title last year (read it!), and he has cultivated an on-line community around the idea. I have volunteered to help out by serving as an editor and light writer for the FAQ on the web site's wiki. I have so much free time... but this is an idea and a community I want to support.

The second -- going now -- is for planning the OOPSLA 2005 conference. I agreed to chair the Educators Symposium again. Giddy-up!

Up next is a fun event at the Vancouver Aquarium, of which I've heard many good things. I'm ready for a break.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 27, 2004 1:11 PM

Steve McConnell on the Realities of Software Construction

Let's try this blogging thing in real time. Steve McConnell, author of the recent bestseller Code Complete 2, is giving the opening talk for Day 2 of OOPSLA. The first edition of Code Complete is a classic in the field, still cited by software engineers and practitioners.

McConnell opened with some humor on the hazards of renaming a book called 'complete'. The best ones played off cultural icons: Davinci Code Complete and Code Complete: This Time It's Personal.

The first part of the talk gave several lists summarizing the software world since Code Complete, the prequel, came out. A lot of the humor and insight in these lists lay in how some items showed up multiple times, or in how opposites showed up.

The worst construction ideas of the 1990s

  • code and fix
  • Big Design Up Front (Back then, it was *all* design up front.)
  • designing programs based on speculative requirements
  • the belief that components will solve all our problems (Just as Biddle and Noble's postmodernism theme tells us, there is no one story that can account for all we can or should do.)
  • automatic programming
  • calling everything "object-oriented"

The worst construction ideas of the 2000s, so far

  • code and fix
  • no design up front
  • planning to refactor, usually meant as fixing code
  • the belief that offshore outsourcing will solve all of our problems
  • automatic programming
  • uninformed use of extreme programming (An informed use of the waterfall approach is likely better uninformed use of extreme programming.)
  • calling everything "agile"

But not everything in the software world is bad...

A decade of advances in software development

  • With the theatrical release of The Lord of the Rings, all companies now have servers named 'gandalf' and 'frodo'.
  • We now do design at a higher level. Indeed, this may be the ultimate legacy of OO: we design our systems in terms of larger aggregations or abstractions.
  • The daily build and smoke test minimizes integration problems and institutionalizes incremental development.
  • There is now accepted, widespread use of standard libraries.
  • The creation of VisualBasic has brought several advances to common use in the public: visual programming, widespread use of COTS components, and improved control constructs that learned from Ada language design principles.
  • open source software
  • the web as a research tool
  • the widespread use of incremental development
  • Test-first design shortens time to defect detection and increases personal discipline.
  • Refactoring as a discipline, not as a cop-out, improves the design of software.
  • Faster computers have radically changed how we have to think about software development. Computers are so much faster than they used to be (McConnell spoke of having to perform test code 5 million times just to get measurable results!) that we should no longer think about optimization at the code level. It is almost never worth the effort. We can now pay attention to optimization primarily at the design level. Machine speed also means that we can use languages that we like, that make us more productive, without having to worry about the speed of interpreters, compilers, and compiled code.

I'm not going to report all of McConnell's ten realities of modern software construction, but I will summarize some of the points that struck me:

  • Construction is a legitimate topic of discussion as an activity, a set of practices, separate from the other parts of software development.
  • Personal discipline matters -- in the form of making realistic predictions, refactoring code, and creating simple designs. McConnell didn't mention writing tests, but I think it belongs here, too. He did point out that, while many folks think of Ward Humphrey and Kent Beck as representing very different sorts of software methodology, perhaps at opposite ends of a continuum, the discipline of Humphrey's PSP and the courage of Kent's XP are in much the same spirit. I think that this is a great insight. XP is not high ceremony, but it is high discipline. I once asked Kent what one new practice I should introduce into my first-year courses, and he said, "Have your students keep a project notebook", so that students could record their behaviors and be able to examine and improve them. Not so much different than PSP.
  • The fundamental tension in software is between simplicity and complexity. In the trade-off between write-time convenience and read-time convenience, the former is worth essentially nothing, given how much more code is read than written.
  • The toolbox metaphor gives us great power. We should keep that in mind when thinking about our development methodologies.

Talk Complete. (That was McConnell's joke, not mine. :-)


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 26, 2004 11:08 PM

OOPSLA, Day 1

The first day of OOPSLA has been seen highs and lows, though the highs weren't as high as I'd expected and the lows were lower.

Rick Rashid gave the keynote address to open the conference. A good keynote inspires a conference's participants to think interesting thoughts, to respond to some challenge, or to interpret what follows in a particular context. Sometimes, a keynote is spectacular in its scope or challenge. Christopher Alexander did that at OOPSLA a few years back, even though I didn't like the talk as much as many. But keynoters don't have to be spectacular. But they should at least provide a theme for the conference that threads through all the conversations that make it up, as Brian Marick explained last summer.

Sadly, Rashid's talk didn't do either. He opened with 20 minutes or so of promising ideas, about how the future of computing lies in pervasive computing, with its attendant need for situating people and their computers in place and time. The interesting part of this discussion focused on Microsoft's serving up of geographical information and providing a way for programmers to integrate such information into apps. Check out especially http://terraserver.microsoft.com/, and also http://skyserver.sdss.org/, http://skyquery.net/, and http://gpgpu.com/.

But soon after the talk lost its steam, ran out of the ideas that are the fuel of a good keynote. Rashid announced the upcoming web release of VisualStudio.Net 2005 and then called up a project engineer to demo a piece of the new tool. If this new tool had something new in it, that might be fodder for a keynote, but in this case the content is new only to the MSDN crew and pedestrian otherwise. After the demo, the talk never returned to intellectual currency, and it ended with a much smaller audience than it began with.

Robert Biddle and James Noble opened the Onward! track with their "Notes on Notes on Postmodernism" (NoNoPoMo), a self-referential peek back at their groundbreaking 2002 "Notes on Postmodernism" in the inaugural Onward! Robert and James do wonderful theater -- as entertaining as anything you will find at any computing conference -- that points out an essential truth: We don't need to have one overarching unifying story to guide computing; lots of little stories, told by smaller communities to guide their work, can be enough. We can build software in this way, too. They passionately declare that, contrary to the fiction our own industry has created and nursed for 35 years, there is no software crisis; software development has actually been a prolific and wide-reaching success. We should admit that and move on to do our next good work.

After lunch came Ward Cunningham's talk on systems of names. I have been looking forward to this talk for a couple of months, and Ward didn't let me down. He told a story, which is what Ward does. The story wove together the many ideas and contributions from his career -- including objects, CRC cards, patterns, wikis, and XP -- and drew out a theme that captures Ward's magic. It's not magic, though; it's an outlook on life, an attitude:

Be Receptive to Discovery

Ward even drew out some sub-themes to help us adopt this attitude. I was going to comment on each, but my words don't add to what Ward said, so:

  • Use what you know.
  • Feel it work.
  • Share the experience.
  • Wait for insight.
  • Refactor to include it.

My last event from the day's main schedule was Brian Marick's talk on software methodology as ontology. If you read Brian's blog, you know that he has a peculiar philosophical attitude toward software development. This attitude probably follows a bit from Brian's having been an English major in school, but I suspect that it's mostly just who he is. Brian takes a unique perspective on software development, one which I find both enlightening and challenging. I'm a sucker for this kind of this stuff.

Today's talk started with Ralph Waldo Emerson (who will almost certainly show up in my blog some day soon, for different reasons), whose fundamentally optimistic outlook on the world and human nature so differs from the software world's fear of change and complexity and failure; moved onto ontology as world view; and finally applied Imre Lakatos's view on the progress of science to the idea of software development methodology. I will save the real discussion of Brian's talk for a post later this week, to give it its due in a separate discussion. Suffice it to say that I found this talk both enlightening and challenging.

The rest of the day has been special events. At dinner time Alan Kay gave his Turing Award lecture. I will also blog on Alan's talks later this week when I can give them full attention, but for now I will say this: Alan's keynote to the Educators' Symposium was the better talk. Perhaps it was nerves, or a smaller time window, or just the effects of giving very similar talks on consecutive days. But we really lucked out with our 90+-minute talk and 30-minute Q-n-A session.

Finally, as I write this, I'm sitting in on the GoF 10th Anniversary Commemorative event. Solveig Haugland, author of the hilarious spoof Dating Design Patterns, is leading a fun session on her book, replete with skits about the untold story of the Gang of Four. So far, it's mentioned Trojan Proxies, Encapsulated Big Fat Openings, Half Bad Boy Plus Protocol, and leather magazines. I had the opportunity to meet Solveig before the talk, and she is a lot of fun. The session is a nice way to end the day.


Posted by Eugene Wallingford | Permalink | Categories: General

October 26, 2004 11:00 AM

The First Day of the Rest of OOPSLA

With the Educators' Symposium over, I now get to enjoy the rest of OOPSLA worry-free. The conference proper begins today, with some great speakers and panels on-tap. As is now usual, the Onward! track will get most of my attention between invited talks and networking.

Vancouver really is a nice conference city. The view to the right is one third of the panorama outside of my 15th floor hotel room. This morning I ran about eight miles, into the city to the south and then around False Creek, an inlet from the bay to our west.

I do like water. I'm not one of those folks who feels an indomitable urge to live on the sea, but I love to be near it. (Though after my run, I did come back and pop Son of a Son of a Sailor into the CD player...) The sounds of waves lapping against the shore line, birds flocking over head, and the gentle swoosh of a morning crew team out for a training run of their own certainly bring a sense of peace to a run.

That said, it's easy to forget that not everything about the coast is light and beauty. Port cities are, at their edges, industrial places: big steel ships and beyond-human scale concrete piers. Here in the heart of Vancouver things aren't so bad, with the coastline dominated by marinas and restaurants, but even still I ran through a couple of industrial areas that didn't look or smell all that wonderful. I'm glad when the real world occasionally reminds me not to surrender to my weakness for romance.

Well, off to Rick Rashid's conference keynote on the future of programming. Rick's not a programming languages guy, but he has written a little code... He developed the Mach operating system, which sits at the core of a number of operating sytem running on my laptop right now!


Posted by Eugene Wallingford | Permalink | Categories: General, Running

October 26, 2004 10:41 AM

Educators' Symposium Success

The Educators' Symposium is over. I'll have to think deeply about Alan Kay's talk and the follow-up panel to say much on the central challenges posed by the day, but I can at least say that the day went pretty well.

Alan's talk went longer than planned, but no one complained. A few questions then took us another half-hour over schedule. We made some adjustments in the line-up, tightened up the talk slots, and things fell into place.

The technical papers were stronger than in some past years. We received many strong submissions, and the papers that made the cut held some important ideas for the audience. Some -- like teaching interfaces before inheritance, by Axel Schmolitzky, and teaching collections before arrays, by Adrienne Decker -- are small steps, for sure, but steps that many folks still need encouragement to take. Others, like how teaching event-driven programming first can improve our coverage even of traditional procedural topics such as for loops, by Kim Bruce, are less obvious jumps that some folks are taking. They show that the universe of choices is larger than you might think.

The Framegames! activity by Steve Metsker and Bill Wake was intense but fun. It showed how teachers can use simple game shells (like instantiable classes) to create interactive class sessions with relatively little fuss. I don't yet use games of this sort in my classes very often, but I should probably try them out sometime. Students might appreciate the chance to take a break from my intense pace in class. You will be able to find notes on the games at Bill Wake's web site within the week.

The closing session of "sound bytes", one-minute ideas for improving instruction, started slowly but picked up. Unfortunately, it spun a bit off-topic at the end, with lots of 'me-too's added in. This was the first time Joe Bergin had tried this idea live, and it showed some promise. To be honest, though, the result of this activity is a common phenomenon at Educators' Symposia: open mike time at the end often doesn't live up to its promise, because people are both tired and overstimulated with ideas from the long day. But sometimes people just need a chance to speak, and they miss it if you take it away.

So, after all the work I and my committee put in this year, the symposium came off a success.

My strengths showed up in the planning: well organized, ambitious but not too much so, and being connected to folks with good ideas and a willingness to server.

And my weaknesses showed through, too, though more in the execution. For example, I get so into the moments of the workshop that I don't do very good job setting up beginnings and ends, such as wrapping things up gracefully and getting the next scheduled item off promptly enough. I have big plans in my mind, and may even prepare to execute them, but then I lose steam at the end.

I've been asked to chair the Educators Symposium again in 2005. I know now how to do some of the little things better next time, but can I do the big things as well or better? Do I have an idea of where we should take the next Symposium? I'm too tired tonight (Monday night) to say for certain. But maybe -- if I can get the right folks to help me again. San Diego is awfully nice this time of year.


Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

October 22, 2004 4:23 PM

Heading to Vancouver

I'm off to Vancouver for OOPSLA. The conference will be exciting, with two talks by Alan Kay, another by Ward Cunningham, events on Eclipse and Squeak, and the culmination of a year of my work in Educators' Symposium. When you take on one of these professional service tasks, it seems pretty innocuous, but after months of thinking and planning and organizing, and working with the dedicated people who invested their time and energy through my program committee, the event takes on a more personal tone. I have big hopes for a symposium that helps the community take a step in the direction of re-forming CS education.

I love Vancouver as a conference town and a running location. I'm looking forward to circling Stanley Park again and to exploring some new parts of town. You can be certain to receive another episode in my Running on the Road series soon. (See the latest one here.)

We'll have wireless access at the conference. I plan to blog daily once I arrive.


Posted by Eugene Wallingford | Permalink | Categories: General

October 22, 2004 9:45 AM

Kenneth Iverson, RIP

Sad news: Kenneth Iverson passed away on October 19. Iverson is best known for creating APL, an extremely powerful and concise programming language. In 1979, Iverson received the Turing Award for his work on programming and notations for describing programs.

Concise taken too far turns into cryptic, and APL is often derided for its unreadability. But I have a special place in my heart for APL after a three-week unit studying it in my undergraduate programming languages course in the mid-80s. I've always marveled at just how powerful language can be. In APL, I could write a program to shuffle a deck of cards and deal them to several players in four characters. Within its domain of matrix processing, APL was king.

I met Iverson in the late 1980s while studying at Michigan State. He came to speak about his more recent language development work, which ultimately led to the J programming language. J synthesized ideas from APL with the functional programming ideas found in John Backus's FP. (Backus also won the Turing Award for work on programming languages, in 1977.) I don't remember much about the day of Iverson's talk at MSU, except that he graciously and patiently fielded many aggressive questions from the audience.

I am on quite a Turing Award ride these days. As I blogged earlier today, I've been thinking of Edsger Dijkstra this week. Iverson and Backus won in the late '70s. And I'm preparing my introduction for Alan Kay, who is giving the keynote address at the OOPSLA 2004 Educators' Symposium on Monday and then giving his 2003 Turing Award lecture the next night. My excitement about Alan Kay's talks is only heightened by Iverson's passing, as it reminds me that great thinkers are mortal, too. We should appreciate them and learn from them while they are with us.


Posted by Eugene Wallingford | Permalink | Categories: Computing

October 22, 2004 9:16 AM

Dijsktra on Academic Conservatism

A few different threads at work this week have me thinking again of Edsger Dijkstra's Turing Award lecture, "The Humble Programmer". (I first blogged on this back in July.)

The primary trigger was a discussion yesterday of a grant proposal two of my colleagues were preparing. They proposed to teach our first-year courses using a studio approach inspired by the arts and architecture. The essence of the software studio is the concept of reflective practice. Students and instructors work on projects in a common space, with continuous interaction and continuous questioning. Students build things, critique their work and the work of others, and defend their work. A major goal of this approach is to help students develop the analytic and the artistic skills that are the hallmark of the professions. Ideally, students learn how to build, innovate, and invent.

That is my own summary of what a software studio might do, not my colleagues'. You see, I've been interested in this approach for my whole career as a CS professor. My interest goes back to my time as an undergrad architecture major in the wonderful B.Arch. program at Ball State University. I began using a studio approach in my senior-level Intelligent Systems course back in 1995. (You can read more of my thoughts in the most recent incarnation of that course.) I've used the idea in other courses, too, though not in my freshman course.

So I was quite excited that my colleagues were considering a change in how we teach introductory software development. Studio approaches work in other disciplines, and I have seen the results. Students become used to the give-and-take of constant evaluation, and they do become more deliberate creators. By spending time in a lab rather than a dead classroom, students develop better work habits and more facility with their tools.

But the reaction of other faculty members was predictable. Should we be experimenting with our students' education? What do we do when this adversely affects retention? Or even recruitment? The questions were many and various. Maybe these questions reflected healthy skepticism, but they felt a little like an attempt to discourage a new idea.

Frankly, given how poorly we seem to be doing educating a broad range of undergraduates to be effective software developers, I have a hard time thinking change is a bad idea.

What about all this made me think of Dijkstra? His Turing lecture proposed a new way of thinking about and doing computing, too, and he was aware that some people would reject his proposal:

As [with] each serious revolution, it will provoke violent opposition and one can ask oneself where to expect the conservative forces trying to counteract such a development. I don't expect them primarily in big business, not even in the computer business; I expect them rather in the educational institutions that provide today's training ...

What Dijkstra saw in the early 1970s is every bit as true today. Whatever their political reputations, academics are remarkably reactionary when it comes to their disciplines. This may seem strange in a field like computer science, where the technical horizon advances steadily. But how we think about programming, programming languages, and our courses has really changed very little in the last 20 years.

That's one reason I've had Dijkstra's talk on my mind this week. Discussions of classic AI papers with a graduate student are another. And a third is that I'll be heading to OOPSLA tomorrow...


Posted by Eugene Wallingford | Permalink | Categories: Teaching and Learning

October 18, 2004 11:24 AM

Marathon Results On-Line

The results are on-line now at:

http://www.onlineraceresults.com/race/view_race.php?race_id=1765

Check out 335th place. My official time was 3:45:15.

And I am even able to walk forward down stairs today...


Posted by Eugene Wallingford | Permalink | Categories: Running

October 17, 2004 3:23 PM

It's a Good Day to Run 26.2

A quick note from Des Moines. My second marathon is in the books. On this cold, cloudy morning, I joined 3300+ people for the Des Moines Marathon. It went well, with my time coming in right on target -- 3:45 -- though differently than I expected. After two of these, I think I now understand that nothing will ever go quite as planned. That is part of the charm of a a marathon -- but an even bigger element in its challenge.

Des Moines is a different kind of marathon than Chicago, where I ran my first. We had fewer 10% as many runners start this morning, and the crowd of onlookers was as much smaller. But I was surprised by how many people braved a cold, cold morning to cheer us on, play music, and offer snacks. I am indebted to the creative folks who passed out facial tissues along the course. The crowd may have been smaller, but their enthusiasm more than made up for their numbers.

The course was also much more scenic than Chicago. Des Moines doesn't have the history of Chicago, but it has several pretty parks and many pretty neighborhoods. Out of staters may not expect that -- or the hills! They definitely affected my run today.

I don't when the race results will be avilable on-line, but if they do you can check me out at race bib #1272. (The bibs didn't actually have our numbers -- they had our first names. This made it possible for friendly total strangers to call out "Looking good, Eugene!" throughout the race. I doubt I did, but it boosted my spirits.)

All in all, a well-organized race. I recommend it highly.

Oh, and remember the gonzo Grant Wood race poster? That's the image on our race medal!


Posted by Eugene Wallingford | Permalink | Categories: Running

October 15, 2004 4:37 PM

Off to the Des Moines Marathon

Well, the time is almost here. I leave tomorrow for the Des Moines Marathon. Officially, I've been training for this race since April 1 or so, but I never really stopped getting ready for my first marathon last October. You reach a point where there is nothing left to do. I increased my mileage and my pace during training this year. I've tapered the last three weeks, running only 13 miles so far this week. My eating has been out of sync the last few weeks, but I think that my body will be fueled well enough for the race. It's time to do it.

Tomorrow, I will hit the race expo, to pick up my race number and timing chip and to do a little window shopping. Then I'll spend the evening with a friend, former student Fred Zelhart, who has generously offered to put me up for the weekend. The race is 8:00 AM Sunday morning. The weather forecast is almost perfect -- mid-40 degrees to start the race, upper 50s to finish, partly sunny. That may sound cool, but it's perfect for a long run.

I'm excited. I think I can improve on my time at Chicago, but I'm respectful of what race day and the distance can bring. My first goal is to enjoy; my second is to improve on my debut performance. If everything goes perfectly, I could run anywhere from a great time to the same time as last October. I have a couple of goal times in mind but learned last year that sometimes you just have to run. So that's what I plan to do.

Oh, and if you want something with a little more attitude than my cautious forecast, check out this Grant Wood-inspired race poster. And we Midwesterners wonder why our coastal friends tease us sometimes...


Posted by Eugene Wallingford | Permalink | Categories: Running

October 15, 2004 2:57 PM

What Is It Like to Make Software?

Earlier this week, my students and I discussed a chapter from The Pragmatic Programmer. A few students wrinkled their noses at Dave and Andy's use of gardening as a metaphor for software development. I know lots of folks who don't like this and other "soft" metaphors for making software. For most folks, engineering and architecture still make the most sense.

At one level, of course, software development is like engineering. Software developers design and build artifacts in response to human needs. They base their designs on a scientific and mathematical understanding of the world. They strive for processes that are verifiable and repeatable, so that they can reliably build artifacts that meet their specifications.

But, as I admitted to my students almost in a whisper, I like the gardening metaphor. Design, programming, refactoring, and debugging all have reasonable analogs in gardening, and even better is the mindset of "cultivating" a system over time. It's an organic metaphor, and that feels right to me.

We do make software, but software isn't really like a bridge or an auto. The abstractness of software makes it more like a legal argument or a scientific theory. As a graduate student, I built models of arguments and theories and tried to understand how people create them. There's a lot of value in taking an engineering viewpoint on these tasks, but it doesn't always seem much like how people do them.

Of course, the relationship between art, science, and engineering is a popular topic among reflective practitioners of all three. In just the last week I ran across an article by a physicist talking about superstition in scientific method and an article by an artist talking about the mundaneness of artistic craft. It seems that many seemingly different activities are less different in the doing than they seem at first glance.

While I appreciate the gardening metaphor and think that it can help us understand something about what we do, I don't think it suffices as a model for how we make software. None of the metaphors I've heard of do. That's why I really like this quote from Richard Gabriel:

Over the years I've tried to make the point that programming (even in its "hacking" form) is not precisely like anything else that people do, but is like everything that people do all at once: Programming is not engineering, but programmers do engineering, programming is not art, but programmers need to be artists, etc. The totality of the activity of programming is not like any one thing people do, but because people are people, we bring to bear all our ways of doing things - alone, in groups.

We are just beginning to understand what it is to build software. Metaphors can both help and limit us in our discovery.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 14, 2004 8:15 AM

Isaac Newton, Failed Agile Software Developer

Every once in a while I run across an article in a journal or trade magazine that reflects some misunderstandings about agile methods. Last July, I blogged about an article from a CS education magazine which asserted that using agile methods was unprofessional. (Presumably, then, so is teaching them as a viable alternative to traditional methods.)

Yesterday, Steve Berczuk pointed the members of the XP discussion list to an article in the October issue of IEEE Computer called "Do Agile Methods Marginalize Problem Solvers?", by Victor Skowronski. (The article is available on-line to IEEE-CS members.) As Steve said, this column "sounds like it was written by someone who has read about agile methods but not used them."

Skowronski's argument seems to be this:

  1. Excellent problem solvers often have personalities ill-suited for teamwork and, further, must often work in ways that do not match well with teamwork.
  2. Agile methodologies favor people with lesser technical skills and strong "people skills" over excellent problem solvers and others with technical skills whose people skills are subpar.
  3. Thus, agile methodologies are unsuitable for environments that require excellent problem solving skills and thus must attract people who have them.

This, of course, means that agile methodologies are unsuitable for many (most?) software projects.

The article uses two of history's great thinkers as examples: Isaac Newton and St. Thomas Aquinas. Apparently, Newton wasn't much of a team player, feuding with rivals, guarding his advances until publication, and preferring to work in isolation. Aquinas, though, was just quiet, a man living the life of the mind irrespective of his social circumstances.

Would I really want a Newton on my team? Most software developers aren't writing software that will change the intellectual foundation of a discipline or even a company. They don't need to create new ideas of the depth and complexity of Newton's advances.

Most software developers also don't get jobs for being pains in the behind.

Would I want Aquinas on my team? Maybe. I can imagine having an excellent programmer be a valuable contributor to my team even though he is unable to pair effectively. I've never worked in such an environment, as my agile background is limited to teams that chose to use agile methods on their own, but I can imagine it. Maybe over time the loner becomes an effective pair; maybe instead the team adapts to the loner. It could work.

Like so many articles of this sort, this one projects a lot of details into the description of agile methods that aren't really there. Perhaps this projection follows from never having tried agile methods, or maybe from an ideological bias. In any case, this article makes assumptions that demean agile proponents' professionalism and ethics.

Forcing programmers into a communal workspace with no opportunity for either personal or professional privacy in the work place? Discouraging the writing of all documentation? Building software without adequate knowledge of one's task, tools, and domain? Please. Those aren't agile practices. They are just bad ones.

A big part of the article discusses how the phases of problem solving fit with an agile approach, but it is largely beside the point. When an agile team needs to solve a thorny problem, agile developers can read books and seek other sources of information. They can take time away from the active production of code, if that's what's needed. The team can make reasonable decisions about how to advance its work.

I did have some good thoughts as I read this piece, reminders to be agile:

  • Adapt to your personnel. Certainly. Agile processes aren't just about software; they also encourage us to be agile in how they work with people.

    That said, you should take care in assembling any software team, and an agile team is no exception. You may choose not to have a Newton or Aquinas on your team, if they don't fit. You might choose not to have lots of different kinds of people on my team.

  • Don't overlook developers who can contribute value but don't fit your stereotypes. This is a variant of the previous point. The article reminds us that a good problem solver who lacks people skills may seem less competent than a person who fits the agile mold. We certainly don't want to overlook potential contributors. We need to watch for opportunities to bring potential contributors onto the team and help them to contribute. They might even grow in the process, too.
  • Use methods appropriate to your project and environment. Well, certainly. Agile is as agile does. We need to mold our approach to the task at hand. But that doesn't mean throwing out things that we value as essential, like communication.

Throughout this article, the author seems to imply that you can't find good problem solvers who are capable of working on an agile project. Hogwash. Not every person who excels at problem solving behaves as badly as Newton. I know a lot of smart people with great technical and problem-solving skills who use agile methods and like them. They wouldn't choose to develop software any other way. Furthermore, not all software teams need a problem solver as singular as Newton. Writing software is hard, but it is rarely as hard as inventing the calculus.

One other claim caught my eye. This article defines the "best programmer" as the one with the most advanced problem solving skills. This is almost certainly the wrong answer. The best programmers are those people able to deliver high value to their customers for suitable cost. Problem solving is certainly an important component in being able to do that. It is essential that software developers be able to think deeply and to find solutions to thorny problems. But problem solving is not the only requirement for a good programmer; indeed, often it's not even the most important one.

I know that this article is presented as an opinion piece, in a column that the editors of IEEE Computer hope will stir up foment. In that regard, I suppose, this piece succeeds. But still I wonder about the disinformation and misunderstanding of agile methods that cause people to write such stuff. I hope that Mr. Skowronski does better research before diving into one of those really hard problems that he needs to solve.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 11, 2004 12:12 PM

Running on the Road: Muncie, Indiana

The second stop in the Running on the Road series: Muncie, Indiana, the home of Ball State University. (The first stop was Allerton Park, Illinois.)

Ball State University is my alma mater, and I still have a place in my heart for the university and for Muncie, its town. Muncie is a typical small Midwestern city of about 80,000 people. It grew up with the industrial expansion of the US in the early and middle 1900s and, like many such cities is not always pretty on the eyes. But it is also typical Midwest in the friendliness and pride of its people.

I was not a runner in college and so don't have any memories of good routes. But I've been back to Muncie for various reunions three of the last four years or so, which has led me to look for and try out a few different places to run.

On Campus

Ball State has a nice campus to run. It has lots of paths that let you cross the Quad and central campus many different ways, with several arteries that connect the north, central, and south parts of campus. I've run 5-6 miles on campus several times now just by looping in and out for new views. McKinley Avenue is the north-south artery that runs from near the football stadium on the north to the Quad at the south. The south end of campus spans to Tillotson Avenue on the west. It includes a soccer field where you can run laps and Christy Woods, a small but scenic nature area better known for holding hands and kissing than for running. I've stayed at the Student Center hotel, which is simple and inexpensive, and recommend it. Central campus runs east of McKinley and has plenty of trees and paths.

Head east on either Riverside (past churches and frat row) or University (through The Village, BSU's restaurant, club, and store district) to find two areas of interest. When you reach Wheeling Avenue, turn south and you will reach downtown Muncie in no time. Even better, though, from Wheeling you can reach either of the two nature trails that offer Muncie's best runs.

Delaware Greenways

Muncie offers two trail systems. You can find information on both at DelawareGreenways.org. This map of the trails from that site shows the basic layout of the system, as well as the Ball State campus and downtown Muncie, too.

Coming from campus, when you hit Wheeling Avenue you reach the White River Greenway, which runs roughly west to east through town following the north bank of the White River. I've only run the bit of this northeast from Wheeling to the other trail, but I know that the river offers a scenic view of some Muncie parks and residential areas. I'll check it out more the next time I get to town.

If you head south on Wheeling to Wysor Street and then turn left, or north on the White River Greenway, you will reach the Cardinal Greenway, which is constructed on trackbed of the old Chesapeake and Ohio, a railroad originally conceived to bring Appalachian coal to Virginia tidewater. It runs 20 miles with Muncie in the middle, though this rails-to-trails project aims to connect with another C&O-based trail in eastern Indiana to reach 75 miles in length. So far, I've only gone north from the Wysor Street Trailhead, at the site of a restored 1901 depot. The trail is marked every half mile (excellent!) and has toilet facilities 4 miles north. There is also a nice trailhead and parking lot at McGalliard Avenue, a mile or so east of the north side of the Ball State campus.

After a half mile or so, this trail is all natural, with lots of green and farmland to view. I really enjoyed a 12-mile run out and back on the trails this weekend. The southern portion of the trail is probably pretty, too, as you'll be out of town quickly. I plan to try it out next time!


Posted by Eugene Wallingford | Permalink | Categories: Running

October 08, 2004 6:02 AM

A Busy Month

Today begins a busy stretch for me.

This afternoon, I leave for a weekend reunion at Ball State University, my alma mater. I'm part of a scholarship program that has quadrennial get-togethers, and 2004 is our year. This is Homecoming Weekend in Muncie, and there will be a lot happening. Several old friends and their families will be there, and my brother is coming up to spend the weekend with me. Amazingly enough, I never attended a Ball State homecoming football game, even as a student. This seems like a good weekend or a first time. I also plan two easy runs as I prepare for...

Next weekend, I run the Des Moines Marathon. My training has gone well, with only a couple of hiccups that I survived. Now, I'm tapering. This will be my second marathon after running Chicago 2003, and I am in much better shape -- physically and mentally -- for this one. But I am humble in the face of the 26.2 miles and know that I will have to be careful and lucky to meet my race goals.

The next weekend, I take off for a week in Vancouver for OOPSLA 2004, where I am chairing this year's Educators' Symposium. The highlight of the 2004 conference is Alan Kay's Turing Award lecture. Alan is also giving the keynote address at the Educators' Symposium, and I am quite psyched.

But all this travel makes for a busy month. I'd better get home to spend some time with my family before I hit the road!


Posted by Eugene Wallingford | Permalink | Categories: General

October 08, 2004 5:40 AM

Refactoring Support for Scheme Programmers

In a recent post, I mentioned that a group of my students is doing an XP-style project in Scheme. They have available a nice Scheme unit testing framework, equivalent to JUnit and tools available in many languages. Teams working in Java also have tool support for refactoring, particularly the open-source Eclipse and the academically-inexpensive IntelliJ IDEA. But googling and checking the refactoring tools page reveal no refactoring browser or IDE for Scheme. There are plenty of tools for Java, an increasing number for C#, and even one for Python... but none for Scheme. I am aware of a project by Simon Thompson and Claus Reinke on refactoring functional programs, but they are targeting the pure, statically-typed functional language Haskell.

I think that the Scheme group most likely to produce a wonderful refactoring browser soon is the Dr. Scheme group, but I don't think they have done anything in this direction yet. They do have a unit testing framework integrated right into their IDE, though.

One of my current R&D goals is to create a simple refactoring browser for Scheme. I started a project on Scheme-processing tools last spring, and refactoring is the first big tool I want to produce. Right now, I'm working in Java, because of its platform-independent support for GUI code and because it is most accessible to my students at the university. Eventually, I could see migrating to Dr. Scheme, and writing the tools and browser in Scheme itself.

If you are a a student who is interested in working on this project, let me know. If you know of any other projects targeting refactoring support for Scheme programmers, let me know.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 07, 2004 5:30 PM

Agile Software Development in the Large

I just received my copy of Jutta Eckstein's new book, Agile Software Development in the Large: Diving into the Deep in the mail yesterday. (Thanks, Jutta!) This book addresses one of the persistent myths about agile methodologies: that they only work for small teams. Jutta is a consultant with many years' experience in software development, and she has written this book to document practices that have worked for large teams building software in an agile way. And when she says 'large', she means 'large', projects with up to a 1,000 developers.

Most books on agile software development either theorize or talk about the use of agile methods on a smaller scale. That is natural, as many of the pioneers are writing about their experiences using agile ideas in their own smaller organizations. Unfortunately, this has left the agile folks at a disadvantage when asked, "But does it scale?" My answer to this question has always had to be "I don't know for certain", because I've never seen agile methods applied in large, traditional software houses. (I always follow up with theorizing about how it could or should scale, but such theories don't encourage much confidence in a person who has to bear the risk of potential failure if it doesn't.)

Just from my first skim of the book, I see many things that I like. Perhaps best is that this book presents practical guidelines we can all follow. It illustrates the guidelines with stories of real projects, but Jutta has done some serious thinking to distill wisdom from her decade of experience with the agile methods. I also like that the book isn't specific to XP or Scrum or any other particular agile approach. It deals instead with the values and principles that are common to all of these. As a result, the advice we receive here should be useful no matter how we tailor a particular approach to our organizations.

So, I am quite excited to read Jutta's book this weekend. She can teach me something about agile software development that lies outside my experience. I know of Jutta's work in the OOP and patterns communities, and I have come to respect her insight and pragmatism. This book should become a staple on my agile bookshelf.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 04, 2004 5:44 PM

Pleasant Surprises

My Agile Software Development class is doing a big course project. The students are creating the beginnings of a content management system for me, with an initial eye toward me writing content for a book and their program generating a web site for the content. I don't know how far we will get this semester, but that is part of the fun of the project.

Most of our students have spent a year learning Java and a semester learning Ada, so those tend to be the languages in which they want to program. I expected most folks to want to work in Java, given all of the tools that support agile development in that language, starting with JUnit but extending to Eclipse, Ant, and others. (Actually, I knew that a few would probably want to program in C, but tool support for agile approaches in C is still weak. Go, Ale, go!)

Imagine my surprise when a four-person team asked me if they could use Scheme. They had all learned Scheme in my Programming Languages course, so this wasn't an impossible request. But only rarely does Scheme attract a student's fancy in my course... The language is just so different from what they know that, even if they come to appreciate its power, they usually don't grok how they might use it as a development language on a "real" project. These students had all done well in the Scheme part of Programming Languages, but they hadn't expressed any deep love for the language at the time.

So my initial reaction was, "Are you jerking my chain?" But they insisted they weren't, that Scheme seemed like the right tool for the job at hand: transforming data from one form to another, with flexible parsing underneath. So I let out a little bit more chain and said, "Well, you'll have to get a unit testing framework so that you can write your tests first..." I had mentioned SchemeUnit in passing earlier in the course but hadn't told them just how nice unit testing can be in a dynamically typed and highly flexible language like Scheme. They said, "No problem."

They did it. The team submitted the build of its first iteration last Friday. They have three dozen or so tests and three of four domain modules. The code looks good. We'll see what happens by the end of the first "official" release of their code -- two more iterations to go -- but I've graduated from cynical skepticism to guarded optimism.

This is enough to restore my faith in humanity. To quote ranch owner Clay Stone from one of my favorite movies, City Slickers, I'm as happy as a puppy with two peters.


Posted by Eugene Wallingford | Permalink | Categories: Software Development, Teaching and Learning

October 03, 2004 5:00 PM

Duplication in Many Forms

We all know that, all other things being equal, duplication in a program is bad. The Pragmatic Programmer uses the phrase DRY -- "Don't Repeat Yourself" -- to capture the essence of this idea. Unchecked, duplication creates a maintenance nightmare, because changes to the system may be needed in several, hard to find places.

When programming test-first, duplication is a natural part of the development process. First, we craft a test for a requirement, and then we do the simplest thing possible to make the test pass. That simplest thing often involves duplicating some other piece of code, with perhaps a few tweaks that distinguish the new case from the existing one. Test-first development doesn't leave the duplication unchecked, though, because it calls for us to refactor our code as soon as the code for a test passes.

What sort of duplication should we look for when refactoring code, whether as a part of TDD, as part of taming a legacy system, or as part of improving our non-TDD system?

Duplication can occur in many guises, not all of which are immediately obvious when examining a body of code.

The simplest form of duplication is when two pieces of code look the same. Such textual duplication results from copy and paste, but it can also occur when solving related problems independently. When we duplicate text via copy and paste, we usually know to eliminate the duplication in the upcoming refactoring phase. Even when we generate it independently, it's easy enough to recognize as we move around our code base. Common refactorings such as factoring out a method or superclass address textual duplication.

A particular sort of textual duplication arises in how we sometimes name things. Consider this piece of Java code, based on a thread on the refactoring discussion list:

sendMessageToServer( Message m, Server s )

There's a not-so-subtle duplication in the name of the method and its arguments. I like explicit names, to the point of using longer names than most folks like to type or read, but this example repeats the intent of the method in the method name sendMessageToServer and the argument types Message and Server. The duplication rises to another level when used in this too-common way:

      Message message = ...;
      Server  server  = ...;
      ...
      sendMessageToServer( message, server );

That's triplication, not duplication! Let your language do some work for you. And you don't need to work in a statically-typed language to see how good names can eliminate such repetition. A typical Smalltalk method signature for the above would probably read:

      send: aMessage to: aServer

We can eliminate this sort of name duplication by choosing better names. :-) Name methods for their actions, and let the names of argument objects participate in the readability of an statement.

A related form of duplication occurs when two pieces of code behave alike. We can call this functional duplication. Sometimes functional duplication begins as textual duplication, but it can happen quite innocently as programmers working on different parts of a system reinvent one another's solutions to common problems. When two methods or two classes do the same thing, we run into the same maintenance problem as in textual duplication. When requirements change, one of the methods or classes may be modified or enhanced, leaving some part of the system using an older version.

Functional duplication is hard to find, because the code may not jump out at you. One of the less-mentioned benefits of small methods and small classes is that it's harder for functional duplication to hide in complex code. If you see code that does the same thing as another piece of code, you're more likely to see it in simpler code. XP's encouragement that all programmers work on all parts of the system over time, through promiscuous pairing and non-exclusive attachment to particular sub-systems also helps us avoid this problem, as we are more likely to come into contact with all of the system's functionality sooner or later. Once identified, we can eliminate functional duplication using many of the same factoring techniques as we use on textual duplication. But we may also need to redesign some of our interfaces when different functionality goes by different names in the system.

Dave Astels points out another kind of duplication in his article on bad code: temporal duplication, when work is repeated unnecessarily in a program. I see this sort of duplication when both client code and server code perform safety checks on the values of variables, say, to verify a pre- or post-condition. But it can happen in other ways, too. For example, student code often asks a collection if it contains an entry with a particular key, and when the collection says 'yes' it asks for the entry. This may involve searching the underlying collection instance variable twice. Temporal duplication is harder to find, because it requires a deeper feel for what the code is doing.

One way to eliminate temporal duplication is to decide who is responsible for an invariant condition and then having only that object enforce it. Another is to rethink the interface of an object -- why ask the collection if it contains the key; why not just ask for the desired entry and behave appropriately when it can't find it? A third way is to cache the result of the first effort and then return the value immediately upon future requests. Choosing which of these techniques to use is a matter of balancing different forces. Someone should write some patterns...

There are some other forms of duplication that show up as a result of how we design our code. Kevin Rutherford wrote an article or two on how many if statements duplicate knowledge held elsewhere in the system. This is a sort of epistemological duplication that lies at the heart of good system design. In object-oriented programming, we don't need to use an if statement to recover what the system knows or used to know. At the moment the system knows something about its future behavior, it can create an object that has that behavior. Joe Bergin and I have been encouraging this as a way for students and instructors to design programs that make better use of polymorphic dispatch than explicit selection. The advantage of polymorphic dispatch over if statements is, of course, that we can customize a program's behavior by plugging a new kind of object into the system, rather than editing the program code to address another case in the if statement. And, where there is one such if, there tends to be more than one, and we end up with a form of textual duplication if only in the structure of the choices being made!

I like this quote from the Rutherford article mentioned above as a concrete criterion for recognizing epistemological duplication in choices:

Therefore it seems to me that there are two kinds of conditional statement in a code base: The first kind tests an aspect of the running system's external environment (did the user push that button? does the database hold that value? does that file exist?). And the second kind tests something that some other part of the system already knows. Let's ban the second kind...

Duplication in all its forms can come back to hurt a programmer in the long run. I think that one of reasons we feel so good when we read the code of the masters is that even the less obvious forms of duplication are nowhere to be found. We may not recognize this reason, but it's there. Look for these kinds of duplication the next time a piece of code makes you say "Ahh!" or "Ugh." You may be surprised by what you find -- and what you don't. Then think about these kinds of duplication the next time you are refactoring your code. You will surprise yourself by the opportunities you have to improve your program.


Posted by Eugene Wallingford | Permalink | Categories: Software Development

October 01, 2004 2:04 PM

Proofs from THE BOOK

I just finished reading Proofs from THE BOOK, by Martin Aigner and Günter Ziegler. The title comes from Paul Erdós, who "liked to talk about The Book, in which God maintains the perfect proofs for mathematical theorems". Mathematicians don't have to believe in God, said Erdós, but they have to believe in the book. Proofs from THE BOOK collects some of the proofs Erdós liked best and some others in the same spirit: clever or elegant proofs that reflect some interesting insight into a problem.

I am a computer scientist, not a mathematician, but many of these proofs made me smile. My favorite sections were on number theory and combinatorics. Some of the theorems on prime and irrational numbers were quite nice.

My favorite proof from The Book applied the pigeonhole principle in a surprising way. The claim:

Suppose we are given n integers a1, ..., an, which need not be distinct. Then there is always a set of consecutive numbers aj+1, ..., ak whose sum is a multiple of n.

This doesn't seem obvious to me at all. But consider the sequences N = {0, a1, a1+a2, a1+a2+a3, ..., a1+a2+...+an} and R = {0, 1, 2, ..., n-1}. Now consider the function f that maps each member of N, ai, to (ai mod n) in R. Now, |N| = n+1 and |R| = n, so by the pigeonhole principle we know that there must be two sums from N, a1+...+aj and a1+...+ak (j<k), mapped to the same value in R. a1+...+aj may actually be 0, the first value in N, but that doesn't affect our result.

Then:

subtract the smaller sum from the larger -- and get the claim!

must have a remainder of 0. QED. Beautiful.

Eugene sez: Check out Proofs from THE BOOK.

P.S. It might be fun to create a similar book for proofs related specifically to computer science. Proofs from THE BOOK has some proofs on counting and one proof on information theory, but most of the book focuses on mathematics more broadly.


Posted by Eugene Wallingford | Permalink | Categories: Computing, General