We Don’t Use UML in XP
One thing that has been bothering me a little as of late is the misguided dislike of UML I have observed amongst some XP users. As an example, at work the other day I was reading through Object Design: Roles, Responsibilities, and Collaborations (an excellent book by the way), one of my co-workers (who just started) asked me about it, and noticed the page I was on showed a nice sequence diagram and commented he likes interaction diagrams, but they assume that you have the rest of the system fleshed out in UML.
Of course, I noted that’s not really the case, yet when another co-worker joined our discussion, he glanced at it and instantly focused on the “UML sequence diagram” portion under the illustration and instantly replied “Oh, that uses UML. UML is generally frowned upon in XP”.
And how wrong that is! When I’m trying to convey the sequence of events in a system to someone, I find it very helpful to draw out a sequence diagram that illustrates what’s going on. And for this I don’t need the system fleshed out in a class diagram, I don’t even really need to use class names … simply referring to roles in the system can be adequate. One can convey the same information on a whiteboard without using UML, I just find it convenient to use UML because it provides a common vocabulary. Likewise, I might use a class diagram to quickly sketch out the hierarchy of a system, but omitting unimportant details (and usually a throw away sketch or whiteboard drawing).
But, back to the question… why the hatred against UML by some agile developers? I think the reason behind this is that UML is occasionally associated BDUF (Big Design Up Front), a big no no in XP. BDUF implies that you do EVERYTHING (class diagrams, sequence diagrams, entity relationships, documentation, etc) up front before writing a single line of code, and then even worse generate your code from the model you designed. The reason this is bad is because it’s a lot less agile … it almost locks out changes in requirements and when requirements do change (as they are destined to do) they become more expensive to implement. I would guess those that have experienced BDUF would have quite an aversion to it because of the results it tends to yield. 
Of course, what it all boils down to is how to best communicate your ideas to others. While clear cut sequence and entity diagrams are in my opinion the best way quickly flesh something out, a majority of the time quickly scribbled words, boxes, arrows, and stick figures (which exist in UML anyway, hehehe) with someone telling a story describing what is going on can be good enough. Which is what really matters … that which is good enough to convey information correctly in a format that others can easily understand while keeping the nasty technical details to a minimum.
If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
June 11th, 2006 at 11:32 am
James, I also have the impression that XP-ers don’t do UML. But I think it’s worse than just not having diagrams for communication. It is my hunch that most XP-ers do not do design above the class level at all. Bob Martin writing about REP and ADP doesn’t make it happen. I’d like to see the XP practices include Review Emergent Package Design with every iteration with the view to at least removing package cycles.
Please tell me if I’m wrong on this impression!
June 11th, 2006 at 12:28 pm
Chris,
Well, at work we use XP and a lot does fall on the team and the actions that the team takes when it comes to design. Although design happens during coding (and may keep design limited and focused on the “task at hand”), a lot of times we’ll reach a point where we decide some refactoring needs to be done to clean the design up.
I googled “Review Emergent Package Design” and couldn’t find any results … could you point me to a definition of it somewhere? It sounds rather interesting as my team currently does quick reviews of where our code has evolved to and, with the larger overview of the system dynamics, can choose proper refactorings based on this.
June 12th, 2006 at 5:53 am
I kind of just invented the term, but I agree that it’s a good one ;-). We’ve been doing this for a couple of years now and I strongly believe that it is important enough to be included as an explicit principle in XP/Agile processes. Out of interest, how do you discover your emergent design at the higher (e.g. package) levels in order to perform the quick reviews?
June 12th, 2006 at 8:35 am
For us it happens while practicing constant refactoring during our iterations. For example, a major component of our new system is a business rule processor. When I came on board, there were only a handful of business rules that were in a pacage called, simply, “businessrules”.
Since then, our businessrules package has split up several times as our number of business rules grew and we could identify rules as belonging to a particular family of rules with certain traits. Liewise, new objects arose over time that took responsibility and roles that had naturally been spread out early on, but as those roles became more common required new objects to play those roles.
June 12th, 2006 at 11:46 pm
Good post - when I first came on board one of the first things I did was sketch out a sequence diagram of the system we were working on. My pair was confused, because he thought we weren’t supposed to use them.
I told him that the trick is just not to keep it around - and we didn’t.
June 23rd, 2006 at 1:59 am
Interesting - I’ve worked two jobs post-college, 1 where I was required to produce detailed UML before writing code, and one where half of the developers didn’t know UML. At work, I find UML being used frequently, not to PLAN a system, but to DESCRIBE it. I find it dangerous to do a UML until after you have written code, but creating UML as a way to document a system for your customers and teammates can be useful. It’s not embraced by all agile developers, but it should be - A picture (especially on a whiteboard) is worth a thousand words.
June 23rd, 2006 at 9:50 pm
Indeed … I think that’s always the biggest issue … to keep from doing too much up front design.
By the way, I noticed you put a url down for your name that has a placeholder page in place … you setting up a blog soon too?