Design documents vs UML or both?

Question

I've had a hard time sitting in front of UML and getting value out of it because it almost seems like as much work as programming (if you use an expressive language). I find that writing natural language tells me more about a software project than creating complicated diagrams. I'm new to UML though and I wondered from others who know UML well:

1. Is UML worth all the time it takes to learn / do, even for small-medium projects?
2. Can well elaborated design documents, while still higher level, suffice to keep programmers on target to create the right code, even in teams?

Answer 1

1. Not in my opinion. I once did an OO design module as part of an MSc in Computer Science and UML was barely mentioned (although in my opinion it should have been discussed a lot more given its influence).

2. There's more scope to reduce ambiguities in written text than in a UML diagram, most UML daigrams leave a lot of scope for interpretation. That being said I am a very big fan of the use of diagrams in software design documents and a lot of the UML diagrams are extremely succinct: Deployment, State, Class and Activity are my favourites. When I create UML diagrams I try to stick roughly to the conventions but I don't let them get in the way if they can't represent the concept I am trying to communicate.

Answer 2

I would answer:

Nothing, absolutely nothing, replaces the need for good communication between programmers on a programming team, and management.

This means a certain level of breaking down the task into simple "what we need to do" statements for managers and explaining any roadblocks.

I worked on a small project where the entire class structure of the program was designed by someone in UML prior to any code being written. Great, but the designers didn't anticipate the way the classes might be used, or the need to change certain structures to better fit program logic. They simply threw out a design they thought would work.

I'm yet to meet someone who can design a program in their head and produce exactly that when writing it beyond very simple stuff. The process is quite organic and things do need to change along the way as programmers realise their earlier errors and correct them. I can see why feature creep starts to occur and this is where management need to understand what is going on, be kept in the loop and updated. Good managers will listen to what their programmers are telling them and adjust sights accordingly.

So, of your two options I'd go for the high level design document: we want the software to do this, run on this platform, accept this sort of input and spit this sort of thing out. That works, if the above is kept to.

UML, as far as I'm concerned, isn't worth it.

Answer 3

I don't think UML is sufficient on its own.

I've had a hard time sitting in front of UML and getting value out of it because it almost seems like as much work as programming (if you use an expressive language).

I agree with this. UML can provide method signatures, but you don't fill in the meat of the method. Worse, you can't do anything approaching TDD with UML. Given a choice, I'd rather have TDD and functioning code than UML diagrams.

I find that writing natural language tells me more about a software project than creating complicated diagrams.

Spot on. Pictures can be helpful, unless they're bad pictures. Sequence diagrams tend to become impossibly complicated for all but trivial flows.

Is UML worth all the time it takes to learn / do, even for small-medium projects?

Vendors and architects will tell you UML is indispensible, but I don't agree. I fall into the "skecher" camp of UML users.

Can well elaborated design documents, while still higher level, suffice to keep programmers on target to create the right code, even in teams?

I don't know what suffices to keep programmers on target, but I'd guess that UML isn't a big part of it. Architects tend to love it because UML tools keep them busy, but most developers don't care beyond boxes and arrows on white boards.