Geeks With Blogs
Ulterior Motive Lounge UML Comics and more from Martin L. Shoemaker (The UML Guy),
Offering UML Instruction and Consulting for your projects and teams.

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!

Posted on Saturday, November 15, 2008 5:07 PM Ulterior Motive Lounge | Back to top


Comments on this post: Ulterior Motive Louge Q&A #3: In & Out

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Martin L. Shoemaker | Powered by: GeeksWithBlogs.net