Programming by Drawing

I’m a big fan of specialized editors. I disagree, strongly, with people who believe that one of either vi or Emacs is the hammer of all hammers that really does make all problems into nails.

I’m also a big fan of WYSIWYG editors. I like, for example, Dreamweaver as an HTML editing tool. I almost always use it in the “both WYSIWYG and source code” mode. Even if I want to fiddle with the specific HTML tags, I find it tremendously satisfying to click on a particular cell of a table and have the source view automatically move my cursor to that specific TD tag. No scanning through the code looking for the right spot.

But something I haven’t yet believed in is the visual programming paradigm. I first ran into this in VisualAge for C++ and, later, for VisualAge for Java. These tools tried to entice me by telling me that I could program just by connecting dots. Select a button, draw a line to a bean, select a method to invoke. Simple, in a sense. But it never worked. The visual programming paradigm lacked a kind of necessary expressivity. Try doing a complicated if/else if structure in a visual tool, and you quickly become disillusioned.

As a result of these early experiences, every time I see a vendor pitch a product to me that uses some kind of visual programming, I’m dubious. I’m not sure I believe that visual programming can’t ever work, but I don’t really think I’ve seen the nut cracked.

So recently I was reflecting on a couple of interesting cases:

  1. All the J2EE vendors have a product that’s categorized as a “Business Process Management” tool. For example, JBoss has one called jBPM. These tools generally provide editors that allow you to “draw” out a workflow, and the output of that drawing is used at runtime when the tool processes a piece of work, and pushes the piece of work through the workflow. I suppose I never reach the Aha moment of these tools because I’ve never seen an example that was easy to understand, and yet demonstrated the power of the technology.
  2. SEAM can use essentially the same paradigm when defining “page flows” — you don’t have to define the page flow visually (the output is stored in an XML file), but a visual editor makes it nice. And I really believe that in cases like this a picture is worth a 1000 words.

I find myself mentally debating my opinions on Business Process Management tools. Certainly, when you see the sales pitches, they’re really big on promoting the idea of “hey, you get this great diagram of your business processes, and even you customers can understand the diagrams!” (Which sounds a lot, to my ears, like “Even managers can read COBOL!”).

It doesn’t help that I’ve had really bad experiences with BPM/workflow tools in the past: in an earlier job, I dealt with a guy who wanted to use Mosaix ViewStar, a workflow tool, as a general tool for building business applications. It wasn’t a strategy that I believed was sound then, and I still disbelieve it. But it was interesting to hear Gavin King (Gavin King!) talk about how one of his objectives with SEAM was to raise the profile of BPM tools.

I have no conclusions. I’m attracted to SEAM’s page flow definition. I’ve certainly started to feel that web frameworks need to model page flows more formally (and SEAM and Spring WebFlow seem to be the two big frameworks entering this space), and I kind of like the visual aspect, in this specialized space.

And while I’m still hugely dubious about “visual programming” as a selling feature of BPM tools, I feel like there’s a big Aha moment out there waiting to find me.

It's only fair to share...
Share on Facebook
Tweet about this on Twitter
Share on LinkedIn

Leave a Reply