If you develop software long enough, you'll eventually run into Universal Modeling Language. This happened to me last year when we started working with our offshore vendor. UML is a diagramming standard that allows you to model software in a universal way. This could be theoretically be helpful if you were working with a bunch of developers in Bangalore, India. However, it doesn't take long to conclude that UML has some serious problems, even for simple development scenarios. The biggest problem is noted in the UML Wikipedia entry:
I tried UML several times and failed each time, precisely for the reasons you mention.
I don’t care which methodology a tool uses if it is useful. Class designer in VS2005 seems to be just good enough for simple prototyping and code visualisation, just what I need most of the time.
The class designer in VS 2005 is great…but is not all inclusive. There is still a purpose for Visio and other modeling tools outside of the development environment. Although, this will give project managers more cool pictures to show management and others and may help the developer communicate with the end user in an easier-to-understand-technie-talk manner. I like the new tools in VS 2005 and will be using them along side other modeling tools.
I don’t know… when I think about UML, all I can think is “I have to learn all this modeling language… and any other developer who wants to understand my program also has to learn UML?” It might have its uses, but I hope I don’t have to work with it. I’d prefer reading a simple text document.
Nobody is suggesting you use the UML stick figure diagrams as a requirements gathering tool. They are simply supplemental so the high level stakeholders have something to look at. Read any of the current books (especially Alistair Cockburn’s Use Case Books). I have never, ever read someone propose that these diagrams are it. There is ALWAYS a detailed document that accompanies these pictures and I agree they are close to worthless to developers. But to the C-Level stakeholders they are just what they need (if a prototype or Interative release is not available which are both far superior).
I think you all hate it because you were forced to use it. Could that be the case?
Besides, UML is not so “revolutionary”, they say it is. It’s just a combination of several techniques and tools that already existed. That means saying UML is bad, is like saying all previous methods were bad too.
My guess is that you do not dislike UML, but that you dislike all analysis maybe? Disliking analysis is something natural if you are not used to work in team on big projects.
Let me illustrate it: maybe one of you has ever worked with a genious programmer who does not comment his programming code and has his own way of making diagrams and sketches. I worked with this guy that gave all his variables animal-names. He really drived me insane. To give you a small example of the code he wrote:
He did have some kind of analysis method for this: a drawing of 2 tigers sitting next to eachother. One of them is starving to death, while the other is eating a little monkey.
The program worked excellent however. It worked truely amazing. But I heard they kicked him out about a year later because nobody could work with him. When they tried to replace him, they couldn’t find anybody capable of maintaining his code though.
What I am trying to say here:
Rules and dicipline are needed.
Communicationtools can be a real help.
It is not because you do not need it that the rest of the team does not need it.
my friend do you hate UML? read some of your articles and I’d found several critics and no one positive comment, why is that?
do you work sometime in a big time? you’d never needed understand some code rapidly through some UML sketch?
