This wasn't the Three Amigos fault. They did quite impressive work on the meta-model aspect of UML. It was defeated by two forces. First, the fundamental problem lies with the amorphous nature of software itself. Coming up with a really expressive graphical notation is hard. Most developers know enough to draw boxes for classes and open-arrowheads for inheritance, but don't get much further into the UML specification because it gets quite convoluted (especially if you start looking at the later generations of UML, with Object Constraint Language and its ilk).
The second failure reason is the implicit assumption that you need (nay, must) design all the classes and interactions before you start writing code. Big Design Up Front is a failed technique in almost all software development. The only exceptions are systems that are truly life and death. One of the reasons for the outdatedness of the software on the space shuttle lies with the fact that they have very long iterations. In other words, they are willing to say "once this date passes, we will make no changes to the design of this system. Period." While most business software could make this statement, it ill serves the business. Business processes change like the weather, and you need software that can change just as readily. I don't come to this discussion as a dilettante: for a while, I worked for a company that was a Rational partner. We did the training, and we built software based on the Rational Unified Process. We even had some successes. But it didn't take long for us to realize that the upfront design didn't serve our clients because it hampered the kinds of changes required by their business.
Most developers I know use AML: Arbitrary Markup Language, usually consisting of boxes, circles, and lines. When a given developer writes on a whiteboard, they write in their own version of a diagramming language. It's a shame that we don't have an industry wide diagramming language that everyone feels compelled to use, but that's the reality in most places I've been for the last 5 years. But, having said that, I'm a fan of AML, because it cuts down on irrational artifact attachment: you have nothing except the last 5 minutes invested in the diagram, making it as transient as possible. Transient artifacts are good because you're willing to throw them away, preventing them from becoming a part of the documentation for your project once the actual code has migrated away from that initial stab at design. Out of date documentation is worse than none at all because it actively misleads
12 comments:
I think you mean Arbitrary Modeling Language, not markup. Even in jest, what you describe wouldn't be markup.
Great article.
Regarding the Rational Unified Process (RUP), in this article Scott W. Ambler describes it this way :
"RUP is a comprehensive process framework for iterative software delivery which can be instantiated anywhere from a very agile form to a very traditional form as your situation warrants. RUP practices include risk-value lifecycle, whole team, test-driven development (TDD), business process sketching, and continuous integration."
This seems different from your view of RUP.
Why are you saying that RUP requires big design up front? Would you care to elaborate on this?
Yes, substitute "markup" for "modeling". Fat finger mistake.
Just because Scott Ambler and IBM says that RUP is agile doesn't make it so. Generally and historically, RUP and UML defines Big Design Up Front, and they are shifting the marketing because they know that it's ineffectual.
I certainly agree with your overall points about the limits of the existing UML diagram types.
A suggestion: Why not study actual on-the-fly whiteboard diagrams and try to distill the half-dozen-or-so most common patterns? We might learn a lot from seeing how people intuitively diagram problems/solutions.
Making it easier to create UML diagrams doesn't make it an effective communication tool for the reasons I highlighted in the first part of the post.
Hi, Neal
Great post.
Purpose is critical.
I think diagrams fail as a means of expressing software designs for automatic code generation.
However, they can be very useful at conceptual modelling for purposes of understanding and communicating between humans.
The key issues here are expressiveness and relevance, instead of completeness and preciseness.
Rafael Peixoto de Azevedo
http://symprise.net/
You say: "Out of date documentation is worse than none at all because it actively misleads"
While generally this has a large amount of truth, I like the reading the old documentation to get a sense of the "direction" the originators were taking. There are usually very interesting nuggets of information as to why something is the way it is.
Good points Neal. For many year, we struggled to use consistent ways to represent our design and finally gave up on it.
It was a smart decision to leave it to the creativity of the engineering team itself.
What followed was simple and easy to read design diagrams.
Thanks for your post. I wish even a tiny percentage of my clients would read it and act accordingly.
I try to tell them that "designing" the program (which to them means making UML diagrams) and then coding it afterwards (mostly by autogenerating it) is just waterfall by another name (since they never go back), but your explanation is much better.
Great job, yet again. :)
Your two big assumptions seem to be:
a) nobody finds it satisfying to work directly with UML to represent their ideas.
b) "Big Design Up Front is a failed technique in almost all software development"
Both resonate with me (although what person is familiar with "almost all software development"? Honestly1).
What I don't understand is the conclusion that these make UML a failure. I'm no major fan of UML or anything but, in my experience, most UML has been generated and tweaked. In other words, it is not necessarily the starting point of development and effective use tends to rely on translation to and from something else.
Personally, I've used UML on legacy code to quickly find patterns/models that may need removal or tweaking. In theory (emphasis on, "in theory"), I could have used the UML structures I generated and tweaked to regenerate some code. Thus, starting a rather Agile feedback loop. Some Ruby programmers are even talking about integrating their Cucumber stories into this kind of feedback loop (UML translators permitting).
Given this, the conclusion that UML has failed, at least for some of us, doesn't yet fit.
I appreciate the tone of your article but have to point out one major flaw in your argument. UML is a notation, pure and simple, it is not a process; any criticism of design up front is a criticism of process and can;t be directed at the notation.
If I do have a big gripe about UML it is the hi-jacking of it by the tool providers in UML2, over-tightening the syntax to support aims like MDA but in the process, making most tools inflexible for day to day use in the early exploration/analysis stages (*Arbitrary UML?).
The Elaboration phase can in no way be described as BDUF, it is simply ensuring one is building the right system the right way - but to do that you need a certain amount of up-front scoping to a satisfactory and sufficient degree(80%).
Sounds like you've encountered bad application of RUP rather than UML.
Post a Comment