"Do you know UML?" I used to say these words often when I started to work with new teams. Nowadays, I just just start drawing boxes and lines. I find I that I can explain as I draw and people grok it pretty fast. "So, you're saying that a Flippet has many Finkles?" I draw the little asterisk to indicate "many" when I say this.
There isn't much to UML. It's just boxes and lines.
A long time ago, people did try to turn UML into a big thing. Maybe they succeeded. No! Don't go off and do a search for "UML" now. You're better off not knowing what they did. It's just boxes and lines that we use to explain ideas. And, you know, you are the boss. You can use ampersands instead of asterisks when you use UML in your team, and you can even call it UML. No one is going to sue you.
The thing is.. boxes and lines got a bad rap a long time ago. They were generally seen as a way of avoiding "real work." And, there's a lot of truth to that perception.
In the past, people did spend ungodly amounts of times getting all of their boxes and lines in the row before writing code. I worked on a team like that once. Those were trying times. But, drawing boxes and lines before you write code is only one way of using UML. The niftier thing you can do is draw them after you've written code. "Why?" you might say. Well, because it's good to get a picture of what you have that's bigger than the class in front of you.
It's nice to think that we "kind of know" what's connected to what in applications we work in day to day, but you'd be surprised. Actually, let me put that another way - you will be surprised if you take the time to sketch out the design of your existing code.
Sketch. Forget about UML generating tools. They are a pain.
Oh, and there's a lot we can say about critiquing a design once we have a nice sketched UML view of it. But, here's a good short rule of thumb:
Boxes good. Lines not so much.
When you have too many lines connecting things crazily, your code is in trouble.
Isn't it funny that when we look at a project the things that turn into boxes are more visible than the things that turn into lines. Maybe that's part of why it happens.
About a year ago I thought I should really learn UML - I'd read a lot of older-school software engineering books and it seemed to be what everyone was using. I never got around to it in the end.
Do you think there's any point these days for a new developer to actively learn UML?
Posted by: Skilldrick | June 03, 2011 at 07:30 AM
@skilldrick That's the most troubling thing about UML - people tried to make a gargantuan project out of it - mostly to sell CASE tools. The core of what you need to know is pretty damned small. Martin Fowler's _UML Distilled_ gives that plus a bit.
Posted by: Michael Feathers | June 03, 2011 at 07:42 AM
These days, I just draw diagrams (yes, "boxes and lines"). Sometimes they are UML, more often they're SDL, and more often still they're just "boxes and lines", following no particular convention or methodology. All that matters (IMO) is that they aid the understanding of your reader(s). [And if they don't, shoot yourself. Twice.]
Posted by: Pattern-chaser | June 03, 2011 at 07:45 AM
P.S. "In the past, people did spend ungodly amounts of times getting all of their boxes and lines in the row before writing code." I know what you're getting at, but feel obliged to observe that a reasonably neat diagram is MUCH easier to read and understand than one whose layout is more, er, chaotic. :-)
Posted by: Pattern-chaser | June 03, 2011 at 07:47 AM
@Pattern-chaser Yes, the notation doesn't much matter as long as people understand. The thing is UML, is pretty decent for the what I want to explain often, and even if what I use isn't strictly UML I don't mind calling it that.
BTW, when I said "all their boxes and lines in a row" I wasn't talking about formatting as much as the urge to make sure that every detail had been explored in a diagram before writing code.
Posted by: Michael Feathers | June 03, 2011 at 07:52 AM
You should really, really read Cherubini et al's "Let's Go to the Whiteboard" (http://research.microsoft.com/apps/pubs/default.aspx?id=74243), about what developers actually draw (and why) when they're explaining things to each other.
Posted by: Greg wilson | June 03, 2011 at 08:11 AM
@gregwilson I'll take a look at it. The abstract, though, makes me think of how often I see people just snap pics of whiteboards with their phone these days.
Posted by: Michael Feathers | June 03, 2011 at 08:29 AM
UML is a great tool for visualizing a problem. It gives you something to do with your hands while you think and something to point to if you're fortunate enough to have a collaborating team mate.
It works best on a whiteboard and you should never get caught up in the minutia of the "the" UML. But it's worth learning enough to be conversant in it. Wikipedia actually has all you ever really need on the subject (and probably more). I find Class, Sequence and Use Case to be my go to models.
Posted by: Bob | June 03, 2011 at 09:50 AM
Nice post. I think Agile teams often get the impression that drawing models isn't important, their whiteboards get taken over as task boards and discussion of design goes underground. Sadly lots of Agile meetings seem to focus too heavily on estimating and tracking progress against those estimates rather than help the team get together to workout design issues.
Another way to make it visible to a team how complicated their design is to do a roleplay. Each team member takes the role of an object and you pass a token between each collaborator. I think I first heard about this technique when Scott Crawford demonstrated it at OT2001 (back in the days when UML was still new and exciting). We tried it in our team at Connextra after that conference and it really helped make clear we needed some re-design. We could have drawn some boxes and lines on a whiteboard to create the same effect but somehow this had more impact.
Posted by: Rachel Davies | June 03, 2011 at 01:56 PM
These days aren't spreadsheets the main non-work distraction procrastichnology?
Posted by: 90210 | June 03, 2011 at 04:24 PM
Great post - I especially like how simply you have put it. We have been thinking about this for sometime (diagrams from code). You can see some of what we have been upto here: http://www.architexa.com
Would love to hear thoughts.
Posted by: Vineet Sinha | June 27, 2011 at 03:51 PM
Je vous dis que Jean connaissait très bien Sawimbi, qu'il lui a rendu visite en centre-afrique, c'est quand même pas votre lettre qui va changer quelque chose, Jean est très retissant de reconnaitre certaines de ces amitiés passées et même présentes.
Posted by: Space Clearing | July 05, 2011 at 09:46 PM
I agree Agile tends to dismiss UML as it was associated with Waterfall whereas it wasn't used as a way to communicate. Also UML tools are really ugly to do so with users so I draw themself using ... Powerpoint see sample pictures here http://lepinekong.com/combining-use-cases-diagrams-with-user-stories-technique/
Also people tend to use Class Diagrams first because it ressembles so much java classes, I think Use Cases should be used first since it's the closest to Business Requirements.
Posted by: Agile or Waterfall | July 18, 2011 at 12:23 PM
am known to be very pretentious when it comes to T shirts designs. Few t-shirt designs are in my liking and fewer become part of my wardrobe. Miles to go set the record straight! I just love these guys! Their t-shirts are not only well designed, but have that special touch when it comes to mystery.
Posted by: Dining Room Sets | October 27, 2011 at 05:29 AM
Why not try this method.
And I think it is a good idea.
Posted by: iPhone contacts backup | February 10, 2012 at 12:03 AM