Business Analyst Wanted

A break from the ordinary. I am looking for a Business Analyst with BPMN.

The jobs are in London and up state New York. This is in Banking and concentrates on Risk Management, Disaster Recovery and other aspects related to financial and operational risks.

Need three people in each location. This is for Business Analysts skills and specifically the ability to create models with the BPMN standard (Version 1 and especially version 2). Not too picky about being in banking, but it helps. Mainly looking for the ability to do a mind meld of a business and document in BPMN.

At this time I am unaware of rates or duration, etc. Given that it is for six people, it smells quite big. This will be with No Magic.

So, if you feel this is your cup of tea, call 214-291-9100 and ask for Jim Rice our head of services. If this is not in a comfort zone and you have some friends that can play in this area, please forward the email.

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!

Artificial Stupidity

Artificial Stupidity (AS - pronounced rudely as you would expect) is an important discipline and I believe a growth area in computer science.

Look at the things we can do with AS:

• Dumb monsters in games
• Automating the news reporting at Fox News
• Anticipating typos or mistakes
• Turning off computers in the cockpits of airplanes that are overshooting airports
• Politicians
• Testing of artificial intelligence
• Thesis committees for AI doctoral candidates
• Better ways to annoy MS Word users with silly assumptions about spelling or formatting automation

Actually there are endless applications for AS. You could do a Turing Test that if the human agreed with the AS, we could confirm the human is a politician, mid level manager, or works for Fox News.

There are many places to learn about AS. For example, NASA. Not the space flight NASA, but the National Artificial Stupidity Association at the University of New Mexico.

Unfortunately this is sot something you can get a degree in. You have to specialize, maybe write a book or make it part of your doctoral thesis (writing one book is the equivalent of 300 blogs or a doctoral degree).

The funny thing is that there are already a lot of AS professionals (or is that AS pirates?). There are a lot of smart folks out there, but some are just plain bad. So, write bas AI, you automatically become an expert in AS.

AS's are everywhere! We have been awaiting self aware machine intelligence, but I think we see AS emerging right now all around us. Look at MS Word and its auto-formatting for wonderful example. Even though a lot of software was designed with traditional techniques and no AI or expert system code. Airline sites that pick only pricey tickets, shopping carts that forget what you bought, most applications have become 'self stupid'.

JRuby Trick: Saving time instrumenting Java classes

Ever with you could teach a class a new trick without wrapping or extending capabikities in a new class?

One of the issues I initially had issues with was extending Java to do cool things with Ruby.

First the Java class:

public BoringPig{

public String getName(){

return "name"

}

}

Being a Java guy, my first attempt at adding Ruby to Java looked like this:

class FlyingPig

def initialize(boringJavaObject)

@boringJavaObject = boringJavaObject

end

def flyPiggyFly

# ..... exciting stuff,

puts @boringJavaObject.getName+ " is flying!!!!"

end

end

But this meant I had to create a new Ruby instance. If I have a lot of objects, I ned to visit each one and create my Ruby version.

Instead, here is a cheaper way that simply adds the new method to the existing class

class BoringPig

# adds this method to any existing BoringPig objects or new instances of BoringPig

def flyPiggyFly

# ..... exciting stuff,

puts getName + " is flying!!!!"

end

end

Note that I don't need to fiddle with the initialize anymore. I also don't have a pointer to the object because the instance is the same. the "getName" could have been written as "self.getName", but self is implied.

To summarize, I have made a pig fly without creating a flying pig class.

Essentially I am extending the class rather than wrapping. Because Ruby is much more dynamic about when you add a method to a class definition, I can do this at any time for any reason. This could also mean that I could extend the class depending on the context and what I need to do. This is sort of like adding a visitor method directly to a class definition.

Why else would I do this? Basically I have a ton of Java in a very wordy API. I would like to reduce the churn of code to do things with these classes. For example, I have a class that has a very deep relationship that changes the classes use and context. Rather than create a wrapper for the new use and context, I can simply bubble this up to the methods of the root object. For you UML guys, I am adding stereotype info at the class rather than digging for it deep in the association of the stereotype tags.

Fun trick.

Pretty cool! This also meant my software runs a lot faster and takes a lot less memory.