Thursday, October 8, 2009

Why Is UML So Hard?





I changed careers back in 1995. I jumped from mechanical engineering to software development. I've worked hard to try and learn what object-oriented programming is all about, what advantages it brings to helping to solve problems in software design and implementation.

First I learned C++, the great new language that Bjarne Stroustrup gave us. I thought that figuring out pointers when I moved from FORTRAN to C was hard; wrapping my brain around objects was much more difficult.

Then Java came along. I took a one-week class, but I didn't really get it.

Then I moved along to a company that wrote client-server accounting software using Visual C++. One day the CTO asked if I was willing to tackle an assignment that required Java. "Oh sure, I know that language," I said. I really had no business taking on that problem, but I muddled my way through it well enough to deliver something.

That company was struggling with the transition from client-server to a distributed, three-tier architecture. They had a long history with the Microsoft platform, but they liked Java's "write once, run anywhere" promise. Their clients were banks and businesses, not all of which ran on Windows. They also wanted to get away from the tight coupling between their user interface and the database tier. They had all their business logic tied up in stored procedures. This meant that they had to support Oracle, DB2, Microsoft SQL Server, Informix, Sybase - any flavor of stored procedure language that a client wished to run. They had a "can do" cowboy attitude that said hacking stored procedure code on site for a new customer was just good business, even if it meant that every installation was a custom. Why let an out-of-synch source code repository stop you from saying "Yes, sir!" to the customer?

The CTO brought in a bunch of folks to try and help them move to a more object-oriented approach. He bought several licenses to the most well-known UML tool of the day. He hired a consulting firm from the Washington DC area to come up and give us a week's intensive training in the use of this UML tool. When the pressures of keeping the production version rolling out the door subsided, he took us all to a hotel conference room, away from the office, and had us spend two weeks locked away with our UML tool, flip charts, and markers. When we were done, we'd have an awe-inspiring object-oriented design for the 21st century accounting system.

As you can guess, the two weeks were a disaster. No object-oriented design came out of those sessions. The company didn't get their distributed accounting system.

What went wrong?

We lacked a strong leader with experience at object-oriented design. We were still learning the tools. Domain knowledge in accounting and experience with the product varied among the participants.

Each session would start with something like "Let's do one use case." We'd draw stuff on flip charts and quickly veer off the road. Every discussion would descend into a dizzying argument that was a roller coaster ride from the heights of abstraction to the stomach-churning drop into implementation details. I was trying to persuade them to list the steps for accounts payable when one old hand smirked and said "I can tell you what accounts payable is! Pay me!", holding out his hand with palm facing up.

The developers would scowl and listen quietly until one of them would stomp out of the room, tossing something like "If you don't make up your mind soon, I'm just going to start coding what I want" over their shoulder as they headed towards the soda machine.

We couldn't agree on what words meant. We'd have bike shed arguments for hours about what "customer" meant. We couldn't agree on how to drive from a meaningful description of the problem at hand to artifacts that a developer could use to produce working code. It's as if we'd get bored or frustrated doing that very hard work and give up before the payoff.

I left the company soon after those sessions ended. There was a layoff within six months. The CTO was forced out in a power struggle with the other two founding partners.

Fast forward eleven years. I'm working for another large company that is struggling with a transition from an older platform to a more modern one. UML has been championed as the cure for what ails us. Licenses to another UML tool have been procured. Training will commence. A large cross-disciplinary team has been convened to go through the UML design process. Consultants have been hired to shepherd us along the path of righteousness.

The funny thing is that it feels just like those sessions I sat through eleven years ago. Every discussion descends into a dizzying argument that's a roller coaster ride from the heights of abstraction to the stomach-churning drop into implementation details. We can't agree on what words mean. We have bike shed arguments for hours about design minutia. We can't agree on how to drive from a meaningful description of the problem at hand to artifacts that a developer can use to produce working code.

We'll see if we get bored or frustrated doing that very hard work and give up before any payoff comes through.

This might be the growing pains of a new team. But what if it's something wrong at the heart of UML? This object-oriented notation for rendering design decisions, codified and maintained by the Object Management Group, was born out of years of notation wars among the Three Amigos - Booch, Jacobsen, and Rumbaugh. They created a notation (UML), a company (Rational), a software tool (Rational Rose), and a software development methodology (Rational Unified Process) before selling out to IBM.

Agile approaches have largely discredited heavy approaches like a full-blown UML design.

Maybe somebody has found that this is a good way to develop large software systems in a team setting, but I haven't seen it yet. Things don't seem to have improved a bit in the past eleven years.




5 comments:

Unknown said...

I had high hopes for UML but quickly soured on it, around the same time you did. We used Rational Rose, the worst software I've ever used. Buggy, inconsistent UI, never work well with MFC code, etc. And we had a consultant from Rational working closely with us.

Aside from tool problems, UML (at least how we were using it) was too complex. We tried to capture too much detail in UML. It was easier to just write code.

Pete Kirkham said...

I started with a longer comment, but it got too long so I made a post instead.

What you describe is quite common, partly it's not UML's fault - the same happens whenever you introduce a tool into a process without thinking about how the tool's inputs and outputs disrupt that process - some of it's due to the way UML is taught ( small examples which give the illusion you should try and capture everything about a system in one setting; examples such as 'create a model of a bicycle' without thinking what the responsibilities of the bicycle class are in the context of the system it resides in ), and some of it really is UML's fault - as a notation it ignores quite a bit of human factors research, its roots as a view of the classes in a systems means it doesn't capture the narrative of how a design fits together.

turbogeek said...

I have been doing UML now for approximately forever... at least in software years.

I am also the chief architect at NoMagic, producers of MagicDraw UML. So I am a little biased, but only in this job for a few years, so not born into the religion of UML because of the signature on the paycheck.

Here the problem: UML is a language. Just like your experience with Java, if you don't get it, you don't have it.

Just because you know English does not mean you can write the great American Novel. You need to know how to model to create a great design. UML is just syntax for the model.

When you come to my class, I teach modeling. The syntax of the larger pieces of UML sort of disappear because of the approach which is to only model certain things at one time.

The biggest problem people have is levels of abstraction. Most people have verbal diarrhea when they model. This causes most of the problems.

Another issue is people seem to forget about requirements. Requirements have a bad name, so let me say that these are just simply statements about what the design 'must' do. The more you constrain your design to fulfilling the requirements, the fewer issues you will have with pointless models.

There are two new OMG standards that have been added. UPDM does enterprise architecture. I love it because it forces you to think about software in the context of its use.

The second is SysML. It was created for engineering. However its most useful and strangely simplistic feature is the ability to model requirements and relate them to your design and tests.

But why is UML so hard? Most people are allowed to simply do, not learn and perfect their modeling skills. There is not a silver bullet unless you have the skills to shoot the gun and hit the target.

I am working on changing this in our tool. We are adding wizards, helpers, and even a little artificial intelligence. It won't make you a world class modeler, but it will keep you from shooting yourself in the foot.

Michael Duffy said...

Daniel, thank you for taking the time to comment. I greatly appreciate hearing your views. I will say that Magic Draw was part of a UML tool "bake off" that our team did last year. I was pleasantly surprised by your product's capabilities.

My preference was JUDE community, because I liked the price and shallow learning curve; we chose Sparx Enterprise Architect because our boss had past history with it and another group inside the company was already using it. I find it to be quite capable.

Can 10,000 Elvis fans be wrong? If UML hasn't taken off, is it the failure of the audience or the technology?

It's an argument that doesn't resonate with me. Software methodology folks tend to use it: "If the methodology doesn't work for you, it means you're doing it wrong." It has a faith-based tinge to it that bothers me.

Your point is well taken - maybe my lack of talent with UML colors my attitude towards it. Maybe the wizards in your product and instruction from someone like you with more ability than I possess might win me over. Perhaps someday I'll get the chance to see.

Thank you again for reading and commenting.

Unknown said...

hi! wow! thanks for another great blog post!
Customized application development