Occasionally, I still run into development tools which sell people on the idea of visual programming.
There are particularily prevalent cases in the enterprise world which typically sounds something along the lines:
This tool allows architects to draw a domain model using diagrams.
The diagrams are translated into source code skeleton for developers automatically.
Multiple languages are supported as the output: C++, Java, SQL, …
If this source code is ever assumed to be updated by developers manually, the approach will likely fail…
… unless the issues discussed below are thoroughly addressed.
Visual Programming versus Visual Presentation
I want to emphasize the difference between directions of conversion:
-
Visual Programming - the WRONG approach
-
Source: manual visual diagrams
The visual diagrams are modified via special visualization software.
-
Result: generated source code.
The text files with code are still normally generated to provide input for a compiler.
-
-
Visual Presentation - the RIGHT approach
-
Source: manual source code
The source is the code (hence, the “source code”).
The source code is modified via text files (using any text editor).
-
Result: generated visual diagrams
The visualization of the source code is done by various tools.
For example, IDEs may draw class diagrams or dependency graphs.
-
These are essentially two different directions on the same two-way road.
And the road should only be one-way!
I warn specifically against the impractical 1st case. Why the 2nd case only?
-
Practical benefits rooted in the fact that most software is written/read in code (text).
-
In turn, using code is motivated by its immense flexibility and support from wide-range of easy to implement tools.
What’s wrong with visual programming?
The mess and inconvenience introduced by visual programming tools defeat the benefit of seemingly more illustrative diagrams they provide.
It is one-way the wrong way
The first problem is that visual representation goes the wrong way: the diagrams are the “source”, and the code is “destination”.
Any manual change of generated code will be overwritten with the next change of a diagram.
And this wrong way of update direction is often the only way!
Can you load existing code into visual programming environment?
It often couples presentational layout and implementation data
This issue alone makes life miserable. The (noisy and frequent) graphical layout changes are indistinguishable from changes in implementation.
This is similar to whitespace changes in text files, except that you may not be able to tell them apart due to a possible binary format of the produced artifact (see next).
It often uses binary formats and integrates poorly with other tools
Entire spectrum of tools are plug-able into the text processing infrastructure:
- text editors,
- revision control systems,
- text processing tools,
- static code analyzers,
- …
How does a visual programming tool fit in here?
Are you able to take any tool of your choice to analyze “diagram sources”?
Even in cases of open text-based format, it won’t be convenient for consumption because the produced artifacts were not meant to be looked into directly without rendering them in the visual tool.
It can hardly provide change review
For example, how to compare differences between two spreadsheet files?
--- hello-world.sh 2016-06-02 13:54:13.910585354 +0800
+++ hello-world-file.sh 2016-06-02 13:53:31.174356629 +0800
@@ -1,4 +1,4 @@
#!/bin/sh
-echo Hello, World!
+echo Hello, World! > file.txt
If you cannot clearly see changes between versions, the confidence of making steps forward will be drastically undermined.
Think again: if you don’t know what has changed, you must be concerned.
By the way, how do you quickly send bits and pieces of the solution “written” in visual programming tool to a remote peer for review? Text is immediately copy-and-paste-able (diagram screenshots are not paste-able).
It is not flexible enough
The visual programming tools will crawl behind possibilities achievable with the combination of components working on “standard” text.
For example, does it allow regex search of attributes or comments within diagrams (or you have to wait for the next release)?
Moreover, such tools may incur lots of mental pain with every change in their own GUI layout. A new layout is like a new town - everything has to be rediscovered again. Also, experience inevitable bugs with such over-responsible software.
It does not scale well with details
Visual programming is not allowed to hide details. In fact, it may even expose more of them.
It needs to hold all required details to generate necessary code! Otherwise, it can only be used to create a skeleton for a prototype - irrelevant for product development.
If it generates database schema based on diagrams, how sure are you about controlling every fine-tuned piece of SQL?
Just imagine visualizing every detail of any project source code. Isn’t visualization supposed to hide unnecessary details and be limited to a particular context?
It lacks mindshare
-
Is the tool’s knowledge wide-spread and generic?
-
Is it commonly adopted?
-
Or is it something the Internet knows nothing about?
Due to limitations explained above, answers to the questions are usually negative.
Living examples
All the visual design tools developed for website design in the past are currently not popular anymore.
Modifying HTML/CSS directly and reviewing result in the web browser is the most common implementation process among designers!
Just compare it to the most of the examples of popular software related sites and blogs. Will you be able to communicate details in answers and comments on StackOverflow as easily as the text can do?
Conclusion
This post is a warning for those who choose tools for next projects at the current state of things.
Visualize software on whiteboards or documents outside of the code.
Keep code the ultimate source. Derive from it, visualize it, not vice versa.
Visual programming approach will only get you started (with a prototype). Instead, choose tools which keep you going.