Recently I had the opportunity to use a graphical programming tool. The problem was to automate an industrial process, and what could be better than a flowchart-like tool? is apparently what the pioneers thought. The tool had been used on several other units, with varying "success". This means I had legacy code to start with. While this certainly does not speak for other tools, and of course the legacy code had a hand in the experience, I want to document here some of the horror-ful experience.
1. The tool turned out not so well-suited for the problem domain. The industrial process in question here was not linear like we initially thought. It couldn't be described simply using one or two flow charts, we had to use TEN. And about six of them would be running in parallel; there was no way any person would monitor six flow charts on one screen at once over eight hours, no?
Mitigation: I implemented a crude mechanism (lucky me the tool supported strings) where each flow chart would output its status on the main screen regularly, like "Cannot perform [action] due to [reason]" or "Step 16 completed, starting with Step 17". I'm surprised it wasn't done earlier.
2. The final code had to use internal boolean flags as a form of inter-module communication. To make things worse, some of the flags were stored externally across the network. Enough said.
3. GUI getting in the way. And I really mean it! An if clause takes probably 3 seconds of typing in a text editor, and your hands did not have to leave the keyboard. This particular tool required 1) dragging a block from the palette, 2) double clicking on the block to bring up the configuration dialog, 3) typing in the test conditions, 4) create downstream blocks, 5) click and drag lines to connect the blocks, and finally 6) right clicking on the thin lines to specify true/false directions. Wow.
Furthermore, the agreed solution to this particular automation problem is basically a bunch (30? 40?) of if-then rules.
4. More GUI getting in the way. One of the plus points of graphical programming is that it would be self documenting and be easy for non-programmers to figure out what it's doing. But this particular tool has no auto-resizing for the blocks! An if block with more than one condition requires manual click and drag resizing so that the conditions would be visible on a printout. Good grief.
5. Parameter declaration and scoping is a mess. For a member to inherit a parameter, the parameter had to be made global, which means the parent can read/write to it too. And you can actually mistype something and it automatically becomes another variable. (Option explicit is hidden in the menus, you need to manually tick it every time before the build.)
6. Functions start in a separate thread concurrently by default. In other words, you cannot "call" a function and wait until it returns before moving on to the next step. The only choice is to 1) adding custom logic (and more global variables), or 2) make a copy of the function and place it right in the middle of the execution path. I think (2) defeats the purpose of having a function. Even to do (1), the function must be "initialized" every time before it is called - more blocks and unnecessary complexity.
7. Nested procedures. This is more of a legacy code issue. There are so many levels of nesting, navigating the code is actually tiring! There is no way a person without insider knowledge can understand what the legacy code does by just looking at it, which is rather absurd because the point of graphical programming is certainly not to increase obscurity.
Ok, that's enough, I think seven will do because today's Sunday. To be fair, I must say that there are some strong points of the tool that I really appreciate as well. For one, it has a full audit trail, and every action is logged. Second, it supports online tweaking and debugging, which is crucial for unusual situations that may turn up every now and then.
But then again, these are things which should be a given nowadays...
No comments:
Post a Comment