Sometimes, a word is worth a thousand pictures

In one of my recurring nightmares, I'm chased down a crowded street by a
gang of business analysts who scream at me:

"Use a mouse to write your programs or suffer the consequences.
Programming is pictures you know!"

In my dream, I keep one step ahead of the lynch mob in my picture-less,
black and white, Emacs world. I manage to get my programs to work before
they have me fired and then wake up in a cold sweat.

Every time I have the dream, the mouse-wielders get more numerous.
However, they don't get any closer to beating me when writing business
logic. They kick my ass when doing data entry screen prototyping though.

There is a rumor (or is it another nightmare?) afoot that it is only a
matter of time before business analysts will be able to model the
business logic of a process graphically and then have it executed
without any intervention from software developers.

I'm not going to hold my breath. Yes, I can see how simple
draw-and-execute could work for ultra-simple business logic but if my
experience is anything to go by, business logic is rarely so simple that
it lends itself to complete representation in diagrammatic form.

There comes a point - I'm not sure exactly where it is, but its there -
where no amount of drawing pictures to "express" the business logic,
will actually express the business logic. Sometimes you need the words
and the words in question are called programs. Programs created by
programmers - not business analysts.

One of the key words on that point that separates pictures from programs
is the word "if". Programmers spend a lot of time crafting what are
called "if expressions" to get programs to behave as desired. A lot of
complex business logic ends up in these "if expressions". How would you
draw an "if"?

As it happens, programmers have conjured up techniques for drawing
programs visually many times in the history of computing. There are
numerous routes to graphical "if"s if that is where you want to go. But
here is the rub. None of these visual programming techniques have become
mainstream as an alternative to hand-crafting. We are still very much at
the stage that visualizations of business logic are an adjunct to,
rather than a replacement for, hand crafted computer programs.

Having read this far, it will come as no surprise to you that I am not
bowled over by the idea that somehow, Web Services magically make
business process visualization possible in a way that wasn't possible
before. I don't get it. I, quite literally, cannot see it.

That's the bad news. The good news is that I think we can get a lot
further with business process visualization than we have to date. The
trick, I believe is to de-emphasis visualization of the process control
and emphasize visualisation of the *effect* of a process in terms of
data flow.

If you prefer the former, you are probably a programmer and if you
prefer the latter, you are a budding (or practicing) business analyst.
Reconciling these two world views is the real challenge of visual
business process modelling.

The answer to visualizing business logic does not lie in standards or
programming language wars. The answer lies in understanding when
pictures are preferable to words and visa versa.

As with so many other things, I suspect there is a spectrum there and we
will need both. Programming has a long way to go before it is obsoleted
by mouse wielding business analysts.

» posted by ITworld staff

ITworld

Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine