Illustrative Programming: I am a skeptic! (and I am not alone)

September 22, 2009 | 3 Minute Read
This post was originally posted on my old blog.

I have stated several times, that I don't believe in visual modeling and cannot share the enthusiasm that a certain branch of MDSD people have for visual modeling:

Now Martin Fowler is coining the Term "Illustrative Programming" in the context of Language Workbenches like IntentionalSoftware, which are tools to build "illustrative DSLs".

For a lot of people coming from the UML camp, the notion of a "DSL" is what Fowler is calling an "illustrative DSL" here. Visual Studio Domain-Specific Language Tools are a striking example of this.

In his article Martin Fowler quotes some opinions of Neal Ford about the concepts of Illustrative Programming:

I think these tools work best for lay people (thus, your link to LayProgrammers). However, in general, tools like this slow down experienced/power users. [...] I would much prefer a markup language I could use to directly define stuff, with macros, snippets, and all the other things I'm accustomed to as a developer.

As these tools grow, they get unwieldy (perhaps because they are ceasing to be domain specific enough?). [...] APIs in programming languages scale much better, with several orders of magnitude more density before they become hard to navigate.

All the best-practices and tools don't exist there: refactoring, levels of testing, etc. Also, you loose the connection to text, meaning that macro facilities either don't exist or complex one-offs. [...]

I share your bullishness around these types of tools, but they are a long time from being useful for full-bore Agile development. I hope they mature fast.

Reading these comments, I am having a deja-vu!

This is really expressing what I was feeling when I was involved in MDSD attempts in recent projects. I don't generally doubt the noble goals that the visual modeling camp believe in.

But the tools and environment are just not ready to provide value. At least not in that kind of mainstream real world enterprise projects I have been involved in.

Also in my experience, the target of illustrative programming is the developers, which is wrong!

As Fowler is pointing out, the goal of illustrative programming is to engage lay-programmers.
Developers need other tools than lay-programmers! So if there are no lay-programmers in your project, there is arguably need for illustrative programming...

This insight was always lacking when I was confronted with attempts at visual modeling.

It is a common mistake in a lot of projects to establish some kind of two-class society among the developers, in this case it could be tempting to degrade the second class to lay-programmers. But that is a sick environment to begin with (and the topic for another post)...