There are already quite a few articles raising “Why?” questions on BeyondJava.net. This seems to become a special feature of this web site. Today’s “Why?” question came to me when I was reading Scott Ambler’s article UML 2.5: Do You Even Care?
Scott writes he used to be big on UML a couple of years ago. He’s clearly been one of us who were propagating graphical modeling. But now he’s struggling to get interested in the new version of UML that’s coming soon.
Does this sound familiar to you?
Actually I had exactly the same experience. Back in the 90’s everybody told us UML was the Next Big Thing. You can’t expect your company to survive without UML, they said. Let alone growing. Coding without drawing images is what we did in the 80’s, the stone age of computer science. And even back then images depicting certain aspects of programs were ubiquitous. Do you remember Nassi–Shneiderman diagrams? Flow diagrams? Entity relationship diagrams?
I even bought a book consisting of 200+ pages dealing with the sole topic of bringing colors to UML diagrams. Colors add value to business models, we believed at the time. Including me. Colors were cool. Not that I ever draw a multi-colored diagram, but I liked the idea. To be honest, I still like it today. However, for some reason I never made up my mind to design a consistent system assigning colors to tasks. So my UML diagrams remains mostly black-and-white.
Granted, E-R diagrams are still there. They really proved their value. However, the random example diagram Google showed me first when I was looking for a nice E-R-diagram clearly shows the problem about diagrams visualizing code: they tend to be large. Often they are way to large to be useful.
Some ten years ago they hired me as a UML coach (plus a few other tasks). I enthusiastically started teaching UML. Pretty soon I noticed a certain reluctance of my new co-workers. No matter how hard I tried, I could hardly ever convince them to draw pictures. There’s only one project we really did model with UML. It was the first project I was responsible for. After that my co-workers just abandoned UML.
They wanted to return to the stone age of computer programming, I thought at the time. They were reluctant to leave their cozy cave they inhabited during the last couple of centuries.
Today I’m convinced my co-workers decided wisely. UML really is causing more trouble than it’s worth.
It wasn’t always so. Back in the 80’s and 90’s diagrams did help us. Powerful IDEs were yet to be invented. There simply was no tool showing you the structure of your code. VI and edlin only show you the gory details of your code, not the underlying structure.
I remember how much I loved TogetherJ. At the time it was the only tool knowing how to refactor code. Each time I wanted to refactor a method name I closed my IDE, started TogetherJ, did the refactoring there, closed TogetherJ and re-started my IDE. Nowadays this sounds like a tedious task. Can you imagine this was a real killer feature?
I suppose that’s the most important feature why UML ceased to be en vogue. Modern IDEs do a pretty decent job when it comes to reveal the source code’s hidden structure. Every IDE knows how to refactor your code in a dozen ways, and the information where a class, method or attribute is used is just one or two mouse clicks away. Visualizing the class hierarchy is just as easy. For instance, Eclipse users simply hit the F4 key.
The moment developers could see their code’s structure without leaving their beloved IDE the second common trait of most developers became visible. We don’t want to paint pictures. We’re text workers. We’re drawing images if nothing else helps. Architects still love their diagrams, with SAP’s fridge possibly being the most famous example. It’s really astonishing how many diagrams are inspired by the SAP fridge – including a couple of diagrams of mine.
Architecture diagrams do reveal informations buried under tons of code. The average UML diagram shows much more detail. Sequence diagrams even show individual for loops and conditionally executed code (aka
if statements). Truth be told it’s easier to have a quick look at the code than trying to decipher a sequence diagram. Plus the code is up-to-date. The sequence diagram may never have been updated during the last couple of releases.
I guess that’s why UML diagrams aren’t fashionable today: they ceased to be useful, they are almost always wrong (because they show what the code looked like when the diagram had been drawn instead of showing what the code looks like today), your display is never large enough to show an entire UML diagram and programmers prefer to work with texts, anyways. After all, they didn’t apply as painters, they applied as programmers.
I also remember MDA and MDD being en vogue once UML was widely accepted as the standard tool. That’s just another technology that proved to be mostly useless (albeit there are quite a few success stories). There’s some merit to model driven development – but who said models have to be graphical? They don’t. Remember, programmers are text workers. They’re happy with textual models. If you want to do model driven development, I recommend XText. Basically, XText is just a nice tool to develop domain specific languages, so what I’m really advising is to create a DSL – no matter whether you do it in Groovy, Scala, XText or any other language that suits your needs. The bottom line is it’s unlikely you really need graphical clues to get your job done.
Funny thing is most of our bosses still insist on writing lots of documentation including diagrams. The explanation is simple: they are one or two generations older than the average developer. When they were developers themselves they desperately needed diagrams, documentation and every other hint our nifty IDE nowadays gives us for free.
Sometimes it’s needs to remember the good old times to see how much we take for granted :).