Is a picture always worth a thousand words?
In his recent article, Why we write code and don’t just draw diagrams, Dean Wampler argues that in software development the opposite is more often true.
Advocates of graphical notations have long hoped we would reach the point were we only draw diagrams and don’t write textual code. There have even been a few visual programming environments that have come and gone over the years.
If a picture is worth a thousand words, then why hasn’t this happened?
There are not many graphical programming environments that are widely used, but there are exceptions. Labview is possibly the most well known one, but it is primarily used by testers (and kids with cool Lego) - not traditional developers.
Why is that? Likely because there are a lot of details to take care of in software development. This makes it hard to create visual languages that can represent such complexity without overwhelming the reader. If we represent programming constructs as pictures, we need to map these pictures to an (often) abstract concept to be able to understand what it means. The hard part is to not end up in a classic trap. And since we talk to other developers, we do need words for everything in any case.
Dean writes:
Well, couldn’t we still do that with a sufficiently expressive graphical notation? Certainly, but then we run into the pragmatic issue that typing textual details will always be faster than drawing them.
I came to this realization a few years ago when I worked for a Well Known Company developing UML-based tools for Java developers. The tool’s UI could have been more efficient, but there was no way to beat the speed of typing text.
However, this all depends on how powerful abstractions you have created in your code. Poorly done, you may need a thousand words to represent what could be said in one picture. And you or your colleagues need to decipher that each time you read the code.
The current Domain-Specific Languages movement explicitly focuses on this point:
It’s also true that some languages are rather verbose. This is one of the ways in which Domain-Specific Languages (DSL’s) are going to be increasingly important. A well-designed DSL will let you express those high-level concepts succinctly.
Dean refers to textual DSLs in this case, but companies like Metacase creates tools for designing visual modeling languages and Microsoft took a similar route when they developed tools for creating graphical DSLs to accompany their Software Factory vision.
Arnon Rotem-Gal-Oz describes the limitations of graphical DSLs like this:
Unlike small code based DSLs - the modeling based approaches of software factories, MDA etc. aim too high and thus provide much less value or suffer too much from the generation gap (the code generated is too generalized or far off from the actual need of the solution).
Arnon also has explicit comments on if a picture is really worth a thousand words:
This is true if you treat models as sketches you can raise the level of abstraction by as much as you want and convey ideas with less clutter. However when you need to make the model very specific so it would allow code generation - you get to a stage where it is more convenient to do it in code and rely on generated or pre-built DSL or framework
Ironically, pictures can be a good way to grasp a complex code base. InfoQ recently published an interview with Erik Doernenburg on Software Visualization, where Erik explains ways to visualize different aspects of for instance a system or a code base. Using visualizations, it is possible to quickly spot anomalies that would be hard to find otherwise, but that is still a different thing from creating software graphically.
Dean concludes by explaining that he doesn’t imply that there is no place for graphical representations, but:
Still, for the general case, code written in succinct languages with well-designed API’s and DSL’s will trump a diagram-driven approach.
On the other hand, Intentional Software will tell you that code or pictures are just different projections of the same underlying model.