A Brief Moment of Fame

These things change rapidly. But at this moment, a search on Amazon.com for UML across all categories yields this result:


Product Details

Ulterior Motive Lounge: UML, 80s Flicks, and Bunny Slippers by Martin L. Shoemaker (Kindle Edition – Dec 19, 2011) – Kindle eBook

Buy: $9.99

Auto-delivered wirelessly

Books: See all 4,206 items

A search for UML under Books finds this:


Product Details

Ulterior Motive Lounge: UML, 80s Flicks, and Bunny Slippers by Martin L. Shoemaker (Dec 19, 2011) – Kindle eBook


Kindle Edition Auto-delivered wirelessly

And a search for UML in the Kindle store finds this:


Product Details

Ulterior Motive Lounge: UML, 80s Flicks, and Bunny Slippers by Martin L. Shoemaker (Kindle Edition – Dec 19, 2011) – Kindle eBook

Buy: $9.99

Auto-delivered wirelessly

And these are the results in the specific categories where the book is listed:

Amazon Best Sellers Rank: #70,014 Paid in Kindle Store (See Top 100 Paid in Kindle Store)

That will all change tomorrow, surely. But it feels great today!

Ulterior Motive Lounge Episode 7: Pizza Party

In our last episode, The Reader and The UML Guy refactored the simple Pizza Order Class into a more complex but more robust Class Diagram that supports a full range of pizza order options.

(Click picture for a larger image.)

Episode 7

No new references in this strip. Too much material to cover. But we see the return of some old friends.

Inheritance in UML is called “Generalization”: Menu Item is a general Class, and Pizza, Item, Drink, and Side are more specific Classes. But in most common languages, it’s just called “Inheritance”. When I say “Generalization” in my UML classes, people look at me funny. Don’t blame me, I didn’t make up the names.

For a discussion of why type codes are for losers, I recommend (again) Fowler’s Refactoring.


For an introduction to Patterns, I recommend Design Patterns: Elements of Reusable Object-Oriented Software


…and also Head First Design Patterns.

Head First

Fowler’s Party Pattern and a host of other really powerful Patterns are found in one of the most indispensable books on my shelf.

Analysis Patterns

With Design Patterns — as powerful as they are — there’s a trick: you kinda have to know you need a particular Pattern to know whether you need that particular Pattern. They’re low-level design concepts. Analysis Patterns are higher level, and you can usually recognize when you need them simply by looking at the customer’s business problems.

Ulterior Motive Lounge Episode 6: Class Act

In our last episode, The Reader and The UML Guy drove through time and space in The Search for Class Diagrams. Along the way, they held a long discussion on the philosophy of modeling. But The Reader was surprised when they reached their destination: they were back at the Lounge!

(Click picture to see larger image.)

Episode 6

If you haven’t seen the film, parts of this strip will make no sense at all. I like some oddball films. Get used to it…

Oh, and because Editor Bill and Ernie Out in the Barn demanded it, Receptionist got contacts, and a makeover.

Ulterior Motive Lounge Episode 5: To Gumball, and Beyond!

In our last episode, Pestbuster pursued Pest right through the strip, leaving a mess in his wake. The UML Guy told The Reader they would need Class Diagrams to help in the clean-up, and said they wouldn’t find any without a road trip.

(Click the image for a larger view.)

Episode 5

Yeah, I know… A lot of blah, blah, blah, yackity-smackity… But these were things that needed to be discussed. A road trip is always good for a long discussion.

Here’s the key to today’s references…

The car is a 1973 AMC Gremlin X, to be precise. Just in case you had trouble recognizing it.

Neither fencer is left handed.

Actually, this book has one comic. But it clearly needs more.

The premier for this film was the second-biggest event in my life that week. (Somehow that whole wedding/honeymoon business won first place…)

Steve McConnell has written many valuable books; but in my opinion, this is the most important of them all.

Do I really need to explain this reference?

Yes, I’m shameless.

Take your stinking paws off me, you damned dirty ape!

BDUF == Big Design Up Front; a.k.a. The Boogeyman, if you’re on an Agile team.

There was no room for pictures of this great book from Scott Ambler


…or this from Martin Fowler


Both are inspirations for the Lounge.

The car that made the jump in this film was actually an AMC Hornet X (heavily modified). But the Hornet was the basis of the Gremlin, so it’s close enough.

Until you know every word in the English language, you cant speak English, right?

The Three Amigos — Grady Booch, James Rumbaugh, and Ivar Jacobson — wrote the first draft proposals for the UML, as well as some valuable UML books. Jacobson’s point — as captured in this video — is that the “OED” UML is too much notation for most people, and confuses more than it communicates. He recommends that we identify and promulgate an “Essential UML” for most developers to learn, and leave the detailed notations to teams and projects that need them. I agree, and recommend that a good start would be to go back to UML proposal 0.8 — i.e., the work of The Three Amigos.

Sometimes, when I look at my own code, I find myself humming: If I only had a brain…

And the question must be asked: will anyone catch the Dukes of Hazzard reference?

Ulterior Motive Lounge Episode 4: The Real Pestbusters

In our last episode, The Reader and The UML Guy explored how adding collaborating Actors to a Use Case Diagram gives the audience more context and thus better understanding of the requirements. In the process, unfortunately, Pest escaped. Pestbuster has abandoned his diagram to recapture Pest.

(Click for a larger image.)

Episode 4

And now I’d like to address four related questions. Editor Bill asked me why, in Episode 1, I chose to use an obscure in-joke from a mostly forgotten film — and worse, a film that was mostly hated by those who do remember it. (The masses just don’t appreciate its brilliance…) And Bill, a gamer and Foglio fan, also asked for an explanation of growlf, telling me that that reference was pretty obscure, too.

And jbkazoo asked why the porkpie hat was gone in Episode 2, and where was Samuel L. Jackson? (I suspect he was thinking of the wrong Bruce Willis film…)

So after these questions, why did I drop another reference to Bruce Willis’s underappreciated masterpiece? Even more bizarre, why did I drop a reference to an obscure 1976 film that no one outside my family has ever admitted to seeing?

Simple answer: it amuses me.

This strip is hard work for me, but it’s also fun. If it ever stops being fun, then it’ll only be work. Hard, unpaid work. If it gets to be a chore, well, I have plenty of other claims on my time. So inserting obscure jokes and references helps me to keep producing it. Think of me as the Dennis Miller of UML (though not as funny, nor as erudite).

Editor Bill gently suggested that if I let the references get too obscure, I could lose my audience. (Bill must not be a Dennis Miller fan.) And while I appreciate The Reader, each and every one of you (and hope some of you some day will have comments and maybe even questions I can answer), my answer has to be: I don’t care. Many successful bloggers will tell you the advice I first heard from Dean Esmay: if you blog, blog what interests you. Don’t try to change who you are to please an audience, because you’ll lose authenticity, and lose your audience in the process. Blog for yourself; and if you’re passionate about it, you’re more likely to find and hold an audience.

Now these strips are a little different from the usual blog. I have a not-exactly-subtle goal of teaching UML here; and I can’t achieve that goal without The Reader. If I find no one’s reading over time, well, I already know UML. As fun as they can be, the strips don’t teach me much. So I can’t completely ignore the impact of my obscure jokes on the audience. But I gotta be me. As long as it’s me drawing and writing the strip, the obscure jokes will happen. It’s not like I have control over them.

Returning to jbkazoo’s second question: where’s Samuel L. Jackson? Well, I know it’s a shock, but I haven’t seen that film. I can only reference films that amuse me, which means films I know. Roughly speaking, that means 80s films (though two of three films referenced so far are from 1976 and 1991). Without me planning it, exactly, my favorite films have become an integral part of this strip, driving it almost as much as the UML. Since the 80s were a big movie-watching decade for me, that’s where most of the films will come from; and since some of my favorite films are a little off beat, some might say these aren’t just 80s films, they’re bad 80s films.

So I guess if you need a five-word description of this strip, it’s “UML and Bad 80s Films”. And that amuses me.

UPDATE: Unknown to me, it turns out Manny Quinn is an unintentional reference. Disney was there first, as Lynn the Build Queen pointed out. (And don’t worry, Manny’s not hurt. He’ll be back.)

Ulterior Motive Lounge Episode 3: Pestbusters II

In our last episode, The Reader and The UML Guy drew Use Case Diagrams for a number of Actors within Pestbusters (The Reader’s client). In the process, The Reader discovered and a vital Use Case that he had earlier overlooked. Two weeks later, after the team has implemented, tested, and delivered this new Use Case, Supervisor and The Reader meet in the Ulterior Motive Lounge…

Episode 3

For those who are curious what lies in store for Pest, I have an obscure one-word reference/hint: growlf!

Oh, and it’s time for some overdue credit where credit is due. Editing and feedback for Ulterior Motive Lounge is courtesy Bill Emerson and Curtis Gray.

Ulterior Motive Lounge Episode 1: Friday Night in Ulterior Motive Lounge

Beginning a slightly twisted introduction to the Unified Modeling Language… (Click the image for a larger version.)

Episode 1

Inspired by these YouTube videos:

Also an old Warner Brothers cartoon I can’t find right now.

Further inspiration from Scott Adams, Jolly R. Blackburn, and Chris Muir for convincing me that limited art skills are no barrier to telling graphic stories.

Thanks to Bruce Willis for the porkpie hat.


So one time, I showed a friend a Web site for a project I was working on. And he asked an interesting question:

Well, you’re design guy right? Shouldn’t you be writing a design document?

And what I suddenly realized was unclear was that the Web site was a design document. It was just a design document of a very different sort. It was basically a step one design document, serving as a way to put the ideas in a concrete form for discussion. The team kinda knew what the product should do, but not every last detail yet. Some team members were ready to jump in and start coding right away, and just call it Agile Development if we needed to justify the work. Instead we said, “Wait a minute. We have a vision, but no details. If we don’t explore what some of the users will demand from the system, we won’t design the architecture to accommodate them properly. So before we can write a line of code, we need to explore what a range of users need. Then we can design an extensible architecture that should support most of those needs. And then we can jump in and start coding.” So the Web site was, in part, a format for exploring what different sorts of users would want, by telling stories of how they would use the system. And since the system was intended to be marketed to users who could use those same stories as a way to envision using the system themselves, it made sense to document those stories in a marketing-oriented Web site. But marketing-oriented or not, the Web site still served a purpose as a design document.
Now my friend would never be so rigid and unimaginative as to say that the Web site wasn’t a design document; but I have met people who are so wedded to hidebound procedures that they would have argued exactly that, just because it didn’t conform to some formally defined design document template or fit into some formally defined design methodology. And that reminded me of Kipling:

“There are nine and sixty ways of constructing tribal lays,

Design is a heuristic problem, meaning that there are techniques that can lead to a solution, but no single guaranteed and inviolable path to a solution. Quoting from Wikipedia:

In computer science, a heuristic is a technique designed to solve a problem that ignores whether the solution can be proven to be correct, but which usually produces a good solution or solves a simpler problem that contains or intersects with the solution of the more complex problem.

Note the word “usually” in that description. Some heuristics are better than others, but none can be proven to be right, especially not in the general case.
There are many ways to design, because design is really just a means of communicating and refining your ideas. Different people communicate better in different fashions. Some people are more visual, and some or more verbal. Some are more instinctive, and some are more methodical. Some are more detailed, and some have a broader view. And so there’s no one right way to communicate a design to other team members and stakeholders. The only “right” approach is multiple approaches, to ensure that you cover the same material in different ways to gain different perspectives.
As an example, some people love written design docs, and just can’t see any benefit in design diagrams. Others believe in making excruciatingly detailed UML diagrams, and sometimes see those as “complete” designs. Now I’m pretty fanatical about using UML for my designs; but when I teach UML, I always point out that neither text nor pictures is sufficient. You need both. Different people and different teams will emphasize one over the other, but you need both.
That doesn’t mean that there aren’t better ways and worse ways to design. I would never consider a marketing-oriented Web site to be a complete design, just a step in building the design. But when we built that Web site, we were definitely participating in a design effort. Because…

“There are nine and sixty ways of constructing tribal lays,