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.

This is a bit of work I am particularly proud of. I wrote a little workspace that got me a method list browser on all the methods in the image that use “super” (that in itself was fun). Then I went through them trying to categorize each one. I felt like a real scientist there for a minute- taking samples, making hypotheses, testing them in the “real world.” The result is a “theory of super,” which is much simpler than the language feature (and perhaps not coincidentally quite similar to the “inner” feature of Simula, from which super was derived).

This is the biggie, the paper that made my name (and to a lesser extent Ward's, since he was already a little famous). I got my name first on the paper because of our rule that whoever wrote the first draft of a paper got to put his name first. This has caused considered confusion since then, with people crediting me as the inventor of CRC, or telling Ward how exciting it must have been for him to work with me.

There are a couple of stories about this paper. First, the title. Ward and I wanted to be very careful not to claim more for CRC than we could prove. We knew it was good for teaching “object-think,” so that's the approach we took in the paper, the one single point we pushed. We deliberately understated what we thought the impact would be, leaving it to our readers to extrapolate to making CRC cards into a design or analysis technique. We spent at least an hour on the phone polishing the title, and the result pleases me as much now as it did then.

Another story- I missed OOPSLA '89, waiting for the arrival of Lincoln Curtis, child number two. I had no idea of the impact of this paper. Then I attended OOPSLA '90 in Ottawa. I was in a “Design and Analysis” BOF. The biggies were all there: Booch, Constantine, Yourdon.

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.”

If you have read The Smalltalk Best Practice Patterns, you can see in this column the beginnings of the section in the book on collections. Once again, I mined the material from the image. Thinking back, I'm amazed at how important reading the image has been to me. I can remember being incredibly frustrated at having to spend all day looking for the method or class that I wanted, but then realizing at the end of the day that I had gotten more accomplished with six hours of reading and ten minutes of typing than I used to accomplish with ten hours of typing.

We may underestimate the value of a shared body of literature (the image) in creating and sustaining the Smalltalk culture. Perhaps that's why the visual “wire-and-fire” front-ends failed to have much impact-there was no corpus of visual code that everyone routinely consulted.

Object-oriented concepts, including a few that we missed in The Object Primer.

Modeling techniques like class responsibility collaborator (CRC) modeling, use-case scenario testing, and class diagramming.

An iterative development life cycle called “The Pinball System Development Life Cycle (SDLC).”

What this book is all about.

Unless you're reading The Object Primer and Building Object Applications That Work back to back you're going to need a quick refresher. Furthermore, there's some new material in this chapter starting in section 1.3 (hey, like we'd want you to skip an entire chapter).

Until the release of this book, The Object Primer was the greatest thing since time-sliced bread. Now we have Building Object Applications, a book that is even more spectacular than its predecessor. In The Object Primer we covered analysis techniques such as class responsibility collaborator (CRC) modeling and use-case scenario testing. We also introduced several object-oriented (OO) concepts and showed you how to model them using class diagrams. We finally put all this into the context of the Pinbail System Development Life cycle (SDLC), an iterative and incremental approach to OO systems development.

I wrote this paper in one sitting in my favorite coffee shop in Boulder Creek, perched out over the creek sipping a mocha (several mochas, in fact). I was trying to come up with a catchy intro. When the time machine idea came to me, the rest of the article wrote itself.

I don't know whether it will reproduce in the book, but in the magazine, the words “Star Trek” in the fourth paragraph were done in the Star Trek font. I was impressed that someone had the time and ingenuity to put in that little touch.

The other lesson in this is that the coffee shop in question closed soon after. The building owner wanted to jack the rent way up once the shop was successful, and the shopkeeper closed down rather than pay. The shop had become a gathering place for the community. Our little town still hasn't recovered

What I take from this is that even though as a businessman I have to pay attention to the bottom line, every decision I make also affects real people's lives. Once you're committed, not following through may have a huge cost for other people.