What do Autonomous Driving and No Code Platforms have in Common?
They both are framing the discussion with the wrong question
There’s a connection between Autonomous Driving and No Code platforms… and it has to do with how they think about people.
In the No Code world, it is:
“How do we eliminate the need for software developers.”
And in the autonomous driving world, the framing is:
“How do we eliminate human drivers of automobiles.”
I want to discuss why each of these misses the point.
Autonomous Driving and Human Drivers
For many years now, startups and giant tech companies alike have pursued the dream of fully autonomous driving. And it turns out, to do that, we need for the autonomous drivers to be better than humans in every way, at driving. It isn’t enough to avoid the countless minor mistakes that humans make. Our autonomous drivers must also avoid the catastrophic mistakes that humans are unlikely to make (that have resulted in self driving cars plowing head on into trucks and road barriers - and pedestrians). We also have to solve the trolly problem - the age old balance of pre-determining the lesser of two evils, vs. just accepting that a human in that situation does the best that they can in the moment, with no predetermination.
It also turns out that autonomous driving algorithms were really good at the easy stuff first. Lane detection, braking for the car in front of you, etc. But not so good at solving complex problems (construction zones come to mind).
But think how differently autonomous driving might have progressed if we framed the challenge as “making human drivers more effective drivers.” All of that AI power utilized to help detect when humans are inattentive, to detect when there are hazards ahead that human drivers are unlikely to perceive; or to help humans drive better in challenging conditions, in limited visibility conditions, or in slick conditions- these are all things we could teach computers to assist humans with.
If we framed it as how to make human drivers better, we could achieve major strides in safety without having to wait for 100% replacement capability.
No Code and Software Developers
Remember that the framing in No Code software vendors and their proponents is:
“How do we eliminate the need for software developers.”
It’s important to understand the motivation behind these no-code movements:
Eliminate expensive labor (software developers)
Where it can’t be eliminated, replace that expensive labor with less skilled, less expensive labor (non-software developers, in general)
Make their software product look more attractive by minimizing the skills and quantity of the hours of labor/effort it will potentially save. (“you don’t even need to be a software developer to do this, it’s drag and drop!”)
Introduce the idea of “Citizen Developers” who will run around your organization building new applications that you didn’t even know that they needed.
The first thing I’d point out in the market is that the no code folks always express it as “Low-Code/No-Code” or LCNC. Why do they do that?
“the dirty secret is that all of these no-code platforms do, in fact, require some code to be written”
Because the first dirty secret is that all of these no-code platforms do, in fact, require some code to be written. So the next thing you do is minimize how much. But why is that the case? Why do these “no code” platforms actually require “some code” (therefore low-code terminology)?
Look no further than this image, shared by John van Der Draai - and note that there are quite a few other charts showing similar things. John runs a company that leverages No Code or Low Code platforms to build his business.
But there are a few problems with this chart:
Notice there is only a horizontal axis label - “skill required” - increasing from left to right.
Notice that there are no definitions of these levels - No Code, Low Code, and Full Code. What do they mean? Exercise for the reader. Does it mean that full code solutions cannot use any low- or no-code tools?
There’s an implied, unlabeled, vertical axis. I wonder what that might have been in the original incarnation of a slide like this… I can imagine it might have been “complexity required” to solve the problem… And then this chart implies that No-Code is a good fit for simple problems with little effort. That’s perhaps a reasonable conclusion.
Invariably vendors will position their product as the new true no-code solution - all solutions that came before having failed to deliver on the promise of no-code (or are represented as dinosaur full code solutions, regardless of how much low-code candy is provided).
In a followup, John says “key message you don’t need slowcode developers for developing a business application. [..]” So you kind of already get the sense that the argument isn’t entirely on the merits.
What’s Wrong with the Story?
There are a few problems with this thought process, from my perspective:
The complexity axis actually matters. Like fully autonomous cars, No Code tools are generally only good at really simple problem solving - an approval screen, for example. It calls into question whether No Code tools are really providing any value if the problems they can solve are inherently easy and not that valuable.
If you try to solve a problem that is too complex, with a No Code tool, you will typically end up in what I call “property sheet hell”. You end up building something more complex - without code - than you would have - with code. You’ve fallen into the golden hammer trap (everything looks like a nail when you have a golden hammer). Solutions built like this end up being an albatross around a business. I’ve often heard them referred to as cargo cults by CIOs who lose patience with them.
Once you introduce code (Low Code!) to the solution, you’ve introduced code. Now your “non software developers” need to be comfortable writing JavaScript or other code artifacts, sprinkled throughout the solution. So you’ve lost your first line in the sand of “business users writing their own applications.” You need people with real technical expertise - and specific product expertise - to do the job. But - usually how that low-code is sprinkled in is not tightly governed - so you can pull in a massive amount of complexity without realizing it.
Apparently the business applications that are referred to by LC/NC advocates are super simple. But “a solution to the problem should be made as simple as it can be - but no simpler.” Sometimes business challenges are complex, and require more than simplistic solutions. In my line of work I’ve seen lots of necessarily complex challenges, and it is part of what makes this line of work so fun and rewarding - helping you find a faster way to solve problems they previously thought were intractable!
Low Code and No Code are not New Ideas
Finally let me address the idea that Low Code and No Code are new ideas in the world of enterprise software. I assure you that they are not, and let’s take a few examples from memory lane:
An early No Code example is HyperCard on the original Mac operating systems. It is probably one of the best examples of what good No Code application building could look like. Even today you see solutions patterned off of HyperCard, like Decker.
Drag and Drop UI-Building was considered Low Code in its time (and still should be for what it does). You would drag the user interface components onto the canvas and when you ran your application, as if by magic they would appear in the right places. Examples: Visual Basic, NeXT’s Interface Builder, Delphi, IBM BPM, Pega, Appian, Mendix, Outsystems, and many others.
Later versions of these UI-builders took it further - if you dragged a data object (variable or reference) to the canvas, it would pick the likely correct UI element to drop onto the canvas, and it would connect that UI control to your data element so that edits would pass through from UI code to the server-side status. (At least one example of this is how IBM BPM supported UI Building).
We wrote our own UI framework at BP3 that allowed for writing one application for any platform, that actually looked good on all of those platforms and screen sizes. Write once, run anywhere so to speak - and it was mostly drag-and-drop Low Code, inside a Low-Code platform…
Drag and Drop process-mapping, process-orchestration, and process-documentation products introduced Low-Code for building and modeling processes. These really came to prominence between 2004 and 2015.
Enterprise Application Integration tools that introduced drag and drop integration points rather than requiring you to write code for the integrations. This category definitely hit on some of the Low Code limitations.
Software builds have gone from things that are heavily coded to things that are heavily configured (Lower-Code if I may say so).
Robotic Process Automation vendors are offering Low Code or No Code ways to emulate human work for filling out forms, pulling data, collating data, reporting data, and integration.
I’m waiting for someone to release a new rules engine and claim that the idea of a rules engine is new in the world.
When you take account the arc of history, the job isn’t getting rid of developers entirely, and it isn’t getting all the jobs done with one master tool.
The job is making developers more productive! Increases in productivity would include things like - fewer defects, leveraging well-tested components, assembling components rather than writing from scratch, and being able to write new well-tested components that fit in.
That pragmatic approach - of making better tools for the jobs in front of you - feels more true to what leaders in the Process Orchestration and Intelligent Automation markets are doing today. The pragmatic approach is more true to what is needed by you, to solve high-impact problems.
My goal isn’t to replace software development and software skills on our team (or in our clients’ teams). My goal is to arm our teams with the best tools for the job they do, so that we can be productive and reduce friction in our work! We focus on high-impact solutions for our clients, and anytime we reduce friction we’re improving the quality of our work.
My goal isn’t to stop driving my car either. It’s to be so effective when driving that the probability of an accident or damage is dramatically reduced.
If we simply orient our goals toward allowing people to perform at higher levels, rather than trying to replace them, we’ll achieve better outcomes.
If you’re wondering whether you should adopt a new tool - low code/no code or otherwise - refresh the criteria for choosing these tools here: what thing does this tool make easy, that used to be hard?
One more thing… Video Interview…
Recently I sat down for an interview with Jakob Freund, CEO of Camunda. It was really fun to talk about our shared journey in process - and how we are now really impacting the way businesses are run.
Jakob and his team have built something really great at Camunda, and we put this edit of our interview together in preparation for CamundaCon, which by all accounts was a great conference in Berlin this year (and moving to NYC in 2023!). We talked about Camunda 8, Partnering, creating impact for our clients, and other topics!
Hope you enjoy the conversation as much as we did!
Interestingly, I ran across this article on Apple News / Washington Post over the weekend:
https://apple.news/AzoFbX9q0T8mEOQ9m6rdHNA ("The tech CEO spending millions to stop Elon Musk")
The short version is that he believes full self-driving mode is not safe, and that it should be stopped until it is. And he does a lot of testing to back up his claims. It's a cautionary tale, aligned with my own view that we really should make humans better drivers, rather than replace them as drivers!