This post, which will shake up your idea of black boxes (and the much-maligned Pandora), is the second in a multi-part series that examines why developers like me have negative reactions to low-code platforms. If you’re a completionist too, you will want to read the first one before you continue: Why Your Team Won’t Low-Code: Job Loss.
After reading the previous post, your team’s feeling of dread has subsided. They don’t believe that they’ll lose their jobs or value as software professionals to low-code platforms. It was a close call, though, since low-code platforms replace much of the work they do for cheaper and faster than they’ve ever done it. Oooh, how spooky that was 👻!
They’re brave and willing to marginalize that fear as a byproduct of their lizard brain that says, “Familiar is safe. New is scary!” But then they look at this low-code thing:
Developers have one of two reactions to these low-code WYSIWYG editors. The first is, “OMG, look at how quickly I can do X!” That’s someone who understands the value of time and appreciates the beauty of abstraction.
The other and more prominent reaction is, “I wouldn’t trust this to run my toaster.” Unlike the previous fear of job loss, this one has merit. Personally, I was in group A – the group that I so graciously praised a moment ago – because I’m a trusting person and I enjoy self-praise.
Those Evil, Treacherous Black Boxes
But when I talk low-code with developers, they assure me that these platforms are treacherous black boxes from hell. And they can’t afford to run mission-critical services on something over which they have no control.
This logic seems sound – at first. And in keeping with the theme of these posts, I will explain why this fear is irrational.
Same Old, Same Old
True of OutSystems, and likely true of its growing list of competitors, these platforms run on the familiar stacks developers have come to know, love, despise, and love again.
Admittedly, OutSystems runs on top of AWS. And they compile visual code to native .NET or Java. No, they don’t rely on proprietary visual runtime environments to execute drag-and-drop code on the fly.
This lets developers append existing server scripts to their low-code deployments, and that’s a feature touted by rivals as well.
On the front-end, OutSystems doesn’t impose any strong opinions on the developer. In their case, the only de facto library bundled with each page is jQuery – heaven forbid. I can’t speak for other options here, but it’s likely that competitors follow suit.
We Rely Heavily on Black Boxes
This point doesn’t refute the original argument, but your team may find it comforting to put black boxes into perspective. Java and its sister languages Scala, Groovy, et. al., rely on developers’ most popular black box of all: the JVM. So why trust the JVM and not low-code? Time.
When first introduced, the JVM also received heavy scrutiny from the developer community. But after seeing it work repeatedly year after year, trust grew. Developers understood that Java and the JVM were sticking around for a bit and Oracle would continue to support both.
I have no clue how Oracle executes my bytecode, but I trust it implicitly. And if I exclude the Android platform, I am effectively locked-in after I build a project in one of these languages. And I can’t leave out the other famous black boxes I rely on: Windows, OS X, registries like npm and maven, etc.
And I need to call my Open Source dependencies what they truly are: “tinted windows.” I’m talking about Linux, Ruby on Rails, Ruby itself, and a whole host of other libraries that contribute to my stack. I may have access to their source code, but if I had to dig in and discover the cause of a rare issue, it would require exceptional effort to find the problem, and even more to patch it.
In the grand scheme of things, developers trust plenty of black boxes and hundreds of tinted windows. Adding one to this list, from a morally relativistic standpoint, is painless. Especially one as old and reliable as low-code. Yup, low-code platforms like OutSystems have been around for quite a bit and they’re finally getting noticed.
That’s two down; are they still getting low-code feet?* Let me know in the comments.
*The pun that refuses to die.
Next post in this series: Why Your Team Won’t Low-Code: Oh Code You Didn’t