This was my first column in The Smalltalk Report.

The Smalltalk Report occupies an important position in legitimizing Smalltalk. While it has in the past seemed the ugly stepchild of the SIGS family, the mere fact of its existence has gone far towards convincing reluctant decision makers that Smalltalk is worth betting on

When I started writing for The Smalltalk Report, I had already made something of a name for myself in the Smalltalk world. The CRC paper was out and making its splash, I had been working on Smalltalk in various guises for eight years, and I was well into my tenure at MasPar.

My life in a startup cloister was a big part of my decision to begin writing the column. Startups are great fun, but you don't join one to see the world and become famous (if you're not in sales, anyway). Writing the column kept me in touch with my friends.

In the end, the benefits of writing the column were much greater than I had imagined, as were the pains. It always seemed that the next deadline hit just after I'd finished the last column. Dragging fingers to keyboard when a paying customer was already waiting for code was tough. However, I got much more from the column than I put into it. First, I learned to write. You will see a distinct change in my writing style from the first columns to the last.

The previous column got me started examining why people create classes. About this time, I had collected enough patterns to begin thinking about the patterns book. Of course, at first I was going to cover all of programming/analysis/design/project management/etc. in a single book. This exploration was the beginning of trying to write the analysis/design portion of the book.

One of the things I like about writing a column is that it forces you to think hard about a topic at regular intervals. I'm the kind of person who dives deep into a topic until I'm bored, and then drifts until something else catches my eye. I get to study lots of cool stuff that way, but I don't really penetrate to insight. Writing a column returns me to roughly the same place every month and pushes me to find something new. The result is much more valuable thinking.

I think this was originally titled “Inheritance: The Rest of the Rest of the Story,” but it got edited. Oh well.

The pattern presented here is another in the “Transformation Series.” It recommends letting inheritance evolve from the need to reduce code duplication.

Yet another brutal review. I never write a tough review without questioning myself: “Is it just me? Am I just not smart enough to get this product? Who am I to tell someone else what to do?”

I am just now getting comfortable with writing what I know and trusting my readers to take what I say and add their perspective and experience to it.

Well, at least I didn't just present instance-specific behavior as a pointy-hat technique. I tried to extract some cultural lessons from it. Now that the Smalltalk world has contracted to a couple of big players, there isn't enough cultural diversity left to analyze. Ah, the olden days, back when we used to have to walk miles barefoot in the snow to get coal to shovel into our Smalltalk machines… Now I sound like an old fart

Just when I write something that is too short, I write some that is too long. I was really in the groove of writing columns by this time, and I'd wait until the last minute. Sometimes, as in the previous column, this left me a little short. Sometimes as in this column, I ended up starting something I couldn't finish.

This column points to one of my weaknesses as a writer—I don't turn to pictures nearly soon enough. The material covered here would make much more sense with a few well-chosen pictures. If you get bogged down, try drawing the pictures yourself. That's what I do, even if I don't often publish them.

Why we need to wrap.

What the approaches to wrapping are.

When, and when not, to use the following wrapping technologies: C APIs, dynamic shared libraries, screen scraping, peer-to-peer, and the Common Object Request Broker Architecture (CORBA).

The trade-offs of wrapping.

Information technology shops of today have a huge investment in information technology; unfortunately, the vast majority of it isn't object oriented (OO). In the 1980's it is estimated that over $ 1 trillion was invested in information technology in the United States alone. Needless to say organizations are motivated to retain as much of this investment as possible. Wrapping is a technique in which you make non-OO technology appear to be OO by putting a layer of OO code around it, which is often a critical part of any significant OO project.

Oooooh, my first process pattern. All of the patterns I had written to date talked about programming things. This column introduced the first pattern that talks explicitly about people activities.

Jim Coplien was one of the first people to start writing lots of good patterns. Even though he is a good programmer, he chose to write his patterns out of his experience analyzing software development organizations. I was skeptical at first—what do these patterns of how people behave have to do with programming? It was around the time of this article that I began to realize that his perspective was as important as mine. It doesn't matter how good a job you do if you're doing the wrong job.

To make up for all the icky squishy stuff, I made sure I included plenty of code in the column. As aggressive as I think I am, looking at these columns reminds me that I go in the water half a toe at a time.

After the brief pause in the previous column to discuss philosophy, this column descends again into the depths of techno-minutiae. At least I talked about why you'd want to use instance-specific behavior, and didn't just present it as:“Here's a cool thing you can do with Smalltalk.”

The pattern Scriptable Objects still looks pretty good to me. In fact, I like it better as a pattern than many of the patterns that follow.

This was a very important article for me. I had been writing solo for some time. I needed to collaborate more, especially since I had been independent for almost a year and I was getting lonely for technical collaboration.

Bruce Anderson organized this fantastic workshop for IBM at its educational site in Thornwood, New York. Ralph Johnson was another one of the teachers. Late one night, I grabbed him and said, “I bet we can describe HotDraw using patterns.” He didn't know quite what I meant, but he has learned to humor me (probably because he's big enough to just bop me if I get out hand). There in a spartan little room in IBM's training facility in up state New York, we tried to recreate HotDraw using only patterns—this pattern tells us to create this object, then this pattern splits it in two, then…

The result was one of those crackling moments when you know you have something. Early the next morning, I described HotDraw to Desmond D'Souza, first using CRC cards the way I always had, then using the patterns. He confirmed that the pattern description communicated the “why” of the design much more clearly.

Ralph and I were confident enough of our findings that we wrote up the paper with a sweeping conclusion—any object architecture can be derived by applying a set of patterns.

You can't write a review without breaking some eggs. That was my conclusion after writing this article. I pretty much trashed the Enfin product as it stood, backed by my review research and a nasty experience at a potentially big client.

I was worried what my friends at Enfin would say after this came out. I was pleasantly surprised to find them supportive— “We know we have these problems. Let us show you how we are addressing them.”

I learned that readers appreciate it when you speak your mind plainly, but you'd better have some numbers to back up your opinions.

This was about where I started losing interest in writing the column. I had written this nice bit of code for a client, and I ran into a publishing deadline, so I turned it into a literate program and sent it off.

You'll notice that there are eight more columns after this one. Once again, my reluctance to change shows through. My lesson: once you decide not to do something, do not pass go, do not collect $200 (yep, that's the going rate). Quit and get on with something else.

In my case, I was distracted by trying to keep my business going (which in itself was too big a job for one person) and trying to get my patterns book done.

Not that this is a terrible column, or that it gives bad advice. The technique is useful, and belongs in every wizard's black bag. When I don't feel like writing the column, though, I shouldn't write the column.

This column takes a little bit bigger chance. I never worked out the instance variable taxonomy to the degree I did with temps, but I went ahead and published what I had anyway (as a column, it's not in the book), because I thought it was interesting and potentially useful. Looking at it now, I can't see how terribly useful it is. Sigh. Anyway, I was about to quit as columnist, and this and the previous column were just about rock bottom.

There are two notable points to make about this paper. First, it is one of the first times Ward and I published any pattern-related material (we presented some stuff at OOPSLA 87 in Orlando, I in Norm Kerth's “Where Do Objects Come From” workshop, Ward on a panel). Second, it argues that the worst problem of reuse is one of communication, not technology or economics.

The paper started out life as a Tektronix technical report. Ward and I had the habit of writing up just about everything we did as a TR. After we had written this, I think we submitted it as a position paper for some conference or workshop. Somehow, JOOP got hold of a copy and contacted us about publishing it.

The paper can be summed up as: “We created two sets of abstractions. The first was communicated as literate source code. The second was communicated as patterns for its reuse. The first set of objects was misused; the second was used correctly. We conclude that the problem of reuse is one of effectively communicating the intent of the code.”

This column is really just an application of Composed Method to deal with inheritance. Now I always try to make my code fragments be real code, no As, Bs, and Cs. You can see why from the example here that is written the other way.

The column is interesting in that it contains some of the first explicit links between patterns. Down at the end it says, “Use Composed Method if necessary to set this pattern up.” I paid considerably more attention to pattern linking when I wrote the pattern book, and I'll probably pay a lot more attention with my next set of patterns.

Patterns in isolation are all very interesting, but it is when they are linked together that they become powerful. It is only then that you can explain a simple solution to a problem, because you know that the rest of the solution was handled by previous patterns or will be handled by future patterns.

As if one crusade wasn't enough, I had to take on the sacred cow of inheritance as well. This must have been my “caped crusader” phase. I still think inheritance is overrated, but I don't generally get in anyone's face about it anymore. Too many windmills under the bridge, I guess. There I go, sounding old and worn out again.

I like the way the pattern form makes concrete and clear the technique of separating state-related and service-related code. The how of it is clear, as is the why.

This is one of many attempts I have made to explain the pattern I now call Composed Method. I must have written this pattern six or eight times. Persistence (my wife calls it “stubbornness” for some reason) can make up for lack of raw talent.

The two patterns here are written as transformations and named as a transformation—you have a method and you split it apart or you have a class and you split it apart. I was very big on “patterns as transformations” for a while. All the patterns in the pattern book are written differently—as descriptions of the things created, not the process of creating them.

This column is the site of my greatest disaster as a column writer—I promised something I didn't deliver. This was another one of those “write the first half now and the rest later” columns. Unlike the column about applying patterns to design, however, I didn't know the second half of the material when I started. I stil feel bad about this, but I still don't know the material for the second half, so I still can't write it

I really like this column as a piece of pedagogy. It is an excellent example of lie management. I describe garbage collection simply one way, then simply another, then combine the two for a truer picture of garbage collection. And hey, I even included a bunch of pictures.