Why Developers Fear Low-Code

Are your developers wary of low-code platforms? Do they fear low-code tools will replace them? I know where they’re coming from. In mid-2016, I evaluated the upcoming mobile-focused OutSystems 10 release as a native Android and iOS developer. I knew little of web development and nothing of low-code platforms.

As I slogged through tutorial after Portuguese-accented tutorial, I realized I was creating complex products without so much as a blink. And this tool was significantly easier to learn than traditional software development. Creative potential began to flow through me. A platform this powerful could accelerate the development process, bring products to market at startling rates, and replace—me!?…

Fear Replaces Excitement

My fears were fueled by three additional factors:

1. OutSystems raised $55 million a few months prior; the industry was growing, possibly leaving me out in the cold.

2. They were about to release native mobile capabilities—my specialty.

3. Civilians could learn SQL, then learn one of these tools and boom, there goes my job.

Those thoughts coalesced into a brief but real panic. After a few discussions with key OutSystems employees, I discovered errors in my logic. Here’s why low-code will never replace me and does not intend to. Use these arguments to assuage your team’s low-code fears and keep them from getting low-code feet. Cold feet, get it? Forget software, I’m going back to comedy.

Low-Code Is Just a Tool

Unlike the impending A.I. apocalypse in which software ultimately writes itself and subjugates humanity, low-code is merely a tool. And a tool’s value is derived from those who wield it. In the unlikely scenario where the majority of software is built on low-code platforms, developers will make the best low-coders. Yes, you can hire Johns and Janes to build low-code apps. But without requisite software fundamentals, their capabilities will only carry them so far.

OutSystems provides access to custom JavaScript, advanced SQL queries, and C#/Java integration. That allows seasoned developers to go the extra mile if the visual aspect of low-code fails to meet requirements.

More importantly, developers understand the fundamentals of software, computer architecture, the web, and more. That knowledge enables them to work faster and optimize the platform leaps beyond the Johns and Janes. Sorry, J-people; it’s nothing personal.

Low-Code Can’t Abstract Everything

I remind myself that some poor soul out there somewhere writes assembly code for a living. If you know someone like that, have them call me if they ever need to talk. But we don’t have to dig to assembly-level depths to find software patterns that low-code cannot abstract. By running natively on iOS and Android using a WebView pattern, the web-focused low-code developer has limited access to device APIs and platform controls.

For example, it’s currently impossible to implement an Android live wallpaper or iOS lockscreen widget using the tools provided by OutSystems. If you require access to nuanced native APIs, low-code alone will not cut it. Low-code enables a large body of use cases and business processes. But like screwing a lightbulb with a ball pein hammer, low-code isn’t right for every job.

Low-Code Is a Black Box

So low-code won’t replace developers, but that revelation won’t exactly turn them into fans; especially when they first lay their eyes on this 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 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.

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 appears sound—at first. And in keeping with the theme, 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 Box Solutions

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, and others 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, 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 might 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 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.

It’s Not Code

I’ve crumbled the threat of job loss and pulverized the fear of black box solutions. So, what’s left? The fear of losing passion surpasses them all. When developers leave the office each night, they walk out with their skills in hand.

Some are perfectly content to leave those skills unused until the sun rises again. But the rest, those passionate hackers, they claw their way to personal time in which they tinker with side projects. They patch open-source code; they learn a new framework; they answer questions on StackOverflow.

They love coding because it solves complex problems, builds products out of thin air, and is the alchemy of our modern age. And their skills imbue them with power and respect. Low-code threatens to eradicate their status.

One can learn low-code development in a fraction of the time required to master software engineering. To accept one of these platforms as their primary tool is to take a cut in prestige. And these platforms solve the majority of complex problems in advance: load balancing, resource allocation, encryption, and others. That leaves them with precious few hurdles to overcome in their day-to-day lives. So what do I say to this?

Coding vs. Low-Code: There’s No Getting Around It

For a growing number of business concerns, low-code is the way forward. It’s a streamlined development process faster than any that’s come before it. Why is speed so important? Businesses need to change at a rate that can keep up with competitors, vendors, and the modern consumer’s fleeting stream of impatient desires. How can business do that while sitting on a cache of legacy software that upgrades at a snail’s pace?

Code is the bottleneck now. It’s an arduous, slow task prone to human error. And in my experience, there’s an exponential relationship between the speed at which an engineer writes code and the number of bugs they introduce. So coding faster is not a viable option.

The Big Picture: It’s Not Just Coding

If you force your team to work in a low-code environment, they won’t abandon ship—at least not immediately. Those passionate developers have families to feed, roofs to keep over said family’s head, and debts to pay off. But are you prepared to deal with a discontented workforce just to save a few bucks?

Personally, if I had to work in low-code all day, I wouldn’t mind. And that’s because I’m a leader, not a developer. And I use the term leader as defined by Robert Steven Kaplan in his book, What You Really Need to Lead, which I discovered in his Harvard Business Review piece, To Become a Leader, Think Beyond Your Role.

Kaplan believes that leaders look at the big picture, and as the title suggests, beyond their role in the organization. Leadership isn’t limited to those in leadership positions: everyone can and should participate. The big picture developers need to see is that they don’t, “solve complex problems,” “re-factor solutions,” or, even “hack,” What they do is ship products.

And I believe the pride in this work should originate from the people whom it most greatly affects, not the work itself. I’d rather have a low-code base with an endless stream of satisfied users than my own hand-written, proprietary source code coupled with a bag of mixed reviews. And if your team members can’t agree with that and they aren’t focused on the big picture, they aren’t leading.

Inspire Them to Lead

Not everyone was born to think beyond their personal responsibilities, but everyone can understand stakes and empathize with an organization’s goals. And once developers acknowledge that the goals are bigger than they are, you can provide them with leadership tools.

By having them participate in big-picture thinking and incorporating their feedback on topics beyond their role, you give them room to branch out. In Kaplan’s article, a former student of his received no guidance from his peers or superiors. Don’t be like them.

Recognize when your team members feel isolated and irrelevant beyond the minutiae of their day-to-day work. Ask them for their opinions on topics outside their zone of mastery. I think their responses will surprise even you. Bit by bit, they will begin to see how a low-code platform fits into the grand scheme of things. And they will come to understand the pivotal role that only they can play in the future of your company.

Moving Fast Breaks Things

“Move fast, break things,” is a modern startup’s de facto work motto. The idiom implies that a few bugs are okay as long as you’re fast. Despite distancing the company from this belief in 2014, Facebook’s Mark Zuckerberg popularized this idea as a positive attribute of early product development. But the axiom remains: moving fast delivers fast, but results in broken work.

Enterprises Want to Move Fast

In the world of enterprise IT, “breaking things” is rarely a desired outcome despite demands from on high to deliver software and applications as quickly as possible. With thousands of dollars on the line, jobs at stake, and professional relationships at risk, a broken release can cause irreparable damage. Enter low-code.

But if developers associate moving fast with breaking things, the last thing they want to do is move fast. Low-code’s key selling point, speed, is antithetical to an enterprise developer’s workflow. Naturally, when you claim to have discovered a tool that will increase your team’s throughput sixfold, they won’t believe you. And if by some miracle one does believe you, that belief may be clouded by the fear of breaking production.

Good, Cheap, Fast: Pick Two

Now even you may be wondering, is it possible to have both speed and quality at the same time? Yes, refer to this diagram:

Low-code platforms are not free, and far from it. The accelerated development cycles they provide come at a price, one they argue you will recuperate via reduced development costs and rapid turnaround.

But none of that matters to a developer, unless that developer is a leader. What matters to the developer is the analogy they’ve applied to fast development: it can cripple a product. And this belief goes much deeper than Mark Zuckerberg’s callow slogan; the belief stems from irrational thinking.

Hard Work > Smart Work?

In Oliver Burkeman’s piece, Nobody Cares How Hard You Work, he argues that many among us fall into the Effort Trap. The Effort Trap is the poisonous belief that if we work harder or longer, we provide more value. And this belief extends to the evaluation of employees.

In the sharpest example, he cited Dan Ariely’s story of a locksmith. This locksmith was well received by his customers as a rookie, but not as an expert. As a beginner, he spent superfluous time fumbling with locks and even damaging customer property. Customers forgave him because he had, “worked so hard,” to help them.

But as his skills improved, the effort and time required to complete his work shrank considerably. A job that once required an hour, he began to complete in minutes. Despite charging the same price, customers were dissatisfied with the snappy service they received. The job appeared trivial, so they felt short-changed.

Watch the Contributions, Not the Clock

You might agree with that sentiment, too. “If it takes the locksmith no time, why charge so much?” That’s the Effort Trap talking. If you had to choose between slow, labored, error-prone work or a quick, precise, and accurate result at the same cost, your choice is patently obvious. And if you put two-and-two together, you’ll realize that low-code platforms promise to help developers crack thousands of locks each day.

And if those developers are neck-deep in the Effort Trap, they won’t trust those claims. “If it requires no time, it provides little value.” The Effort Trap is pervasive in entire teams and organizations. If you put more emphasis on the number of hours your employees spend at the office, the personal life they sacrifice, or the time spent on call over weekends, then you’re focusing on misleading performance metrics.

To pull developers out of the Effort Trap, zero-in on contributions.

Moving Fast Breaks Things Is a Myth

If your team understands that ends are valued above the means, they will gain confidence in low-code. Working fast will come naturally, and so will finishing early. Don’t be surprised when they ask for more work to do or when they dig into that dusty backlog. Moving fast breaks things will soon become a myth of the past.

You’ve Made It

Developers fear low-code platforms for reasons not covered by this article, and more narrow doubts exist for each specific offering. However, the fear of job loss, black boxes, loss of passion, and breaking production by migrating to low-code are common and real. If you can combat these irrational fears, you can begin to employ low-code tools and reap the benefits of highly accelerated development.