a***@googlemail.com
2008-06-02 20:54:42 UTC
UML lost the programmers. There is no doubt about it… in my mind. And
when a software design technology loses the programmers it fades away
no matter what the academia thinks. This happened because UML was
pushed in a direction that most code writers don’t like: it started to
look a lot like bureaucratic paper work. If we list what went wrong it
starts to look a lot like the mishaps of other committee driven
technologies like CORBA for example. In random order I can list:
http://littletutorials.com/2008/05/15/13-reasons-for-umls-descent-into-darkness/
1. Design by committee
This one is very big and usually a recipe for failure in the long
term. Just look at CORBA and for a new case at the never ending list
of web service standards.
2. The obsessive focus on monetizing UML
Trying to sell expensive tools for a technology that is not mature
enough and only makes promises to the management (just express your
ideas in pictures and the code will be generated by our magic wand)
can only work in short term. At some moment somebody realizes the
costs are too big for the benefits. Lots of programmers instinctively
hated the whole thing. Others were persuaded by management or by
curiosity to try it. Most of them never used UML tools for more than a
project.
3. Tries to unify everything even the kitchen sink (UML specs > 800
pages)
When you try to offer a solution for every problem in a domain, in the
end you are not offering anything useful for any problem in that
domain. UML tried to solve all the issues with software development.
My feeling is it just forgot about the “software development” part.
Software is used or it can be used in almost every human activity.
Trying to capture everything is an impossible task - even at 800
pages, UML covers only a small part of the complexity of software
engineering needs. It is too big but still too generic and abstract.
4. Departure from what programmers perceived as the initial goal
As a programmer I liked the standardization UML provided for design
related communication. It was great to be able to use a common set of
symbols to communicate my ideas to another programmer or designer. I
think most programmers still use only the class diagram and maybe
occasionally when they write a document the sequence diagram. UML
started to go up into the stratosphere with all those business
oriented diagrams that even the business people didn’t understand or
use.
5. Concept bloat
Trying to bridge UML to reality made it incorporate concepts from all
the languages in fashion during the last 10-15 years. Anybody knows
how to represent a Java anonymous inner class?
6. Always catch-up with new languages and concepts
In continuation of the above… and because the promised prize was full
code generation you have to be able to represent specific language
constructs. Closures in UML anybody?
7. UML attempts to become a programming language
By aiming to be able to generate full code actually UML tries to be a
programming language. In my mind there is a big problem with a general
purpose graphical programming language. In human history the written
form of all languages evolved from graphical to textual. Alphabets
proved to be more versatile and more expressive than pictures in
capturing ideas. Try to describe any simple process in images. The
funny thing is you still have to annotate the images with words. And
the full text version with no pictures still gives you more details.
Pictures prove to be good at sharing ideas and allowing people to
visualize concepts. But in the end words are better at describing the
fine details.
8. The need for expensive tools vs. just a text editor
The entry level for using UML for more than just informally sharing
ideas on a white-board is very high. Tools that are any good are
insanely expensive. On top of that they need training as they are not
all the time the most intuitive tools. They start to look like a
solution screaming for a problem to solve. Consulting companies seem
to love these tools since they open opportunities for expensive
training courses.
9. Lack of model clarity
Pictures are interpretable. I heard this kind of complaints from
programmers trying to understand the design of a system from UML
diagrams: you need to read the code to understand what the diagrams
mean.
10. Lack of solutions for real software design issues
While the specifications are huge there are no good solutions for
problems common in software systems. Quick examples are:
* No solution for multi-tasking and communication between tasks
* No dependency between use cases
11. Assumes you can know everything before writing the first line of
code
The concept of writing first the user manual and then the generate the
code based on it is a noble goal but… probably impossible to achieve.
In practice everything is so dynamic, that the maintenance of the UML
diagrams so they conform with the reality of the code becomes very
fast a chore nobody wants to do.
12. Treat software development like manufacturing
Software design is not manufacturing no matter how much management
likes to think about it this way. Software creation is a creative
activity so a more accurate description would be craft, art or
something along this line. UML tries to standardize and formalize the
unknown, the imagination and the talent.
13. UML tools focus on the wrong goal
Most of the UML tools out there promise code generation. This is most
of the time useless since they generate just empty class bodies with
no logic. It is also cumbersome and annoying because one has to keep
the code and the diagrams in sync. Some even use ugly formatted
comments as markers.
Another problem with these tools is the amount of real estate diagram
elements take on the screen.
I tried many times to look at UML diagrams of complicated systems but
looking at only the lower left corner of a class square along with two
crossed segments doesn’t help much with understanding.
I think the tools should have focused on reverse engineering for
documentation purposes. In my opinion no decent reasonable priced tool
exists in this area. Even tools that manage to decently reverse
engineer the code do a poor job for documentation purposes since they
cannot differentiate between what is essential and what is just noise/
boilerplate in the code.
As a result most finished projects that use UML have code that doesn’t
resemble at all the nice UML diagrams drawn at the beginning of the
project.
In general I don’t think code generation is a good idea. Usually what
can be generated is repetitive code and most projects would be better
off with that common code implemented in a library and called from
there.
In the end as a conclusion I think UML had a generous idea to bring
software designers speak a common language. But this idea got lost on
the way for economical reasons. And when the value is lost the
customers leave.
This article is part of a series of opinions and rants:
* 1. 13 reasons for UML’s descent into darkness
* 2. 13 reasons why Ruby, Python and the gang will push Java to
die… of old age
when a software design technology loses the programmers it fades away
no matter what the academia thinks. This happened because UML was
pushed in a direction that most code writers don’t like: it started to
look a lot like bureaucratic paper work. If we list what went wrong it
starts to look a lot like the mishaps of other committee driven
technologies like CORBA for example. In random order I can list:
http://littletutorials.com/2008/05/15/13-reasons-for-umls-descent-into-darkness/
1. Design by committee
This one is very big and usually a recipe for failure in the long
term. Just look at CORBA and for a new case at the never ending list
of web service standards.
2. The obsessive focus on monetizing UML
Trying to sell expensive tools for a technology that is not mature
enough and only makes promises to the management (just express your
ideas in pictures and the code will be generated by our magic wand)
can only work in short term. At some moment somebody realizes the
costs are too big for the benefits. Lots of programmers instinctively
hated the whole thing. Others were persuaded by management or by
curiosity to try it. Most of them never used UML tools for more than a
project.
3. Tries to unify everything even the kitchen sink (UML specs > 800
pages)
When you try to offer a solution for every problem in a domain, in the
end you are not offering anything useful for any problem in that
domain. UML tried to solve all the issues with software development.
My feeling is it just forgot about the “software development” part.
Software is used or it can be used in almost every human activity.
Trying to capture everything is an impossible task - even at 800
pages, UML covers only a small part of the complexity of software
engineering needs. It is too big but still too generic and abstract.
4. Departure from what programmers perceived as the initial goal
As a programmer I liked the standardization UML provided for design
related communication. It was great to be able to use a common set of
symbols to communicate my ideas to another programmer or designer. I
think most programmers still use only the class diagram and maybe
occasionally when they write a document the sequence diagram. UML
started to go up into the stratosphere with all those business
oriented diagrams that even the business people didn’t understand or
use.
5. Concept bloat
Trying to bridge UML to reality made it incorporate concepts from all
the languages in fashion during the last 10-15 years. Anybody knows
how to represent a Java anonymous inner class?
6. Always catch-up with new languages and concepts
In continuation of the above… and because the promised prize was full
code generation you have to be able to represent specific language
constructs. Closures in UML anybody?
7. UML attempts to become a programming language
By aiming to be able to generate full code actually UML tries to be a
programming language. In my mind there is a big problem with a general
purpose graphical programming language. In human history the written
form of all languages evolved from graphical to textual. Alphabets
proved to be more versatile and more expressive than pictures in
capturing ideas. Try to describe any simple process in images. The
funny thing is you still have to annotate the images with words. And
the full text version with no pictures still gives you more details.
Pictures prove to be good at sharing ideas and allowing people to
visualize concepts. But in the end words are better at describing the
fine details.
8. The need for expensive tools vs. just a text editor
The entry level for using UML for more than just informally sharing
ideas on a white-board is very high. Tools that are any good are
insanely expensive. On top of that they need training as they are not
all the time the most intuitive tools. They start to look like a
solution screaming for a problem to solve. Consulting companies seem
to love these tools since they open opportunities for expensive
training courses.
9. Lack of model clarity
Pictures are interpretable. I heard this kind of complaints from
programmers trying to understand the design of a system from UML
diagrams: you need to read the code to understand what the diagrams
mean.
10. Lack of solutions for real software design issues
While the specifications are huge there are no good solutions for
problems common in software systems. Quick examples are:
* No solution for multi-tasking and communication between tasks
* No dependency between use cases
11. Assumes you can know everything before writing the first line of
code
The concept of writing first the user manual and then the generate the
code based on it is a noble goal but… probably impossible to achieve.
In practice everything is so dynamic, that the maintenance of the UML
diagrams so they conform with the reality of the code becomes very
fast a chore nobody wants to do.
12. Treat software development like manufacturing
Software design is not manufacturing no matter how much management
likes to think about it this way. Software creation is a creative
activity so a more accurate description would be craft, art or
something along this line. UML tries to standardize and formalize the
unknown, the imagination and the talent.
13. UML tools focus on the wrong goal
Most of the UML tools out there promise code generation. This is most
of the time useless since they generate just empty class bodies with
no logic. It is also cumbersome and annoying because one has to keep
the code and the diagrams in sync. Some even use ugly formatted
comments as markers.
Another problem with these tools is the amount of real estate diagram
elements take on the screen.
I tried many times to look at UML diagrams of complicated systems but
looking at only the lower left corner of a class square along with two
crossed segments doesn’t help much with understanding.
I think the tools should have focused on reverse engineering for
documentation purposes. In my opinion no decent reasonable priced tool
exists in this area. Even tools that manage to decently reverse
engineer the code do a poor job for documentation purposes since they
cannot differentiate between what is essential and what is just noise/
boilerplate in the code.
As a result most finished projects that use UML have code that doesn’t
resemble at all the nice UML diagrams drawn at the beginning of the
project.
In general I don’t think code generation is a good idea. Usually what
can be generated is repetitive code and most projects would be better
off with that common code implemented in a library and called from
there.
In the end as a conclusion I think UML had a generous idea to bring
software designers speak a common language. But this idea got lost on
the way for economical reasons. And when the value is lost the
customers leave.
This article is part of a series of opinions and rants:
* 1. 13 reasons for UML’s descent into darkness
* 2. 13 reasons why Ruby, Python and the gang will push Java to
die… of old age