Visual Programming Is Unbelievable… Here’s Why We Don’t Believe In It
Visual programming has been an unfulfilled prophecy for years. As with so many other things, like virtual reality, artificial intelligence or speech recognition, when the hype was high, the underlying technology wasn’t there yet.
But that was not its only problem…
Several Misfires
For visual programming, the hype peaked in the early 90s with CASE tools. And, as with all trends ahead of their time, the repercussions of its failure were years of underinvestment, little innovation, and lingering skepticism.
UML (Unified Modeling Language), with its promise of bringing sanity to object-oriented programming, hasn’t helped either, although much of its faults were due to the underlying complexities related with inheritance.
And even more recent trends, like Business Process Modeling, probably did more harm than good to the credibility of visual programming.
No Silver Bullet
In his seminal No Silver Bullet paper, Fred Brooks stated that there is no single development which, by itself, promises one order-of-magnitude improvement in productivity, because technology complexities would decrease, but requested features would not.
Like Moore’s law on hardware, the first part of that sentence proved to be prescient almost 30 years ago. What Brooks might have missed is that this would make room for too many directions in software development, often making us move in circles, instead of forward.
An example is the explosion of the number of languages, idioms and practices, sometimes with opposite approaches (e.g. strongly/weakly typed, client-server/server, all the different new JavaScript frameworks, etc…). Non-functional requirements, like scalability or security, and new expectations, like mobile and user experience, have only made things harder.
All this complexity opens space for an approach that would allow developers to focus more on delivering real value. Visual programming, with its higher level abstraction, could be the champion for this approach and become the productivity silver bullet we’ve been looking for.
So why hasn’t it yet?
Because visual languages have a fundamental set of problems.
Visual Languages Aren’t Extensible
This is probably the capital sin of visual languages. They allow you to do a limited set of things easily, but edge cases are far too difficult, or even impossible to achieve. Tools should give us more power, instead of limiting us.
Visual Languages Generate Slow Code
Every developer who has faced performance problems knows how hard they are to diagnose and overcome. Visual languages are leaky abstractions, often generating slow code which is impossible to optimize.
Visual Language Tools Can Be Terrible
We live and breathe in our IDEs (integrated development environments). When they are poor, they can make our lives miserable! Visual languages and IDEs should be designed together: our love or hate for a language is a direct measure of our love or hate for its tools.
Visual Languages Lock You In
Any technology decision brings a level of lock in. The fear of being locked into a dead-end is justifiable, given that most visual languages generate unreadable lower level code, only target niche segments, are supported by suicidal startups, or haven’t left the research lab yet (where amazing recent work, like Bret Victor’s, is being done). Real success stories, of people using it in large projects, are still rare, and these communities are still growing.
You Are Neurologically Programmed to Reject It
The problems in the previous sections are serious and, as visual language architects, we know it’s our responsibility to continue our work to address them, removing these limitations.
But there are deeper reasons why you don’t trust visual languages:
The first is related to our love for complexity. Although we might say otherwise, we all do, according to the father of usability, Don Norman. Take musical instruments, for instance: musicians love them because they are hard to master. Think about legislation. Or even language: most poetry is hidden under complex sentences and words. We love the intellectual challenge of thinking difficult thoughts. Your mind is probably doing it right now, agreeing with these ideas, or checking if there is anything wrong or missing in them.
We need, however, to be careful with this, as we create deep moats against the rest of the world, and that brilliant xor swap algorithm I’ve coded today may be somebody else’s nightmare next year.
Like Steve Jobs said: “Simple can be harder than complex. But it’s worth it.”
The second reason is even more primitive: it’s fear of change. We take the time to acquire some expertise, and suddenly it seems our old weapons are no longer needed. But we’re seeing it wrong: our weapons are not to be able to do a malloc, or pointer arithmetic; they are to be able to divide a problem into smaller parts, to understand the process of iterating until we reach the solution, to detect strange code smells, to discuss a diagram on a whiteboard, to refactor systems into better architectures.
Those are our real weapons, the ones we’ve been sharpening for years, weapons that, with higher level languages, become even more deadly to any problem that might cross our path. Fear not: a great developer will always be more valuable than any tool he works with.
And let’s face it: there’s also social acceptance. We were here first, we bought the debut albums, we’d never be caught listening to the sellouts that make it easy for everyone.
We’ve Been Here Before
Because of these instinctive reactions, anything that aims to democratize computing is met with skepticism. HyperCard, Delphi, Visual Basic, COBOL. We, the “real” developers, are too quick to point out their faults, and mock them with no mercy until they die, instead of helping them improve. Even JavaScript almost had that same fate during the DHTML days.
There is, however, an analogy that might better show us the future: The shift from text operating systems, like Unix and MS-DOS, to graphical user interfaces, like Mac or Windows, which suffered pushback from several computer experts at the time.
That evolution, which seems so inevitable today, brought us better graphic cards — which lead to better games, brought us the world wide web, brought us smartphones.
Can you imagine a world without these unbelievable things?
So, Are We Finally Ready For It?
Not sure: you may not, or you may feel we’re not — it’s fair either way. But try to understand your biases, and don’t be afraid to give visual languages a shot: there are several organizations like mine, in different domains, challenging the way software is traditionally delivered, and pushing forward the state of the art.
And even if, after trying them out, you still don’t see the bright future of visual programming, that’s fine: consider keeping an open mind and come back later, otherwise you might just end up in the wrong side of history.
Originally published at www.outsystems.com.
