In our last Episode, Linguist Coder and Prototype Analyst kidnapped The UML Guy and demanded he explain arrows in UML. After a rescue by the police, The UML Guy returns to the Lounge. (Click the picture for a larger image.)

This one is for Jennifer Marsman, who is quite possibly the second-most-fanatical UML geek that I know. She's also the creator of Featured Women in Technology, an ongoing series of profiles on women who shine in technology fields. Jennifer does her part to show young women that technology isn't an all-men's club. And boy, is she right! Besides her profiles of Dianne Marsh, Katy Kneale, Janet Galore, Carey Payette, Amity Binkert, and Lidiane Souza, I would add (off the top of my head) Lynne Molenkamp, Dana Coffey, Michelle Leroux Bustamante, Mary Poppendieck, Julie Lerman, Betsy Weber, Sarah Dutkiewicz, Anne Gogh, Gina Loveless, Grace Hopper, Rachel Appel, Janine Moore, Maggie Longshore, Elizabeth Naramore, Lynn Langit, Jennifer Davis, and Kirstin Juhl. Plus many more whom I forget at the moment, but whom I respect as colleagues, and to whom I offer my sincere apologies for my feeble memory. And lest we forget, Jennifer Marsman.

The Lounge is a bit testosterone heavy so far. Partly due to the characters I used as inspirations, partly no doubt from my own experience, the Lounge cast so far has run about 7 males per female. I decided that was out of balance (although honestly, it's a better ratio than most places I've worked); so it was time to add Geek Girl to the cast. Think of her as a spokesperson for all the engineers and designers and evangelists and authors and speakers in the list above. With Crystal Bernard's accent, because Wings happened to be on while I was drawing this Episode. (It's amazing the tricks the mind plays. I could "hear" Geek Girl in my head, clear as a bell, and couldn't place the voice, even as the same voice was speaking in the background.)

Modeling user interfaces in UML is a common problem; and State Diagrams are easily the best answer I've found. They're a great way to show flow that's based on user decisions, not on some algorithm. With Events and Actions, they're a great way to show control events and how your system responds to them within a given form.

And perhaps most important, they're a great way to handle The Cancel Problem. In a modern GUI, it's often the case that a user can cancel at almost any point. Even worse: if you're building a Web app, they can always just close the browser, or even disconnect from the Web. That's not an immediate cancel; but it will be a cancel when the Web session times out. If there's some work that has to be done to clean up when the user cancels, trying to draw control flow with Activity Diagrams, or even with State Diagrams, becomes a nightmare as you try to draw arrows from every possible cancel point to the clean up work. But with a Superstate that contains all of the cancelable Substates, you can easily show that all of these Substates handle cancel in the same way: by performing this clean up work. In today's Episode, for example, no matter where you are in the Booking process when you cancel, you have to go to Releasing, or the suspect will get lost in the system.

User interfaces aren't the only things you can model with State Diagrams, of course. They're a powerful tool for modeling certain kinds of business processes. In particular, if you have a document-centric process, where some document (such as an Order for goods) passes to different departments as different people act on it and different events occur, then you can easily automate that process as a document object that passes through different States in response to some Events, and which does work within a State in response to other Events. This can be a convenient way to model processes built within a Service Oriented Architecture.

Another value of State Diagrams is that a number of tools will turn these directly into executable code. In particular, Windows Workflow Foundation is a powerful tool that lets you graphically design both Sequential Workflows (similar to Activity Diagrams) and State Workflows, and then execute them directly. There's some work involved in hooking them into a user interface, but there's amazing flexibility and power in being able to depict and edit a flow graphically and then change your mind without having to change a lot of code.

In our last Episode, Apathetic Coder and The UML Guy derived code from Sequence Diagrams. Today, the Lounge has a pair of unexpected visitors. (Click picture for a larger image. UPDATE: The larger image is broken somehow. I probably can fix that later tonight.)

This Episode is a hodgepodge of obscure references:

• Star Trek.
• Zatanna the Magician.
• The Ransom of Red Chief.
• Benjamin Franklin.
• Entity Relationship Diagrams (ERDs).
• Data Flow Diagrams (DFDs).
• Episode 8.
• Night Court.
• Columbo.
• Who Framed Roger Rabbit?
• Plus a couple of coworkers with unusual interests: Scott Morris, who specializes in assembling rapid prototypes of systems; and Harry Gilbert, linguist and programmer and musician (among other talents).

If you don't know all of these references, this Episode can be completely baffling.

Kinda like the arrows can be in UML, until you get used to them.

To me, the UML arrows are natural. They're "right". They're what I learned, and they make sense.

But to people skilled in ERDs and DFDs, the arrows are precisely backwards. In those notations, arrows indicate the direction that data moves: in other words, from provider to client. UML's arrows run from client to provider.

For that difference, I can only apologize. The notation is what it is. It took me two years of teaching UML before some student had the guts to raise a hand and ask "Why are the arrows backwards?" Now at least I'm aware of the issue, and (usually) remember to bring it up early so that you can grapple with it.

At the same time, what's the client and what's the provider isn't necessarily cut and dried. In fact, it can be an arbitrary implementation decision. Does a book refer to its chapters, or does a chapter refer to its book? Or both? And if the answer is both, is that one association, or two? In code, it almost has to be two; and in UML, we would model that as two arrows. But if it's a single association, we model that as just a line, not an arrow. That's also a common way to model the association when we haven't yet decided what's the client and what's the provider.

So if the arrows are confusing, I apologize. I'll do my best to make really clear examples.

This Episode is for Harry and Scott, who demanded it. Now, they didn't hold me at gunpoint, but they got really close...

In our last Episode, The UML Guy met Deadline, a project manager with a Grim problem. Today, another member of The Team wanders into the Lounge. (Click the pictures for larger images.)

This one is for @arphahat (who shaved his beard a long time ago). Now can I have my freakin' cookie dough?

And yes, I already referenced this film in Episode 18. It's one of my favorites. Deal with it.

Back in Episode 10, I introduced Sequence Diagrams because I needed to demonstrate them for Ann Arbor Day of .NET. In Episode 16, I contrasted them with Activity Diagrams with Swimlanes and showed some similarities and some differences.

But spurred on by a suggestion from @arphahat (if there's a joke you find funny in this strip, there's a good chance it's his -- I wrote all the unfunny jokes), I decided it was time to show why I think Sequence Diagrams are the UML diagrams that speak most clearly to programmers.

At the end of the day, many programmers just care about code. They love solving problems and using code to do it. And a lot of things that go into a complete development process -- talking to customers, researching rules and regulations, documenting business rules, end user docs -- just don't interest them. And most of the UML I've shown so far has been about those things. Those other things that aren't code. Bo-ring...

But Sequence Diagrams are different. Yes, in some way, they're like the dreaded flow charts that Apathetic Coders hate more than anything; but they're also about Objects and Methods and Classes. In other words, they're about what we have to write in the code! In a way, they're Object-Oriented Flow Charts.

And as I demonstrated a little in this Episode, Sequence Diagrams actually let us think through the code we have to write. We put down an Object, and give it a Class. We ask what it's supposed to do, and we add that to the Class. Then we ask "What does it need to do that work?" Oh, that's another Object, another Class, another Method. Repeat, repeat, repeat. And when we're done, we've defined a bunch of Classes, and defined (or at least implied) a bunch of relations between them. So creating a Class Diagram is practically trivial.

So now all we have to do is wait for the 23rd century and tools that will convert those directly to code.

Tick-tick-tick-tick-tick-tick-tick-tick-tick...

Wait a minute! What are we waiting for? Those tools exist today! In fact, they've been around since the dawn of UML, and are getting better and more powerful every year! In fact, let me demonstrate with Enterprise Architect. I started by converting the Sequence Diagram to this somewhat more elaborate Class Diagram. (I couldn't help myself, really! My geek-ness knows no bounds...)

Then I right-clicked on the Package in the model and selected Generate Source Code:

The Generate Package Source Code window opened, and I selected what I wanted to generate and where I wanted it generated:

I clicked Generate, and the following C# code just beamed in from nowhere (and I apologize to Editor Bill and any other non-coders reading, but I want the Apathetic Coders to see what they're getting at the push of a button):

///////////////////////////////////////////////////////////
//  Photon Torpedo System.cs
//  Implementation of the Class Photon Torpedo System
//  Generated by Enterprise Architect
//  Created on:      07-Nov-2008 10:29:12 AM
//  Original author: Martin L. Shoemaker
///////////////////////////////////////////////////////////

public class PhotonTorpedoSystem : IWeapons {

    public PhotonTorpedoSystem(){

    }

    ~PhotonTorpedoSystem(){

    }

    public virtual void Dispose(){

    }

    ///
    /// <param name="lock"></param>
    public void Aim(SensorLock _lock){

    }

    public void Fire(){

    }

}//end Photon Torpedo System

OK, OK, I won't hurt Editor Bill's brain any further. The remaining files can be found here.

Now this is only one way these files might work. Enterprise Architect has a lot of options for controlling code generation: languages to use, idioms to apply, locations to store files, and more. And other tools can produce code that looks even more different. You have to learn what to expect from your chosen tool.

Many UML tools will also reverse engineer Classes and Class Diagrams from code. The results are usually ugly, because the diagrams are laid out by a machine. Machines have no sense of esthetics. But the elements are there, and you can rearrange them into a more legible diagram.

And some tools can go far further. For example, Visual Studio Team System's next version, code-named Rosario, can do more than generate code or generate Class Diagrams: it can actually reverse engineer Sequence Diagrams from code! I recorded a demo of this using the April Community Tech Preview, and you can find that video here. This is a phenomenally powerful tool for learning and diagnosing legacy code. What Rosario does in an hour, I used to do on new projects in weeks. Once upon a time, there were reasons to doubt the power of good UML tools. Today, I find the better tools to do what I need without any doubt. And tomorrow's tools? Well, you don't have to wait until the 23rd century. Rosario will probably arrive late 2009 or early 2010. I can't wait! And thanks to CTPs, I don't have to! Look for future videos that further explore the power of UML in Rosario (now referred to as Visual Studio Team System 2010).

Now I have some miscellaneous notes on today's Episode...

I'm not gonna explain all the Star Trek jokes in this Episode. Either you get 'em, or you don't. There are just too many to explain.

Back in Episode 16, @dfavre paid me a cryptic comment by responding "Whoa!" I didn't get it, so he explained it was a Bill & Ted "Whoa!" Well, I'm sorry to say that I've never seen Editor Bill's favorite film, so I still didn't get it. So Editor Bill explained: "Bill and Ted 'Whoa!' is good; Joey Lawrence 'Whoa!' is bad." I loved that line, so I stole it.

The hair on the Admiral is a toupee. If you can't tell, blame the artist, not the hair dresser.

Despite the hair jokes and the cadence jokes, William Shatner is one of my heroes. The way he has ups and downs in his career but keeps coming back is inspiring; but then on this album, he reveals a number of real insecurities that show his coming back and coming back is a struggle against the voice in his head that says, "You're not good enough. You never were. You're just a fluke. A has been." Well, a couple of Emmys give him something to say back to those voices. Go ahead and make fun of him, laugh at him. He'll laugh with you, because making fun of him keeps him public. And as Jason Alexander once observed, nobody can do a better Shatner parody than Shatner.

I'm almost the first to coin the term "technobabulator". Live.com finds no hints on it. Google finds two uses on two SF boards. So it's not mine, but it's very likely that you heard it here first.

Speaking of technobabble: I'm not sure that Starfleet ships have to open a pinhole in the shields in order to fire out. I probably got that from Niven and Pournelle. But it makes sense, and it made for a more interesting example.

Editor Bill commented that there seemed to be a flaw here: we jumped straight into Sequence Diagrams and Class Diagrams and code without any Use Cases! First, let me say how proud that makes me. Editor Bill is a good friend who's not a developer; but I keep telling him that he speaks Developer and End User like few people I know can do. If I had a budget, I would put him in charge of a project post-haste, and make him responsible for representing the end user's view to the developers. To have him now speaking UML and thinking how to apply UML makes me feel like: I win!

But he also already had my answer: UML isn't a process, it's a language. You can use it in the context of any conversation about the system, at any stage of a process, no matter what the process is or even if you have no process but code like mad! This Episode isn't an example of a healthy development process; but sadly, it is an example of situations some developer ends up in every single day.

I've told this story before, in a lot of forms and a lot of venues. Since this is a comic strip (sorta), I'll keep it brief and stick to the high points. Early in my UML career, when I didn't even really grasp the scope and potential of UML, I inherited a legacy product, a mountain of bugs, and an anxious manager. They needed bugs fixed, and they needed them now. I was the only one left in the company who knew this technology, so it was me or nobody. Now they knew intellectually that nobody was going to step in and fix bugs in 8 years of legacy code overnight; but even though I promised nothing, they still hoped that I had some miracle in my back pocket.

I did have a miracle in my back pocket. I just didn't know it yet. I had UML.

I agreed to try for a miracle, if they would agree to let me try something radical. At the time, we were experimenting with UML and Rational ROSE, one of the earliest and most powerful of all UML power tools (and still a fine UML tool). I was spearheading that effort at the company. I wasn't 100% sure why I was so interested in UML (though I have recently come up with an answer); but I was interested at the same time the managers were, so they let me learn on the projects. (Thank you, Phil and Steve!) I said I could try taking ROSE home and reverse engineering a "map" of the code. From that, I would try to learn and understand where the new bugs were. But they had to give me time to learn before I could fix.

And so they agreed; and so I did. I started by reverse engineering the Classes and Class Diagrams. With the tools of the time, that took me days. Then, though I didn't know the code, I knew the technology. I could find user input points. Comparing those to screen shots and the help docs, I derived Use Cases and Use Case Diagrams. Working at my best possible speed at the time, that took me days more.

I wish today I could remember why I did what I did next. If someone suggested it, I want to thank him, because it was right. I took those Use Cases, and I took the code, and I manually reverse engineered Sequence Diagrams to describe what happened when the user pushed a particular button. That took me days and days and days; but when I was done, I had learned what that code did in ways I couldn't have known without making something from the information.

And when they asked, "How long will it take to add this data to this report?" I was able to ask, "Where does that information come from? OK, that's this signal. That causes this Use Case, which is detailed in this Sequence Diagram. OK, where does it come in? There? OK, so I can add it to this object, and this call, and this database table." And then I asked, "When does this report happen? OK, when they push this button on this screen, I see it. And that runs through this controller, and pulls this data... There, there's where I need to read the new column. Then I can pass that in with this call, and this one, and... OK, here's the report Class. I need to add one column here, and put this field into there. OK, I can do this in about two weeks, because I don't do SQL. If you can lend me a DB guy, we should have it in under one."

Think about it. This code was 4,000 source files that had been under development for eight years, all written by one developer. And that one developer wasn't me! Yet in under 30 days, I was able to understand, explain, maintain, and extend the code. All because UML helped me to converse: first with the code, then with myself, then with the managers, then with the DB guy. I was by no means an expert on that code yet; but I was familiar, and comfortable, and confident, and competent. I didn't truly appreciate it at that time, but that was my miracle.

And today, with a decade's improvement in tools, and a decade's improvement in my skills, that would be hours instead of days. With upcoming tools like Rosario, some of that will be minutes instead of hours. The future's so bright, I gotta wear shades.

And finally, an unexpected conclusion...

I learned something in drawing today's Episode. Well, I may have known all along, somewhere in the back of my head; but when I drew this Episode, it all came together with a click! Although @arphahat inspired today's episode and served (pre-shaving) as the model for Apathetic Coder, the truth is that thanks to the vagaries of Spacetime distortions (where's @coreyhaines when you need him?), Apathetic Coder is The UML Guy, just a younger version. When this film was in the theaters, I just couldn't see the point to any sort of design drawing (we called it flowcharting back then). I was busy. I had code to write. All this picture-drawing was getting in my way. I would never have admitted it, but I was Apathetic Coder (without the beard).

So although I have a policy never to explicitly state my ulterior motive in drawing the Lounge, I can say this much: when I'm talking to you in this strip, I'm talking to Me. I'm talking to the Me who worked long hours and days and weeks and months on poorly defined projects that didn't have to be that way. I'm talking to the Me who loved writing code but hated failing and hated whatever seemed to make failures more common than successes. I'm talking to the Me who didn't listen to friends who were struggling with some of the same ideas but a little ahead of me in seeing the potential. I'm talking to the Me who thought it was all about code, and didn't see that it's all about communication. I'm talking to all the Mes stuck in warehouses and offices and who knows where at 3 a.m. with an 8 a.m. deadline, trying to understand how they got there. And I'm talking to all the Me's out there who might be smarter and quicker than I was, if only somebody can show them a reason to pay attention.

It was a long, strange trip indeed from Apathetic Coder to The UML Guy. Come, walk with me. I want to show you a shortcut.

In our last Episode, Evil Tester used his newly gained UML skills plus his testing expertise to generate mountains of good news for The Reader. The Lounge is attracting attention from unexpected quarters, including today's new cast member... (Click the pictures for larger images.)

Why yes, I am reading Steve McConnell's Software Estimation right now. You should be, too. While he has earlier argued that requirements errors are the most common factor in project failures, here he shows that systemic underestimation is also a pretty significant factor (complicated, of course, by requirements problems). He shows you techniques that can improve your estimates to a 25% error range (with practice); but he also discusses what an estimate means, what it doesn't mean, how to revise it, and how to effectively communicate estimates and attendant risks to stakeholders.

And one of the fundamental techniques he describes is refining the problem down to a large number of smaller elements. Those smaller elements can then be counted or calculated or judged to produce a number of small estimates. And a fundamental truth of estimating is that many smaller estimates have less error than a few large estimates do.

And where can you find the smaller elements to estimate? Well, if you don't know my answer, you need to reread today's Episode... Long before I ever read McConnell's book, my estimating practice was good for about a 30% to 40% error range (when I followed it rigorously -- not following it is always a risk). And that practice is simple: don't estimate until I have at least a rich Use-Case-level model, and preferably a detailed Swimlane-level model; then build the estimate from the models I have.

Now when I do that, the estimate that results is usually one the customers don't like. They have a Target, and they want the Target to be the Estimate. But that's a contributing factor to the systemic problem that McConnell describes:

The industry data shows clearly that the software industry has an underestimation problem. Before we can make our estimates more accurate, we need to start making the estimates bigger.

Yeah, bigger estimates... That's gonna make stakeholders happy! Not! But they're already unhappy with inaccurate estimates. Much of McConnell's book is about better estimating techniques, but it's also about educating stakeholders on the use and value of accurate estimates. It also discusses ways to present and justify your estimates, and to use them as a basis for negotiating a feature set and a schedule that satisfies your target. By no means do I want to imply that this is easy; but I find that with a good model, I can lay out a case: "These are the things I'll have to build. This is how long I expect each one to take. And this is what those add up to. Is there any reason to believe that we can do any of these faster? Can we do any of these in a simpler, faster fashion? Are there any of these that you don't need for this release?"

And no, that conversation won't be pleasant; but it's necessary. Unpleasant up front is better than unpleasant in the end. Committing to do the impossible damages everyone: the team, the company, the customer, everyone. The customer will plan other parts of the business around a schedule that's never gonna happen. That ties up resources and funds and people that might be better used elsewhere.

Is there a risk in that conversation? Maybe; but if there is, you need to find a new job. If reality is taboo at your company, it's not a question of if you're going to fail, it's only a question of when. But before you abandon ship, try McConnell's suggestions. It may be very possible to work out a win, if you approach the discussion carefully.

OK, now that I'm done shilling for McConnell... (Not really. It's not shilling, it's enthusiasm.) Let's discuss some details of this Episode.

This Episode is loosely inspired by this film, but owes much more to this book. The Hitchhiker's Guide joke was irresistible.

I loved the idea that even Grim is afraid of the consequences of a HIPPA violation! If you're in health care software and you're not afraid of HIPPA, you're either very brave, or very foolish. They take privacy violations seriously, so your software had better do the same.

The Use Case Diagram in panel 6 introduces some new notation; or at least, new for what we've seen of Use Cases:

• The triangle-headed generalization between Use Cases. You may recall from Episode 7 that the generalization arrow runs from the specific to the general. In Classes, the specific Class (a.k.a. the Child Class or the Subclass) added information or new behavior to the general Class (a.k.a. the Base Class or the Superclass). With Use Cases, a base Use Case defines a set of common rules and scenarios, and then a specific Use Case adds details or more scenarios. In this example, Reschedule is probably faster and easier than Schedule, since much of the information is already gathered. Maybe we can skip all the gathering steps and go straight to forecasting. On the other hand, Redo Missed is probably more complex, because we have to determine and set up an appropriate punishment.
• The dependence (i.e., dashed arrow) from Visit Appt. to Redo Missed, tagged with the <<call>> stereotype. This indicates that somewhere during the course of Visit Appt., we may have to also perform Redo Missed. Let me emphasize that again: may. A given Use Case can contain multiple scenarios, and the included Use Case may be part of one scenario or all. The only way to be more specific is to drill in to the Activity Diagram inside the Use Case.

It's easy to go overboard with Use Case generalization and included Use Cases. Resist that urge! That can overcomplicate your Use Case Diagrams to the point where no one can read them and they lose their value. In particular, if your Use Case Diagram starts to look like a flowchart, you should be drawing an Activity Diagram. Use generalization and includes when they clarify and answer questions, not just because you can.

Model-View-Controller and data access layers are just a start to good architectural patterns. The Gang of Four and Martin Fowler have a lot more to say on this subject.

Please don't take the estimates in this Episode too literally. I did my best to make them plausible; but real estimates deserve more thought than I put into these. They're not a project plan; they're just a demonstration of the principle that:

Early estimates tend to expand with detail.

And yet they don’t expand indefinitely! It’s the early estimates that are most sensitive to detail. Notice how from panel to panel 9, we jumped from 5-13 weeks up to 15-31 weeks, or around a factor of 2.5-3. Yet from panel 9 to panel 11, we jumped only to 14-36 weeks. That’s a factor of around 1.2, or maybe even a decrease. This reflects the Cone of Uncertainty described by McConnell. As the development cycle proceeds through phases of maturity, the uncertainty goes down, and the estimates go down with it. I usually find that waiting beyond Swimlanes to do my estimates doesn’t add much accuracy, especially considering that it takes a lot longer. McConnell argues that the optimum time to make a “Commitment” estimate is after the user interface is sketched out and approved. He’s probably right, because the UI is the most tangible information the customer can see to provide feedback. But that takes a lot more time, and customers are impatient. I can take requirements all the way from idea to Swimlanes in relatively short order, so that’s where I prefer to estimate.

Note also that the summing technique I used here (sum the lows for the total low, sum the highs for the total high) is naive. I kept things simple to stay within the bounds of a comic strip. McConnell has much more sophisticated techniques to suggest, yet techniques that aren't that much harder to apply.

Oh, and did I mention that you should read Steve McConnell's Software Estimation? You should!

In response to Episode 16, Mitch asked yet another thought-provoking set of questions:

Another reason for swim lanes: I've seen them before. It was very enlightening to see the similarity between the new concept of Sequence Diagrams with a familiar friend.

Here is a nagging concern: whether you approach your model from the top-down or the bottom-up, if your premises are flawed, how will you know that your nice neat diagrams have errors? It's one thing to note omissions, like the outstanding payables. It's quite another to detect "hangs" (A depends on B depends on A) and illogical constructs, like mistakenly switching the swim lanes for the analyst and the saboteur :).

Is there a "middle out" approach to UML? I recently read a thought-provoking article about how to write technical manuals. The author explained a middle-out approach that works - for manuals.

Cheers,

Mitch

Belatedly, I'd like to respond. To address the first question first, this is the benefit of working with a team. Trust your team members to see what you miss, and they’ll trust you to do the same. I used to espouse a fundamental dilemma of design:

Good design comes from individuals; sound design comes from committees.

And then, building on this dilemma, I advocated for a “most likely” path to successful design: design in isolation, because that’s the best way to get a single, unified vision with great clarity; and then review with a committee to have them point out oversights and places where you thought the design communicated, but it really didn’t.

Boy, was I an officious prig! More and more as I work with clients and teams, I’ve reached this conclusion:

Good design comes from good teams; sound design comes from good teams.

I still see benefit from the “design alone, approve together” approach. You really do benefit from people with different blind spots pointing out your blind spots.

But I see more benefit when a good team can create the design together. Note the difference here between “committee” and “team”. Heinlein said, “A committee is a life form with six or more legs and no brain.” Well, a team has the brains of every team member, actively involved or else not showing up. Jim McCarthy describes the essence of team-ness and team building in two books. He describes a lot of techniques, while by no means promising that team-building will be easy; but two of the fundamental techniques he describes are easy: Check In and Check Out. His point is that if you’re not honestly, actively participating in the current team activity, then your responsibility to the team and to yourself is to Check Out of that activity, and Check In when you can commit to it again. Someone who’s in a design meeting solely because the boss said to be there won’t contribute to the design, and will inevitably add a sense of lethargy to the discussion. Someone who’s there because he or she is curious and interested and actively participating will lead to a better design.

I’m sure I’m making team-oriented design sound too easy. I can only say that in my recent experience, it can be easy. The more I trust the team – including the customers – to communicate their ideas and sanity-check mine, the more I find that trust justified and reciprocated. It didn’t start easy. Like many of us, I had an instinctive distrust of committee efforts. Heck, “design by committee” is a cliché for “poorly and overly designed”. And I still experience that in some design “teams” that are really design committees. But I find that extending trust and giving a committee a chance to be a team pays off more often than the cynics expect.

There are three techniques that I find make a big difference in the effectiveness of my team design efforts:

1. Trust. As above, and as DeMarco notes: the surest way to be trusted is to trust. It seems to be something in human nature.
2. Listen. Really listen, especially to any customers in the discussion. Hear before you speak. When I work with a new customer, I routinely spend the first hour of our time together just listening. I might take notes, but probably not: I want them to know they have my full attention. And then, after I’ve heard their concerns, I start drawing diagrams of what they said, or finding existing diagrams that reflect their concerns and updating those based on their new information.
3. Be their UML tool. This is easy for me to say, hard for you to do until you yourself master a good tool; but I find it’s incredibly effective. Almost anyone on the team can read the diagrams and suggest changes; but if they have to struggle with a tool to put their ideas out there, they get frustrated and stop communicating. I want nothing in the way of that communication. This is a really good argument for team design sessions to use a whiteboard as their design tool: everyone knows how to use a whiteboard! But I find I can get almost the same ease of use plus all the benefits of a good tool-built design if I let them talk while I draw with my diagrams on a screen where they can comment. Soon they’re telling me what I’ve drawn wrong, without me having to teach them UML. Sometimes they’ll ask me notation questions, and I’ll answer to make sure they’re not confused; but I consciously “tone down” the notation, avoiding the obscure and the complex for the simple and the comprehensible.

Of course, none of this helps if you’re a lone developer. In that case, I can only recommend the Beatles Strategy: get by with a little help from your friends. Find fellow developers who are similarly in need of design feedback, and take turns reviewing each others’ work. Of course, there can be confidentiality issues here (no plan is perfect!), but “buddy reviews” can be a great way to find and patch design holes.

As for the question, “Is there a ‘middle out’ approach to UML?”: Nineteenth century German Field Marshall Helmuth Graf von Moltke told us: “No battle plan ever survives contact with the enemy.” Top-down, bottom-up, even middle-out: these are all battle plans for how we think we’re going to attack the analysis and design problem. And as von Moltke taught, blindly following your plan after it’s proven wrong is a plan for defeat. In the case of designing, especially when designing with customers, saying “We can’t discuss that now, that’s not on our plan” is akin to saying “That’s not important”; and they may even hear “You’re not important.”

So my real plan, regardless of top-down or bottom-up, is “If they say it, I draw it, and then I clean it up after we break.” I want to respect all the knowledge they share as they share it. One advantage of a good UML tool is it’s really easy to find a place or at least a parking place for any information you discover, whenever you discover it. I go in with a roughly top-down plan; but I adapt the plan to the people, not the people to the plan.

Thanks as always for great questions, Mitch!