What do Autonomous Driving and No Code Platforms have in Common?

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.

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.

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:

1. Eliminate expensive labor (software developers)
2. Where it can’t be eliminated, replace that expensive labor with less skilled, less expensive labor (non-software developers, in general)
3. 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!”)
4. Introduce the idea of “Citizen Developers” who will run around your organization building new applications that you didn’t even know that they needed.

I argue that the goal instead should be to help developers be more effective and productive, rather than looking to replace or eliminate them. If we focus on solving key challenges for developers, we’ll end up with better software, better developers, and faster results. Eliminating developers entirely is rife with risk and expense.

Why do I have this thought process? We can look to autonomous cars for some guidance:

1. The complexity axis actually matters. Like fully autonomous cars, No Code tools are generally good at 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.
2. If you try to solve a problem that is too complex, with a No Code tool, you will typically end up in what is called “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.
3. 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.
4. The business applications that are referred to by LC/NC analysts are often quite 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! The best LC/NC platforms will offer a seamless blend of complexity solved with code and simplicity provided by good user design.

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 to be done is making developers more productive

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 — 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…

Last year 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 last year (and moving to NYC in 2023 in just one week!). We talked about Camunda 8, Partnering, creating impact for our clients, and other topics!

Hope you enjoy the conversation as much as we did!

Originally published at https://sfrancisatx.substack.com.

Scott Francis is CEO and Founder at BP3 — where we focus on process as the lens to drive business value: because if your business matters, your process matters.