Why does UML seem so hard?

I wrote up the following in response to Why is UML So Hard? I have edited a few things, but the message is fairly timeless. The blog, called CRAIC PROPAGATION, that I am responding to was not just that UML seemed hard, that it also produced poor results. With that context, lets get into why UML 'seems' so hard.

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's the problem: UML is a language. Just like you might 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.

Two ways to program

Below are two flowcharts that describe the thinking process of two types of programmers. On the left is what I would call 'good' and on the right is 'bad'.

Programming is not just coding. There are a lot of things to do. But what you normally see is what is on the right. The programmer is given a problem and they try to throw a technology at it.

On the left, there are a lot of things to do before you ever get to programming. Not saying that there isn't a little experimentation. This diagram is a summary, so there is some wiggle room, but the good developer does something related to each subject we have outlined.

You might ask why these two are so different? The first reason is time. Often a developer is assumed to be programming, not researching and designing. The second reason is that the first diagram does not have a lot of feedback to the customer and people in general are results oriented.

You might also say that the diagram on the right is Agile. Yes it is Agile, but it does not create any real design data other than the program and the testing is only done by the user.

You might also say that the second diagram is wrong because it is missing much of what defines Agile. This is a fair criticism, but again, this is just what most programmers do, not what they should do.

The first diagram could be expanded to be iterative, but I left that out for a reason. The fact is that these are tasks that should be required or verified if you are forced to do waterfall or you are ding XP or Agile. Each point should at least be considered or you rely on recorded information gathered on prior iterations.

What is the message? There are no shortcuts!

Programmer Thinking

Software development is problem solving. Simple enough, so why is it so hard?

The reason that software development is so hard is that we are solving many problems at once:

1. Solve the problem conceptually.
2. Design the user and data interfaces to allow the problem to be solved.
3. Use the API and language to implement the solution.
4. Create this in a context that executes the language and the APIs you have used so that it scales to the size of your user base.

There are a lot of assumptions too:

1. You understand how to solve complex problems.
2. You understand the problem domain which may be many domains.
3. You understand your programming language.
4. You understand many different libraries and standards to use as part of the solution.
5. You understand principals of good user interface design.
6. You understand basic principals of data design and perhaps database design.
7. You can think through your basic knowledge of the items above in a way that can create a viable solution

The productive programmer has all these skills covered or has learned how to quickly learn any one of these quickly to fill a gap. Can you begin to see why programmers are a specialty?

Shibboleth Software Developer Interviews

A Shibboleth is a type of test and was invented to look for impostors. Essentially you have a word that a foreigner can't say properly because their native language. This test goes all the way back to the Old Testament:

Gilead then cut Ephraim off from the fords of the Jordan, and whenever Ephraimite fugitives said, 'Let me cross,' the men of Gilead would ask, 'Are you an Ephraimite?' If he said, 'No,' they then said, 'Very well, say Shibboleth.' If anyone said, 'Sibboleth', because he could not pronounce it, then they would seize him and kill him by the fords of the Jordan. Forty-two thousand Ephraimites fell on this occasion.

So, first thing to notice is that this particular test resulted in a heavy penalty. The second is that if you have a speech issue, you are probably out of luck.

In WWII soldiers used a knowledge of baseball to detect friend or foe. Imagine if you were a football fan back then...

What I do like is that this a reasonably good test for interviewing software developers. I wouldn't worry about exact pronunciations, but phrases. Phrases are much more powerful indicators of impostors.

The one tool that I usually test a developer with is love and anger. Ask what the developer loves about the language or the API you need to have experience in. Then ask about what they hate. Unless you have great actors, they will fail these tests if they are not real experts or experience.

Don't just test your code, test your developers!