Jesper Boeg on Priming Kanban
In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.
News
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Is a picture always worth a thousand words?
Posted by Niclas Nilsson on Nov 08, 2007
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.
A beethoven piano sonata worths 1000 pictures ....
by
Ke Jin
Posted
visual programming will come eventually
by
ding jack
Posted
Graphics for structural representations
by
Stefan Wenig
Posted
Re: Graphics for structural representations
by
Niclas Nilsson
Posted
DSL and XML first, visual programming second
by
Raphaël Valyi
Posted
Lineair text presentation versus spatial presentation
by
Jan Vegt
Posted
Code is text
by
Magnus Christerson
Posted
-
Without clearly defining what means "worth", what is the specific communication background (i.e. context) ... this kind of statements could only be taken at their face value. Human communication is evolved from pictures (prehistory) to words/languages, not the reverse ....
-
im wondering why case tools like ROSE just do not provide procedure define function. otherwise we can generate entire code than only empty function definition.
-
Visual models have proven very useful in some cases. Take UML's static class diagrams, for instance, state diagrams, or even workflow as flow charts. In some cases, even roundtripping to code/DSLs/XML/whatever is painless (UML-like class diagrams within the target language's type system).
Whatever visual representation you use, there has to be a textual representation that you can read and edit. For understanding, troubleshooting, generation, version control, you name it. But if roundtripping works, and if the visual model provides additional value, why not.
Still, the designer-happy crowd that tried to make us think that you don't have to know programming in order to create non-trivial applications, is running into walls everywhere. It's about time the industry recognizes that this has been a wrong path from the beginning. In most cases, pictures are just a good way to get a good overview and navigate your code, but when you drill down into the details, it's still code.
Just compare blogs about programming to blogs about using visual tools. The code blog will tell you, that in order to achieve this, here's these few lines of code.
The visual guys will be busy for days creating lists of steps you have to perform and creating snapshots, testing if this really works, etc. Just to produce a blog entry that takes the better part of an hour to comprehend. If this is not a clear indicator, I don't know what is. -
sure, DSL should come first, visual tools come second. Visual tools may not allow enough expressibility but are great ways of communicating.
Simple and most portable DSL are better done as XML dialects while scripting (say Ruby) DSL are way more expressive and powerful but are harder to implement in different ways and plug with different tools.
XML DSL are also easier to plug with visual modeling tools.
I think we should mix strict XML DSL's with more expressive scripting parts. I like the way for instance JBPM addresses it by supporting scripting inside its XML. Thus you get the Eclipse visual editor but don't loose the power where you need it.
Google Mahup Editor is taking a similar way even if their is no visual tool yet.
In any case, IMHO, the worst situation is when either
* the DSL is so dependent to tools and languages that you are tied with a vendor lock in
* the visual modeling tool has been done before thinking about a simple and published DSL allowing the portability.
Raphaël Valyi -
I didn't include one idea that I was thinking about in the post, but maybe I should have.
Image having an IDE that would allow you to navigate from the highest abstractions down to the tiniest details with speeds like Microsofts CDragon technology.
Granted, CDragon does not change the type of representation when it drills down, but imagine a tool that could? At that speed...
Kind regards
Niclas Nilsson
---
blog: niclasnilsson.se -
One of the problems not yet mentioned is that textual programming languages have a sequential, lineair order. Given the Western domination into programming languages exclusively or almost exclusively in a top-down, left to right fashion.
A visual, spatial programming language has the challenge of not only coming up with an understandable and compact set of symbols, but also presenting these symbols in a uniform way. And with very little history or tradition - like there is with text writing - to make this a familiar experience to a larger audience.
Marten, a ProGraph IDE by Andescotia software, is one of the few visual language environments still around and I think it's pretty coureagous effort given the fundamental challenges of visual programming. www.andescotia.com/
[ I have no affiliation with these guys but think they deserve credit for the effort ]
Cheers, Jan -
Niclas - you are right. Code and pictures can be different projections of the same underlying code model. As long as we store programs as text in the syntax of the programming language we are screwed. That means we will never have the freedom you talk about. But if we separate the storage format from the syntax, we are golden. Then we can have both text in the syntax of the programming language AND pictures, both as editable projections from this same model.
7 comments
Watch Thread Reply