I really enjoyed reading Secret Geek's (AKA Leon Bambrick) post today: Workflow software: I'm calling the bluff. Leon has a major gripe about workflow tools, especially the graphical tools that are their real selling point. Non-programmers love graphical tools. Why? Because code scares them, whereas the pretty pictures seem to make so much more sense. Non only that but, wonder of wonders, you can get business users to design the software. Wow, think of the savings of removing those expensive, scruffy awkward coders. Leon throws down a challenge:
"Show me a working 'business analyst' -- one, who is not now nor has ever been a coder -- who successfully designs 'business workflows' using an off the shelf tool, and who didn't require *any* expensive training, and who achieves their task in less time and with more precision than a coder. And who doesn't need to call technical support for help at the time.
Show me just one.
World wide.
I can wait. I give you one month. Nah, screw it. I give you eternity."
Somehow, I don't think he's going to see any challengers.
Visual tools make for great marketing. That's why so many companies spend so much money on Enterprise Workflow/Service Bus/Business Rule Engines. It's simple evolutionary psychology, Humans are evolved from fruit eating primates, we instinctively like anything with lumps of fruity colors. Code doesn't have that, it looks like something scary and mathematical. It's very hard to sell. But show some management type a colorful tool where you can simply drag and drop a few shapes to make a simple workflow and they're sold.
So what's the problem? It's simple: software is complex. Now that's not just a bit tricky, like sodoku say; it's seriously complex. Most visual tools give you little boxes that do an operation like a decision or maybe a calculation and those boxes are joined together with little lines. Hey, it's just like a programming language, except prettier. The problem is it's just like the simplest programming language. In fact it's a bit like the orginal BASIC:
I used to write very simple BASIC programs on my TRS-80 as a child. But even they sometimes had hundreds of lines of code. Imagine a picture with a hundred little boxes and several hundred little lines connecting them. You can only see the whole thing when it's zoomed too small to read any of the captions, and if you can read the captions you'll only see at best a dozen boxes.
The thing is, we've moved on a little since TRS-80 BASIC. Modern programming languages are fundamentally the distillation of fifty years of lessons learnt; pretty much every language innovation: loops, conditionals, stacks, functions, and all the technology of object oriented programming, not to mention the functional stuff, is there to help us manage the awesome complexity. There are hundreds of books and a million web pages written on the subject: algorithms, object orientation, design patterns, refactoring, testing, the list is endless. A good programmer has to work really hard to keep up with all this stuff. But the result is that with the current state of the art we can do a reasonable job at keeping this horrendous complexity under control.
If you use a visual programming tool, you're throwing all this away. You cannot write anything other than a simple demo program with a visual tool. If you try you will fail.
There's one place where I think visual tools succeed and that's when they're used to represent static structure. I would much rather look at a data model in SQL Server's Database Diagram tool than trying to grep a long list of create table statements, and of course, it's far easier to work on a user interface with a graphical designer than by hand coding the construction and mapping of loads of objects. I actually rather like the class designer in Visual Studio. But I will never use a graphical tool to create program flow or logic.
Posts
