Nerdy tidbits from my life as a software engineer

Wednesday, April 29, 2009

The Value of UML

I appear to be a dying breed.  I am one of the few people who really seems to value strong use of UML.  And it perplexes me to death why nobody else cares about drawing things out before they code.

Complex software systems are hard to understand, but they become a thousand percent easier when you can see class relationships with your own two eyes.  Suddenly, a design either make sense or it doesn’t at all.  In either case, visualizing a system in graphical form makes it easy to spot the pros and cons of your design and understand where to make changes.  Without UML, you’re just looking at a lot of loosely connected text files.

And yet, nobody seems to care about drawing things out.  Any argument that up-front design takes more time than none at all is short-sighted as any experienced engineer will tell you.  It will take you longer to skip design altogether because your lack of foresight will cause delays later on.  You know how people tell you to think before you speak?  Well, I say, think before you code.

My suspicion is that the agile movement has somehow convinced everybody that it’s OK to skip drawing UML.  Maybe all those old, out of date UML diagrams sitting on your backup server have convinced you not to bother with it at all.  But when you are starting a brand new project, UML helps you visualize a class hierarchy of your systems foundation before you even start writing it.  So while there may not be much value in staring at an old UML diagram that hasn’t been updated in 3 years, there is a lot of value in staring at a UML diagram for a new system that doesn’t exist yet.  And for new systems, it’s just so critical to get the foundation right.  A system’s effectiveness will stem directly from the basic architecture on which it was founded.  Screw that up, and your software will be screwy.

So here’s where UML fits into my agile process.  During the design phase of my sprint, I spend 2-3 days drawing UML on a whiteboard.  I don’t get it perfect.  I don’t get every property and every method and every parameter right – but I get the basic classes and relationships down.  And this process forces me to think about how everything is going to fit together so that they meet my requirements.  Because it’s on a whiteboard, I can refactor with the stroke of an eraser.  Class names and relationships change every few seconds.  I can visually see the problems with my design, and I can visually find a way to fix it.  Then, once I’m done, I take a picture, save it, and start coding (using TDD of course).

What happens to the picture?  I can hold onto it or not.  Nobody knows how accurate it will be in a few years.  But my opinion is that if the design was right in the first place, it won’t be necessary for people to have an up-to-date picture there all the time.  And if people need to modify the design, it will likely be more useful to redraw the UML as things exist at the time they are being redesigned.  The relationships will be more complex in the future than they are now, which means the UML I draw today will be so out of date for tomorrows redesigns that there’s little point in holding onto it for a long time.

But the point is: UML is still an important part of the process, and it should not be skipped.  You can have UML in an agile process, and in fact, I think they go very well together.


Yanic said...

You're definitely not the only one.

Perhaps the people who are successfully using UML simply aren't as vocal as those that oppose it?

There is nothing inherently wrong with documenting a design (of new or existing systems).

I think few people will argue that a well-chosen class or sequence diagram is worthless. They will however (and rightly so) complain about the cost to create it and its limited lifespan in an evolving system.

So it's all a matter of cost vs. benefit. If you find that the cost is too high or the lifespan too short, perhaps it is time to look for better tool support.

I had the same problem with sequence diagrams, but I think I've finally found a solution that significantly lowers their cost AND has a good chance of preserving the investment.