[ See what happens when I start talking? I can't shut up. :-) ]
The Delgado Codex
I ran across a neat little example of reflective practice on the major league baseball diamond in The Scholarly Rigor of Carlos Delgado. Carlos is the first baseman for the Florida Marlins in U.S. baseball's National League. He apparently has the agile habit of recording detailed information about every one of his at-bats in a notebook he keeps with him in the dugout. By collecting this data, he is able to derive feedback from his results and use that to improve his future at-bats.
As the article points out, most professional sports teams -- at least in America -- record all of their performances these days and then mine the film for information they can use to do better next time out. Delgado, "like a medieval Benedictine at Monte Cassino", is one of the few major leaguers who still use the ancient technologies of pencil and paper to personally track his own performances. The act of writing is valuable on its own, but I think that as important is the fact that Delgado reflects on his performance immediately after the event, when the physical sensations of the performance are still fresh and accessible to his conscious mind.
How is this related to my previous post? I think that we programmers can benefit from such a habit. If we recorded the smells that underlay our refactorings for a month or even a week, we would all probably have a much better sense of our own tendencies as programmers, which we could then feed back into our next code. And, if we shared our experiences, we might develop an even more comprehensive catalog of smells and refactorings as a community. If it's good enough for Donald Knuth, it ought to work for me, too.
Agility works for Delgado, one of the better offensive players in all of baseball. Knowing about his habit, I'm even happier to have him as a member of my rotisserie baseball team, the Ice Nine. :-)
The Zen Refactoring thread on the XP mailing list eventually came around to the idea deliberately creating code duplication. The idea is this: It is easier first to write code that duplicates other code and then to factor the duplication out later than it is to write clean code first or to refactor first and then add the new code.
I operate in this way most of the time. It allows me to add a new feature to my code immediately, with as little work as possible, without speculating about duplication that might occur in the future. Once I see the actual duplication, I make it go away. Copy-and-paste can be my friend.
This technique is one way that you can refactor your code toward suitable domain abstractions away from primitive data. When you run into a situation where you find yourself handling a tolerance in multiple places, Extract Class does the trick. This isn't a foolproof approach, though, as Chris Wheeler pointed out in his article. What happens when you have references to mass-as-an-int in zillions of places and only then does the client say, "Um, we allow tolerances of 0.1g"? Good design and good refactoring tools are your friend then.
In the same thread, Ron Jeffries commented:
> I have also sometimes created the duplication, and then
> worked to make the duplicated code as similar as possible
> before removing the duplication. Does anyone else do this?
I once saw Kent Beck do that in a most amazing way, but I haven't learned the trick of making code look similar prior to removing duplication; would love to see an example.
Now I have fodder for a new blog entry: to write up a simple example of this technique that I use in my freshman-level OOP programming course. It's a wonderful example of how a little refactoring can make a nice design fall out naturally.
How is this related to my previous post? Duplication is one of my pet code smells, though I often create it willingly, with the intention of immediately factoring it out. Like Primitive Obsession, though you have to learn to strike a proper balance between too little and too much. Just right is hard to find sometimes.
Recently, Chris Wheeler posted a thoughtful blog entry called My Favourite Smells, which described only one smell, but one every OOP programmer knows deep in his soul: using a primitive data type instead of a domain-specific type. James Shore calls this smell Primitive Obsession, and Kevin Rutherford calls it Primitive Feature Envy.
Chris has been justifiably lauded for starting a conversation on this topic. I find this smell in my programs and even in many of the programs I read from good OOP programmers. When programmers are first learning to write object-oriented programs, the tendency to write code in terms only of the primitive data types is hard to shake. Who needs that Piece class, when a simple integer flag taking values from 1 to 4 will do just fine? (Heck, we can always use Hungarian Notation to make the semantics clear. :-) When students come to see the value of that Piece class, they begin to see the value of OOP.
That said, we have to be careful to remember that this smell is not an absolute indicator. There is an inherent tension between the desire to create classes to model the domain more closely and the desire to do the simplest thing that could possibly work. If I try to wrap every piece of primitive data in its own class, I can very quickly create a lot of unnecessary code that makes my program worse, not better. My program looks like it has levels of abstraction that simply aren't there.
That's not the sort of thing that Chris, James, and Kevin are advocating, of course. But we need to learn how to strike the proper balance between Primitive Obsession and Class Obsession, to find the abstractions that make up our domain and implement them as such. I think that this is one of the reasons that Eric Evans' book Domain-Driven Design is so important: it goes a long way toward teaching us how to make these choices. Ultimately, though, you can only grok this idea through experience, which usually means doing it wrong many times in both directions so that your mind learns the patterns of good designs. As Chris', James', and Kevin's articles all point out, most of us start with a predilection to err on the side of primitives.
One way to push yourself to learn this balance is to use the Three Bears pattern first described by Kent Beck to create situations in which you confront the consequences of going too far one way or the other. I think that this can be another one of those programming etudes that help you become a better programmer, a lá the Polymorphism Challenge that Joe Bergin and I used at SIGCSE 2005, in which we had folks rewrite some standard programs using few or zero if statements.
In order to feel the kind of effects that Chris describes in his article, you have to live with your code for a while, until the specification changes and you need that tolerance around your masses. I think that the folks running the ICFP 2005 programming contest are using a wonderful mechanism to gauge a program's ability to respond to change. They plan to collect the contestants' submissions and then, a couple of weeks later, introduce a change in the spec and require the contestants to adapt their programs on an even shorter deadline. What a wonderful idea! This might be a nice way to help students learn the value of adaptable code. Certainly, Primitive Obsession is not much of a problem if you never encounter the need for an abstraction.
Ron Jeffries posted a message to the XP discussion list earlier today confessing that one of his weaknesses as a programmer is a tendency to create small classes too quickly. As an old Smalltalker, he may be on the opposite end of the continuum from most folks. But we need a good name for the smell that permeates his code, too. My "Class Obsession" from above is rather pedestrian. Do you have better name? Please share... Whatever the name, I suspect that Ron's recognition of his tendency makes it easier for him to combat. At least he knows to pay attention.
Chris's article starts with the idea of favorite smells but then settles on one. It occurs to me that I should tell you my personal favorite smell. I suspect that it relates to duplication; my students certainly hear that mantra from me all the time. I will have to think a bit...
My family's weekend at the caves was a great success, both for family and relaxation. This is a completely personal entry, so feel free to move on if you are looking professional content...
South-central Kentucky in the US is one of the most cavernous terrains in the world. My wife, my two daughters, my mom, and four nieces and nephews met there for a long weekend of vacation. In our two days in the area, we visited three different cave systems, all within five miles of one another.
First up was the magnet that drew us to the area, Mammoth Cave National Park. At over 350 miles, Mammoth Cave is the longest known cave system in the world. On our first day together, we took the relatively easy hour-long "discovery tour" of Mammoth Cave, followed by a few hours of hiking the national park trails. The discovery tour introduces visitors to the history and geology of the cave via a gentle walk.
Next time, I'll sign up for the longer, more strenuous Frozen Niagara tour. If you are a real spelunker, or want to be one, you can take specific tours that explore deeper and less accessible portions of the cave.
On our second day, we visited two other caves in the area. Hidden River Cave has the second-largest cave opening in the world -- only Carlsbad Caverns' is larger. It is also one of only two river cave tours in the US. The river is small but steady, with crystal water. You enter the cave by descending through an old sinkhole located right on Main Street in the town of Horse Cave. I was amazed to find this cave site while running through town that morning -- it is stunning. The picture at the right shows the view as members of my tour were leaving the cave; I couldn't do justice to the mouth of the cave from above.
The cave site also hosts a museum that is worth an hour or so. On both the cave tour and museum visit, you learn that Hidden River Cave is one of the great environmental reclamation successes of the last half century. This cave was a popular tourist attraction from 1916 through 1943, when it had to close due to pollution. The residents of the region had been disposing of their garbage and sewage by throwing it all into the many sinkholes that pockmark the area. These sinkholes feed the underwater river that flows through the Hidden River Cave. By the mid-1980s, the cave was such a polluted mess that the town above nearly died. The clean-up has been remarkable. Through education, folks stopped the dumping, and Mother Nature repaired herself. The river itself is clean now, and the cave is clean and pleasant.
We ended our caving with a visit to Diamond Caverns, which is the best "formation cave" in the area. A formation cave is distinguished by the quantity and quality of its stalactites and stalagmites, the features most folks think of when they think of caves. Diamond Caverns' formations have spectacular shapes and colors. On this tour, I learned about The Cave Wars waged in the first decades of the 1900s by the owners of the commercial cave tours in the Mammoth Cave region. The owners tried to increase their own profits by damaging the other caves. As the most beautiful cave in the region, Diamond Caverns was a frequent target, and it suffered extensive damage to some of its chambers. Even still, it was worth a visit.
For the runners among you: I did manage to work in a short long run on Sunday, an 11-mile out-and-back jaunt between our hotel in Cave City and the eastern edge of Horse Cave. The two towns are connected by old U.S. 31, a two-lane highway. The motorists I encountered were not malicious, but they didn't seem to think they should change their behavior to account for a runner in their midst. Fortunately, I ran 5:30-7:00 AM, and the road had sidewalks and grassy shoulders.
This was the first break I'd taken from work since at least March, and my mind enjoyed it. Now, it's back to work -- with slack built into my schedule for summer.
I feel a strong desire to write a substantive essay on something of great import, but at the same time I feel that I have nothing of great value to say today. I suspect that this is my mind and brain telling me to take a break, after a busy spring semester and all of the busy-ness that has followed. I'm due for some time away from the office. Fortunately, that is what's about to happen.
In the US, this is Memorial Day weekend. My family and I will be using the long weekend to tour the caves at Mammoth Cave National Park in Kentucky. Mammoth Cave and its neighbors are the longest known system of caves in the world. I lived the first half of my life only a couple hours drive from this park but have never visited. My 12- and 9-year-old daughters will be able to say that they spelunked there, though we'll have to drive 9-10 hours to do it.
This won't be my first spelunking adventure. While in Arizona the week before ChiliPLoP, I went with a few friends for a short cave tour just outside of Tucson. We were all in town to watch NCAA tournament games. By the time we reached the cave, I had already run 9 miles and played 90 minutes of basketball that morning. At least I should be better rested for Mammoth Cave, which will entail some more strenuous climbing.
Last weekend, while my daughter was doing a final practice for her Suzuki Book I recital, I picked Vaclav Havel's The Art of the Impossible: Politics as Morality in Practice off the piano teacher's bookshelf for a little reading. This is a collection of speeches and short essays that Havel in the first half of the 1990s about his role as dissident, reformer, and president of the Czech Republic. He is, of course, famous as a poet, and his writing and speaking style have a poet's flare.
I ended up spending most of my time with Havel's speech to the Academy of Humanities and Political Sciences in Paris on October 27, 1992. (I just noticed the date -- that's my birthday!) This speech discussed the different forms of waiting.
The first kind is sometimes characterized as waiting for Godot, after the absurdist play by Samuel Beckett. In this form, people wait for some sort of universal salvation. They have no real hope that life will get better, so they hold tightly to an irrational illusion of hope. Havel says that, for much of the 20th century, residents of the former communist world waited for Godot.
At the opposite end of the waiting spectrum lies patience. Havel describes patience as waiting out of principle -- doing the right thing because it is right, not out of any expectation of immediate satisfaction. In this sense, patience is "waiting as a state of hope, not as an expression of hopelessness". Havel believes that the dissidents who ultimately toppled the communist regimes behind the Iron Curtain practiced this sort of waiting.
When the curtain fell and the people of, say, Czechoslovakia took their first unsteady steps into the light of the western world, folks practicing the different forms of waiting encountered distinctive problems. Those who had been waiting for Godot felt adrift in a complex world unlike anything they had known or expected. They had to learn how to hope and to be free again.
You might think that the patient dissidents would have adjusted better, but they faced an unexpected problem. They had hoped for and imagined a free world around them, but when they became free things didn't change fast enough. Havel relates his own struggles at being too idealistic and now impatient with the rate at which the Czech and Slovak republics assumed the mantel of democratic responsibility. Like many revolutionaries, he was criticized as out of his element in the new world, that he was most effective in the role of dissident but ineffective in the role of democratic leader.
What struck me most about this essay came next. Havel recognized the problem: He had waited patiently as a dissident because he had no control over how anyone but himself behaved. Now that the huge impediment of an authoritarian regime had been surmounted, he found that he had become impatient for all the details of a democratic system to fall into place. He no longer waited well.
In short, I thought time belonged to me. ...
The world, Being, and history have their own time. We can, of course, enter that time in a creative way, but none of us has it entirely in his hands. The world and Being do heed the commands of the technologist or the technocrat....
In his own transition from dissident to democratic leader, Havel learned again that he had to wait patiently as the world takes its "own meandering course". He asserts that the "postmodern politician" must learn waiting as patience -- a waiting founded on a deep respect for the world and its sense of time. Read:
His actions cannot derive from impersonal analysis; they must come out of a personal point of view, which cannot be based on a sense of superiority but must spring from humility.
When the world changed, even in the way for which he had been working, Havel had to learn again how to be patient.
I think that the art of waiting is something that has to be learned. We must patiently plant the seeds and water the ground well, and give the plants exactly the amount of time they need to mature.
Just as we cannot fool a plant, we cannot fool history.
I think that 'waiting patiently as the world takes its own meandering course' translates into showing respect for people and the rate at which they can assimilate new ideas and change their behavior.
Perhaps this speech affected me as it did because I am now thinking about leading my department. I certainly do not face a situation quite as extreme as Havel did when the communist regime fell in Czechoslovakia, yet I am in a situation where people do not trust the future as much as I'd like, and I need to find a way to help my department move in that direction. As Havel reminds me, I cannot move the department myself; I can only patiently plant the seeds of trust, water the ground well, and give the plants the time they need to grow.
The value of this sort of waiting is not limited to the world of administration. Good instructors need to wait patiently, working with students to create the atmosphere in which they can grow and then giving them time and opportunity to do so.
I also think that this sort of waiting holds great value in the world of software development. Agile methods are often characterized by folks in the traditional software engineering world as impatient in their desire to get to code sooner. But I think the opposite is true -- the agile methods are all about patience: waiting to write a piece of code until you really know what it should do, and waiting to design the whole program until you understand the world well enough to do it right. In this sense, traditional software engineering is the impatient approach, telling us to presumptuously design grand solutions to force the world to follow our senses of direction and time. The worlds in which most programs live are too complex for such hubris.
I cannot resist closing with one last quote from the rich language of Havel himself:
If we are certain that the planting was good and that we are watering regularly, we have no reason to be impatient. It is enough to realize that our waiting has meaning.
Waiting that has meaning because it grows out of hope and not hopelessness, from faith and not despair, from humility toward the time of the world and not out of fear of its sublime tranquility, is accompanied not by boredom but by suspense. This kind of waiting is more than just waiting.
It is life. Life as the joyous involvement in the miracle of Being.
That sounds like a poet speaking, but it could be a programmer. And maybe the world would be a better place if all administrators thought this way. :-)
When I first started thinking about applying for the position of department head, a former student asked me how I give up time from my classroom teaching, which is where, from his point of view, the best part of an academic's life happens: the A-ha! moment, when a student suddenly gets it. This particular student likes to teach just for those moments.
I like the A-ha! moments, too, and will miss having more opportunities to experience them. (For the next few semesters, I will be teaching one course each term rather than three.) Sometimes, though, other things are more important, and I think this is one of those times.
A-ha! moments are wonderful, but there is another kind of moment that I find as gratifying if not more. The movie The English Patient captures one of these moments perfectly; writer Ron Rolheiser describes just how in one of his essays:
In the movie, The English Patient, there's a wonderful scene, stunning in its lesson:
A number of people from various countries are thrown together by circumstance in an abandoned villa in post-war Italy. Among them are a young nurse, attending to an English pilot who's been badly burned in an air-crash, and a young Asian man whose job it is to find and defuse land-mines. The young man and the nurse become friends and, one day, he announces he has a special surprise for her.
He takes her to an abandoned church within which he has set up a series of ropes and pulleys that will lift her to the ceiling where, hidden in darkness, there are some beautiful mosaics and other wonderful works of art that cannot be seen from the floor. He gives her a torch as a light and pulls her up through a series of ropes so that she swings, almost like an angel with wings, high above the floor and is able to shine her torch on a number of beautiful masterpieces hidden in the dark.
The experience is that of sheer exhilaration; she has the sensation of flying and of seeing wonderful beauty all at the same time. When she's finally lowered back to the floor she's flushed with excitement and gratitude and covers the young man's face with kisses, saying over and over again: "Thank you, thank you, thank for showing this to me!"
And, from her expression, you know she's saying thank you for two things: "Thank you for showing me something that I could never have come to on my own; and, thank you for trusting me enough to think that I would understand this, that I would get it!"
I'm not in teaching for the kisses (if I were, then I would be judged a horrible failure), but this is the sort of moment that touches me deeply in teaching. Something like this doesn't happen all that often, but it happens as often as the revered A-ha! moment. And I think it is a better reflection of how a student-teacher relationship should be viewed. The best part of teaching lies not in giving the student new knowledge, or even helping the student to understand something complex or difficult -- though that's important. The best part is in helping students go places and see things that they wouldn't have gone and seen otherwise.
I think that this is possible more often than we sometimes let ourselves believe. The key lies in the second part of the nurse's thank-you in the movie: We have to trust our students and apprentices to "get it", to appreciate beauty and elegance. We do more damage to learners by not trusting them than by explaining poorly of expecting too much.
Why do I get the strongest urge to blog about running on Sunday mornings? Maybe because the long runs give me plenty of time to think. But I think it's more -- long runs take more out of me, but they also lead to an endorphin rush that I don't get on shorter runs.
I ran sixteen miles this morning. It was my longest run since the Des Moines Marathon. Since then, I have run a few 14-milers and a couple of half-marathon training runs, but nothing more.
Sixteen miles has always been a crossover point for me, where medium-sized runs become long runs. My first 16-miler two years was my least enjoyable run ever. I ran it under conditions that were a recipe for a bad experience, but that never changed how I felt about the distance. My next 16-miler came last spring, the morning after torrential rains had flooded most of the Cedar Valley. I got six miles from home to find myself running through knee-deep water coursing over the trail. Great fun, I know, though the run turned out better than that first.
Since then, I have had better experiences. A couple of weeksa ago I got the itch to go long again, so I built myself toward a sixteen today. It was a glorious morning. The sun was up soon before 6:00 AM, and the temperature in the low 50s was perfect to start. I felt good early, hit the usual lull that happens at ten miles or so, and finished strong over the last two miles.
The strangest part of the run came early, in the third mile, when I ran through a ten-second period where the outside temperature must have been 20 degrees warmer than the rest of the run. I was in the middle of a wooded area on a trail, not near any large source of heat, so I don't know what caused it. As quickly as it came, it left; my glasses unfogged, and the run went back to normal.
I sometimes wonder if I ought to be working so hard on Sunday. But I don't think of it as work, really, and I run early enough in the day that I can go to morning Mass. Besides, if there is a better way for me to revel in the glory of Creation, I don't know what it would be.
I've been thinking a bit about how much the agile software development mindset affected my application for department head. When I first starting making notes for my statement of administrative philosophy, I jotted down some agile ideas: communication, people over processes, trust. Later, as I made notes for my presentation to the search committee, I again had a bullet for agile ideas, with feedback and continuous improvement appearing.
In the end, many of these ideas played important roles in my application. Open communication and building trust became cornerstones of my philosophy. Feedback and continuous improvement became cornerstones of my plan for doing the job. I never got around to using the term "agility" in any of my materials, but its footprint was everywhere.
My administrative philosophy rested on three points:
These principles are essential to any healthy organization. They are perhaps even more important in an academic department, which consists of individuals who are both highly autonomous but also interdependent. They are especially important in a department fraught with lack of trust and persistent interpersonal conflict.
These principles are also very much a part of the agile software movement. Communication fosters trust and enables feedback, which is how we learn to do our jobs better. People matter. What about transparent decision making? Only decisions are made openly can everyone involve contribute to the process. I believe that, in most situations, more ideas lead to better results. Furthermore, when someone disagrees with the decision that is made, at least the person can trust that the decision was made fairly and on principle.
Some folks think that preferring people to processes means having little or no process. Others think that not tying themselves down with process (in administrative parlance "procedures and policies") frees them to adapt better to changing circumstances. Though I value adaptability, and people over process, I believe that appropriate process is essential to effective operation. XP isn't just a set of values or a set of principles; it is also a set of practices. These practices support the values and principles, make it possible for the team to live its values and embody its principles. I hope to help my department develop an appropriate set of procedures and policies. This will involve streamlining some of our existing procedures and implementing some new ones.
Soon after I submitted my application materials, a related discussion developed on the XP discussion list. It started with a request for advice for navigating the waters of corporate politics and soon turned into a discussion of how the principles and practices of P can help us to create a good corporate environment. Along the way, someone said,
Ok, those are good suggestions for navigating oneself through everyday relationships, in and out of work. But they are not techniques that are specific to XP.
The answer to this assertion is both yes and no. Certainly, communication, feedback, continuous improvement, and the like are not specific to XP or any other agile methodology. But they are fundamental to the agile methods, and by making them explicit the agile methods help us to reflect and act on them more readily.
As I told my colleagues and the other members of the search committee, I harbor no illusions that I will do this job perfectly. But I hope that, by making explicit the values that I hold and the principles that I think should guide our department, I hope to do a good job -- and to get better as I go along. This will depend in great part on the level of trust and communication that we are able to develop.
As mentioned last week, I recently applied for the position of department head in my home department. After interviews scattered over the final three days of last week and a weekend of wa-a-a-iting (cue Tom Petty), the Dean called me yesterday to offer me the job. I start on August 1.
I will continue to teach one class each term, for a total of three a year. So I expect to keep blogging about teaching and learning and software development on a regular basis. But because I blog mostly to examine what I am doing and learning, I expect that I'll be posting a new thread of messages over the next three years to examine the administrative and leadership side of my job. To this end, I am creating a new category, Managing and Leading, for this thread.
(Those of you who come here to read about running, fear not! That thread will continue as usual. I've run 74 miles in the last 11 days, so I have plenty of raw material!)
Some of my first entries in this new category will likely deal with what I've been reading about working with people, leadership, and technical administration. I think I've been subconsciously preparing for this role for a few years. But I still have a lot to learn.
My official start date is August 1, but I'll be putting significant energy into the job before then. As I said, I have a lot to learn. Busy, busy, busy.
I just read Joel Spolsky's latest essay, Making Wrong Code Look Wrong. I'm all for Joel's goal of writing code that reveals the writer's intention, of making code transparent to the reader. And I'm sympathetic to his concerns about operator overloading in C++ and leaky abstractions. But the following paragraph exemplifies why I find his C-at-all-costs mentality somewhat uncomfortable:
If you read Simonyi's paper closely, what he was getting at was the same kind of naming convention as I used in my example above where we decided that us meant "unsafe string" and s meant "safe string". They're both of type string. The compiler won't help you if you assign one to the other and Intellisense won't tell you bupkis. But they are semantically different; they need to be interpreted differently and treated differently and some kind of conversion function will need to be called if you assign one to the other or you will have a runtime bug. If you're lucky.
Does anyone else think that Joel needs a really good abstraction here? If my program deals with two different kinds of string -- objects that are semantically different -- then I'd like to reflect that in more than a cryptic two-letter prefix. Classes may seem like overkill for these kinds of thing, but enums and Ada subtypes can be wonderful aids. Then, instead of relying solely on the programmer to read and interpret the prefixes, we could let our compilers and refactoring tools help us.
Intention-revealing names are an important part of transparent code, but we should use languages and techniques that support our efforts, too.
before you can think out of the box,
you have to start with a box
-- Twyla Tharp
I've been reading Twyla Tharp's The Creative Habit, and that quote is the title of Chapter 5. As soon as I read it, I scribbled it down immediately on the note card I had tucked in the back of the book for just such occasions. The idea of "starting with a box" struck me in a particular way, and as I read the chapter I went through a journey from thinking that Tharp meant something else to thinking that, ultimately, we were onto the same idea. For Tharp, "the box" is as organizational system, a way of storing and managing her memory as she works on a new creative project. But the box is more than that -- it is really about preparation.
Bobby Knight, the famous US college basketball coach, once said something along the lines, "The will to win is the most overrated desire in all of sports. Everybody has the will to win. What separates those who succeed is the will to prepare to win."
I often encounter students who say that they can be successful contributors in the software industry despite their unwillingness to work hard to become really good programmers -- because they will be part of a team in industry. I guess they figure that some other member of the team is going to do the heavy lifting. My response to them is always the same: Why would a team want you as a member if you can't help with the most important product it produces? That's awfully presumptuous of you. For some folks, the desire not to program is borne out of a lack of interest in programming. But for many it grows out of a lack of success, and a consequent unwillingness to do the hard work needed to prepare for programming tasks.
Most people can tell when they are unprepared for a job, though our egos sometimes hide the truth from us. Introductory students often come to my office with questions about a programming assignment, saying, "I know just what I want to do, but when I try to write the program I just can't say it in Java." (In earlier years, it was C++, or Pascal.) Again, my response is often the same: You don't really know what you want to say, or the program would come more easily. Tharp says so, too, using a journalist as her example:
If his reporting is good, the writing will reflect that. It will come out quickly and clearly. If the reporting is shoddy, the writing will be, too. It will be torture to get the words out.
Some may think that this all sounds bad for agile methodologies, which de-emphasize months of on-project preparation of requirements and design. But I think that this line of thought betrays a misunderstanding of agile methods, one reflected in the idea that they are reckless. Unprepared developers cannot write good software using an agile method. Agility doesn't mean not being prepared; it means letting your preparation work in concert with concrete steps forward to prepare you even better for what comes next.
One thing I like about Tharp's chapter is that she doesn't stop at "be prepared". She reminds us that preparation is only preparation.
The box is not a substitute for creating. The box doesn't compose or write a poem or create a dance step. The box is the raw index of your preparation. It is the repository of your creative potential, but it is not that potential realized.
You still have to create! You have to write code. You have to pull your head out of design-land, out of the code library, out of the archives and actually begin writing code.
Sadly, some people never get beyond the box stage in their creative life. We all know people who have announced that they've started work on a project ... but some time passes, and when you politely ask how it's going, they tell you that they're still researching. ... Maybe they like the comfort zone of research as opposed to the hard work of writing. ... All I know for sure is that they are trapped in the box.
Some students do this, too. They work hard -- they really do -- but when the assignment comes due, there is no program to turn in; they never got around to actually producing something. And the program is the whole point of the assignment. Okay, okay, learning is probably the real point of the assignment, but you can't learn what you really need to learn until you write the program!
This is where we can see a strong connection to the agile methods. They encourage us to be in a continuous state of writing small bits of code, testing and designing, cycling quickly between planning and producing.
Tharp ends her chapters with exercises for the reader, activities that can help readers work on the idea they've just read about. The section at the end of "start with a box" consists of a single exercise, and it's not especially concrete,. But it does have an agile feel to it. When you are having a hard time getting out of the box, take a big leap somewhere in the project. Don't worry about the beginning or the end; just pick something, an especially salient point (or user story) and get to work. You never know where it will take you.
"Getting out of the box" was one of the primary motivations for me starting my blog. I had boxes and boxes of stuff (metaphorical boxes, of course -- mine were either computer files or file folders stuffed with hastily written notes). But I had stopped taking the risk of putting my thoughts out in the public space. In that regard, this blog has been a huge success for me.
A while back, I mentioned my intention to apply for a job here at the university. The position is head of my department, and last week I did apply. The search is internal, which means that we are considering only current members of the faculty as candidates, and is for a three-year appointment. When I decided to apply, I didn't realize how tense I'd feel at the prospect of interviewing with my colleagues! I think this is the good sort of tension, though, the kind that lets me know that I really do care about the job. It's good to take risks of this sort every once in a while.
The application process required a fair bit of writing, most notably a statement of administrative philosophy, that kept me busy last week. This week, I am preparing a short presentation to give to the faculty, on philosophy and goals for the department. The process has reminded of two things:
Sometime later this summer, I may write up a more general version of the ideas that went into my application and share them here. In the meantime, wish me luck!
(I wrote a complete essay on this topic over the course of several hours on Monday and then, in a few swift seconds of haste, I did the unthinkable: I rmed it. Sigh. I don't know if I can reproduce that wondrous work of art, but I still have something I want to say, so here goes.)
Last time, I wrote about how having a standard literary form can ease the task faced by writers and readers, including reviewers. I found this to be true of submissions to the OOPSLA Educators Symposium, and my colleague Robert Biddle found it to be true of submissions to the conference's practitioner reports track. From this starting point, Robert and I moved onto an ambitious idea.
I closed my last entry with a cliffhanger: The unsupported claim that "the lack of a standard form is especially acute in the area of practitioner reports, which have the potential to be one most important contributions OOPSLA makes in the software world." This time, I'd like to talk about both parts of this claim.
First, why is the lack of a standard literary form especially acute in the area of practitioner reports?
Keep in mind that the authors of practitioner reports are software practitioners, folks in the trenches solving real problems. Most of these folks are not in the habit of writing expository prose to teach others or to share experiences -- their jobs are primarily to create software. Unlike most submitters to the Educators Symposium, the authors of practitioner reports are usually not academics, who typically have experience with expository writing and and can at least fall back on the literary forms they learned in publishing academic papers. (Sadly, those forms tend not to work all that well for sharing pedagogical experience.)
Not having a standard literary form makes writing and reading practitioner reports that much harder. How can authors best communicate what they learned while building a software project? What ideas do readers expect to find in the paper? What's worse, because many software developers don't have much experience writing for a broad audience, not knowing how to go about writing a paper can create a considerable amount of fear -- and the result is that many practitioners won't even try to write a paper in the first place. It turns out that a standard literary form has another benefit: it provides comfort to potential authors, lowering the entry barrier to new writers.
A great example of this effect is the software patterns community. Its popularization of a common and powerful literary form made it both possible and attractive to many practicing software developers to record and disseminate what they had learned writing programs. The software community as a whole owes an extraordinary debt for this contribution.
So, I contend that the practitioner's track would benefit even more than the educators' track from the creation and widespread adoption of a standard literary form. (But I still hope that we educators will take steps to improve our lot in this regard.)
Second, how do practitioner reports have the potential to be one most important contributions that OOPSLA or any other conference makes in the software world?
Keep in mind that the authors of practitioner reports are software practitioners, folks in the trenches solving real problems. Researchers and methodologists can propose ideas that sound great in theory, but practitioners find out how well they work in the real world, where academic abstractions take a back seat to the messiness of real businesses and real people and real hardware. Even when researchers and methodologists make a good-faith effort to vette their ideas outside of their labs, it is difficult to recreate all the complexities that can arise when new adopters try implement the ideas in their organizations.
The result is, we don't really know how well ideas work until they have been tried in the trenches. And practitioner reports can tell us.
Sharing knowledge of a practical sort used to lie outside the domain of computer science and even software engineering, but the software patterns movement showed us that it could be done, that it should be done, and gave us some hints for how to do it. The potential benefit to practitioners is immeasurable. Before trying out XP, or migrating from Visual Basic to VB.Net, or integrating automated acceptance tests into the build cycle, a practitioner can read about what happened when other folks in the trenches tried it out. Usually, we expect that the ideas worked out okay in practice, but a good report can point out potential pitfalls in implementation and describe opportunities to streamline the process.
Of course, academics can benefit from good practitioner reports, too, because they close the loop between theory and practice and point out new questions to be answered and new opportunities to exploit.
Robert and I didn't talk much about what I've written so far in this entry, because we rather quickly moved on to Robert's bigger vision of what practitioner reports can be, one that presupposes the untapped value buried in this resource: the software case study.
As Robert pitched it, consider NCSA Mosaic. Here is a program that changed the world. How was it built? What technical and non-technical problems arose while it was being written, and how did the development team solve them? Did serendipity ever strike, and how did they gain leverage? We can find the answers to all of these questions and more -- the creators are still around to tell the story!
Case studies are a standard part of many disciplines. In business schools, students learn the how companies work by reading case studies. I remember well a management course I took as an undergraduate in which we studied the development of particular companies and industries through case studies. (Most of what I know about the soft drink industry came from that case book!) Of course, the law itself is structured around cases and webs of facts and relationships.
We are fortunate to have some very nice case studies in computing. Knuth has written widely about his own programs such as Tex and his literate programming tools. Because Smalltalk is as much system as language, Alan Kay's The Early History of Smalltalk from History of Programming Languages II qualifies as a software case study. Other papers in the HOPL volumes probably do, too. I have read some good papers on Unix that qualify as case studies, too.
Two of my favorite textbooks, Peter Norvig's Paradigms of AI Programming and Clancy and Linn's Designing Pascal Solutions, are built around sets of case studies. In the latter, the cases were constructed for the book; in the former, Norvig analyzes programs from the history of AI and reimplements them in Common Lisp. (You really *must* study this book.) I even used a case study book as a CS undergrad: Case Studies in Business Data Bases, by James Bradley. It's still on my bookshelf. More recently, the College Board's Marine Biology Case Study has received considerable attention in the AP and CS1 communities.
So, if we believe that software case studies have merit, we find ourselves back in the trenches... How do we write them? Using an excellent case study as an exemplar would be a start. I suggest that any case study of value probably must tell us at least three things:
Robert and I will likely work on this idea further. If you have any ideas, please share them. In particular, I am interested in hearing about existing and potential software case studies. Which of the case studies you've read do you think are the best exemplars of the genre? Which programs would you like to see written up in case studies?
Over lunch today, Robert Biddle and I discussed some thoughts we had after reviewing submissions to the OOPSLA Educators Symposium and practitioners reports track this year. Both of these tracks suffer from a problem that had never really occurred to me before this year: not having an accepted form for telling stories.
If you read the proceedings of most computer science conferences, you will recognize that all the papers have a similar look and feel. This is the way that scientists in the domain communicate with one another. One function of a common form is to ensure an efficient exchange of information; having a common style means that readers immediately feel at home when they come to a paper. But there is a subtle secondary function, too. When you see a paper, you can tell whether the author is a part of the community or not.
One of the the things that makes reviewing papers for the Educators Symposium tough is the variety of papers. With no standard, authors are left to mimic other papers or invent new forms that fit the story they want to tell. But every new form makes the program committee's job harder, too. How do we evaluate the contribution of a paper that looks and sounds different than any we've seen? What role should experimental validation of a teaching technique play? What role should an explanation of lessons learned, or a discussion of how to implement the technique at a different institution?
Most frustrating for me as program chair were situations in which two reviewers evaluated the same paper in essentially complementary ways. This isn't a fault of the reviewers, because the community as a whole has not reached a consensus for what papers should be like. I suppose that one of my jobs as program chair is to guide this process closely, working with the program committee to give authors and reviewers alike a better sense of what we are looking for in submissions. The nifty assignment track that I introduced to the symposium last year was an attempt in this direction. I borrowed from a successful form used at recent SIGCSEs to encourage OO educators to tell the stories of their coolest and most engaging programming assignments. Having an expectation of what a nifty assignment should look like has led, I think, to a more satisfying evaluation process for these submissions.
Maybe we as a community of educators need to work together to develop a standard way to tell teaching stories. Perhaps the greatest contribution of the software patterns community was to standardize the way practitioners and academics discuss the elements of program design and construction at a level above algorithms and data structures. As linguistic form, it enables communication in a way that was heretofore impossible.
Notice here that a common literary form is more than a literary format. The patterns community is a good example of this. Even after a decade there are a number of accepted formats for writing patterns, some favored by one group of writers, some viewed as especially effective for patterns of a particular sort. The key to the pattern community's contribution is that it establishes expectations for the content of software patterns. I can comfortably read a pattern in almost any format, but if I can't find the context, the problem, the forces, and the solution, then I know the pattern has problems. The PLoP conferences play the role of enculturating pattern writers by helping them to learn the standard form and how to use it.
The lack of a standard form is especially acute in the area of practitioners reports, which have the potential to be one most important contributions OOPSLA makes in the software world. I'll have more to say about this tomorrow.
Today and tomorrow, I am in San Diego for the OOPSLA 2005 spring planning meeting. I have the honor of chairing the Educators Symposium again this year and so am on the conference committee that makes OOPSLA happen. As usual, I'm impressed by the energy and talent of the people behind the scenes of OOPSLA. These folks are in the trenches scheduling talks and panels, tutorials and workshops, while simultaneously thinking about the future of software and where the conference can and should go in the future.
San Diego will be a great location for OOPSLA. We are at the Town and Country Resort, about 15 miles from downtown. The resort is more than just a hotel; the property includes several buildings of convention space, meeting rooms, and restaurants, not too mention the pools and outdoor gathering spaces. San Diego's temperate weather makes outdoor gatherings a real possibility. On our site tour earlier, a couple of us joked about holding software demonstrations poolside -- or even on the water, the "floating demo". We may as well surrender to the inevitable temptations that accompany meeting space adjacent to an outdoor pool.
Last night, I had the pleasure of catching up with a current friend, a former student who now calls San Diego home. Kris picked me up, gave me a short driving tour of the area, and then took me off for dinner with another former UNI student, a former Waterloo native, and another Iowan. We talked sports, much to the chagrin of the ladies, and current campus goings-on. Dinner was at Quiigs Bar and Grill (5091 Santa Monica Ave) -- I had a wonderful grilled prawns dish.
This morning, I checked out the running options from the hotel. I did an easy 10+-miler, heading west along Friars Road toward the beach. I never reached the beach but I did find an unexpected bonus: down near a marina off Sea World Drive, I came upon the start location for the Spring Sprint Triathlon and Biathlon. This is a little tri, a ¼-mile swim, a 9-mile bike, and a 3-mile run -- just within my reach. One of these days...
Dick Gabriel and Ralph Johnson have a lot of neat ideas in the works for OOPSLA this year, including a track for essays, collocated symposia on wiki and Dylan, and the evolving Onward! track, which will debut a film festival. If you want to know what software people will be talking about in earnest three or four years from now, make sure to attend OOPSLA this year!