Having previously successfully defended low-code on all four charges of inflexibility, lock-in, security, and scalability today, sadly, we find low-code back in the dock yet again. This time it’s accused of ruining developers’ careers. Are the interests of coders and their employers set on a collision course? Or, can low-code make both sides a winner?

This is the fifth article in my Low-Code Myths, Fears, and Realities series, and if you’ve stumbled on this before reading the earlier posts, then you might want to reverse-up and read the back story. The links above will take you to my previous articles.

The Hardest Nut to Crack

I’ve just returned from our Nextstep conference in Amsterdam, where around 1,600 customers, partners, and prospects joined OutSystems to hear what’s moving and shaking in the world of low-code application development.

NextStep Amsterdam 2018

One of the many interesting conversations I had was with João Campos, CEO of Truewind, (an OutSystems Elite Partner), and the topic was not next step, but rather how to persuade newbies to take the first step on their low-code journey.

This is something very much at the front of João’s mind, as he has successfully established Truewind as a leading solutions partner in Portugal, where OutSystems is huge. Now he is responsible for landing and expanding his consulting company in new markets, including the U.K. and U.S., where OutSystems is not yet so well established.

What João told me was that although CXOs and senior IT leaders were quick to recognize the benefits of low-code’s faster delivery, developers were less enamored at the prospect of being told to configure rather than code.

“Developers have got one eye on job boards like Stack Overflow. When we set up in the U.K. in 2015, there was little demand for local OutSystems skills, so developers were worried that if their companies took the low-code route, their coding skills would fall out of date and harm their job prospects.”
João Campos, CEO of Truewind

If coders don’t want to low-code, that’s a pretty hard nut to crack. No CIO wants a rebellion on their hands, so when developers express doubts and fears about low-code—such as those explored in this article series—CIOs tend to tread carefully. Eighty percent of businesses say recruiting and retaining developers is hard; no one wants to inflame that problem.

Low-Code Has Been Given a Bad Rap

There’s nothing wrong with due diligence, and as discussed in the four previous articles in this series, we’re more than ready to help evaluators explore the minutiae of security, scalability, and flexibility. Want an extended test drive? Not a problem, we’ll throw in the training for free as well. Afraid that you’ll become a hostage to an evil low-code tyrant? Well, we’ve even laid lock-in, to rest.

There comes a point though, when due diligence tips into cynicism, and when that happens, more often than not, you can track the reason back to the career fears of developers. Cynicism —believing only the worst could be true—isn’t a recipe for career success. Diogenes (c. 412–323 BC) was reputed to be the most expert cynic, and he ended up living in a tub on a street in Athens.

The Relentless March of Automation

I was thinking about this dilemma yesterday as I walked my dogs through one of the apple orchards near my house. The apple harvest was in full swing, and it was fascinating to see how mechanization has transformed what was once a manual labor task of picking apples. There are tree shakers, blowers, sweepers, and crate loaders, as demonstrated in this video.

A Beautiful Apple Orchard

At some point, perhaps 70–100 years ago, mechanical apple harvesting was in its infancy. Brave pioneers invented machines for which there was no established market. Maybe the first fruit pickers that learned to operate these machines had the same reservations as today’s coders.

“If I spend my time learning how to drive this thing, will it ever pay back?”

Wind the clock forward a few years, and the need for manual apple pickers is virtually non-existent.

Today, low-code is emerging from its infancy, with (according to our research) around 34 percent of organizations already using one low-code platform or another, plus another 9 percent of organizations saying they expect to start using low-code soon.

Forrester predicts low-code adoption will grow at a rate of 50 to 55 percent each year between now and 2022.

I’m not suggesting demand for developers will diminish to the same extent as manual fruit pickers. After all, by 2020, one million programming jobs in the U.S. could go unfilled, according to the U.S. Bureau of Labor Statistics.

However, as tools become available that can increase productivity and alleviate this development talent shortage, businesses would be foolish to ignore them. Taking the long-term view, only a Luddite would ignore the relentless march of automation and assume coding in five to ten years’ time will be unchanged.

Eye(s) on the Prize

Returning to my conversation with João, there seems to be a potential conflict of interest in how some developers regard their interests versus the interests of their employers. If they have one eye on the job market and the day-rates or salaries paid for particular coding skills, might they have a lesser regard for interests of their employer, when it comes to selecting languages, frameworks, and platforms that are best suited to the job?

Employees interests vs Self-Interest

I realize that questioning the ethics of some developers in this way will be a “red flag to a bull” for some readers, but as I’ve seen this happen with my own eyes, I decided not to airbrush such behavior from the record.

Before joining OutSystems, I worked for a niche low-code vendor, based in the UK. We had a partner that was also a Salesforce.com partner, and they were implementing a low-code solution for a public sector body. Several of the developers asked to get reassigned to other projects using Salesforce so that they could bolster their CVs with more Salesforce experience. The resulting staff-turnover was bad for the customer, delayed the project, and ultimately fatally undermined the partnership.

How Low-Code Experience can Foster Career Progression

Of course, not all developers treat technical skills like guns for hire. Many appreciate that career progression is more likely to come from understanding and solving business problems rather than focusing on code and the latest frameworks.

Low-code significantly reduces the time spent on mundane manual-coding steps which means developers can focus more on solving business problems, and deliver faster solutions.

Low-code developers, therefore, get more opportunity to demonstrate their prowess at solving business problems and gain exposure to more projects and user departments, which makes them more valuable to the business because of their superior business knowledge.

Low-code encourages a co-creative work style because developers and users work more closely together. Developers get deeper business insight and the process fosters many of the soft skills that will serve developers well as they move into more senior positions. Relationship building, knowledge of the business, empathy, and change management feature strongly in the list of top skills needed by successful CIOs.

Businesses that use low-code can innovate more quickly, adapt faster to customers’ changing needs, and therefore achieve a competitive advantage. Thus, improved employment prospects for all employees, including developers, should follow.

How Low-Code can Improve Job Satisfaction

What drives job satisfaction for developers? Without getting overly scientific (I’ll leave that to Myers Brigg,) may I suggest two dimensions to consider:

  • Engineering: Solving complex problems results in a great sense of accomplishment and satisfaction for developers. However, these aspects are not so publicly celebrated, perhaps only the developer, their immediate supervisor, and peers would know or understand the detail.
  • Delivery: When a new system or capability gets delivered, it’s more widely understood and celebrated. Perhaps staff, customers, or partners will offer thanks or at least positive feedback, for the way this has improved their work or the customer experience. However, the success is more of a team effort, and seldom something attributable to one individual.

It seems likely to me that the use of low-code is more likely to stimulate the delivery feel-good-factor than the engineering equivalent. Visual configuration of applications is less likely to mean entirely novel approaches are required.

However, with those rapid delivery speeds and the co-creativity, it’s very likely that developers will receive far more appreciation and plaudits from the business.

I suppose people with different personality types would favor each of these in different measure. However, if you look at this from the perspective of your customers and shareholders, delivery rather than engineering is most likely to make you a hero in the eyes of your CEO. Which is more likely to assist your career ascent?

Hopefully, readers are starting to perceive that low-code is far from a developer career killer.

Three Suggestions For Next Steps

When I started this article series, I had three different personas in mind, each of whom I thought might appreciate some help overcoming the fears and myths of low-code:

  • IT leaders who are wondering how to raise the idea of low-code with developers that they suspected might be resistant to change. “Telling artists which paint brush to use,” as one of my customers so eloquently put it.
  • Web and mobile developers who have the latest, most in-demand development skills and would, therefore, see low-code as a threat, as it alleviates the scarcity of supply that drives increased remuneration.
  • Legacy developers who lack the latest web and mobile development skills and could, therefore, be at risk, when the legacy systems they support reach end-of-life. They watch innovation initiatives from the sidelines, perhaps envious of the fast-pace and excitement enjoyed by colleagues on the other side of the “bi-modal” divide.

So, if you fit into one of these three profiles, what next steps might you take to get started with low-code?

IT leaders

If you’re an IT leader, chances are you want to increase delivery capacity and rebalance how resources are used. You’d like more effort to be spent on innovation and proportionately less time and budget to be swallowed by maintenance. You want to future-proof development and embrace containers and microservices to improve agility. You’re concerned about lock-in that could come from proprietary tools or frameworks that fall out of fashion. Perhaps you also want to reskill legacy developers, so valuable business knowledge isn’t lost from the business when legacy systems are shut down.


Although low-code sounds appealing, forcing its adoption on all of your developers could risk demotivation and departures that you can ill afford. How can you introduce it, and develop some early successes, that will win others to the cause?

Action Plan

If this sounds like your situation, this case study from IOOF should provide some useful inspiration. Sharam Hekmat, CIO at this wealth management company, wanted to introduce low-code to speed-up delivery and eliminate an increasing backlog of digital projects.

If you read the case study, you’ll learn how he used a competition with a $1,000 prize to identify developers and business analysts who had the desire and aptitude to embrace low-code.

"Forcing change on seasoned developers is rarely a recipe for success. So, I hit on the idea of running an OutSystems development competition to find the most engaged people who could help us build excitement about low-code across the IT organization."
Sharam Hekmat, CIO at IOOF

The key elements of IOOF’s approach were as follows:

  • The competition was optional so that only motivated and enthusiastic participants took part.
  • They paired seasoned developers with people who had technical roles, such as business analysts, to improve team building and cross-training
  • Time off was booked to ensure participants could use the self-study training materials and then spend another week building an app that would solve a genuine business requirement.
  • Participants that weren’t keen or failed to complete the training did not join the low-code team.
  • The best low-coders turned out to be legacy developers because of their traditional systems analysis skills and superior business knowledge.
  • Several of the apps built during the competition went on to become productive systems.

Web and Mobile Developers

If you’re a web or mobile developer, no doubt you want to keep up-to-date with the latest languages and development frameworks. You get frustrated when you get buried in long projects that deflect you from that goal.


Keeping up with the latest tech is a constant battle. The truth is that all skills have a half-life, and in the case of JavaScript Frameworks, it’s unlikely that your employer will give you experience working with all those that are in vogue. As described in “The Brutal Lifecycle of JavaScript Frameworks” on Stack Overflow, it’s a constantly changing picture:

  • New frameworks or versions are continuously released.
  • Many companies do major rewrites to optimize or update code when new framework versions become available. That’s dull work, and it seldom adds value.
  • Different developers pay enthusiastic homage to particular frameworks, while others seem less enamored. This particularly bleak assessment caused a heated debate.

"I’ve never once worked with a framework or library that doesn’t have poor/confusing/incomplete documentation, bad examples, performance degradation, conflicts with other frameworks/libraries, new versions that break old ones, learning curves, hard to customize, hard to work-around bugs/missing features, etc."
From "The Brutal Lifecycle of JavaScript Frameworks"

The need to keep up with these ever-changing frameworks and libraries is arguably a distraction from focusing on the things that are most likely to advance your career. As argued previously, developers who demonstrate more prowess at solving business problems and have superior business knowledge are more likely to gain promotion to more senior roles

Action Plan

If you’re starting to see that rather than ruining your career, low-code could actually accelerate your progress, then why not take OutSystems for an extended test drive? It’s free, and the self-study training videos will get you motoring in no time at all.

Once you see how much faster you can build the kinds of applications your organization needs, have a word with your CIO, and suggest the sort of competition described above. With your head start, you could easily be the winner.

If on the other hand, this article has just succeeded in putting your back up, and you’re still smarting from being compared to a manual fruit picker and Diogenes, sorry for the upset. I understand. I did say you’d be a hard nut to crack. Low-code is obviously not for you, but thanks for reading this far, which was a remarkable feat of perseverance. Hopefully, some others in your organization will investigate OutSystems, and then perhaps we’ll talk again.

Legacy Developer

If you’re a legacy developer, chances are you’ve been in your organization for years and have hugely valuable knowledge of the business and systems. However, recently another team of  developers has been getting all the exciting work, although their digital transformation efforts would probably grind to a halt if you weren’t supporting the legacy system and creating the backend services on which their web and mobile apps depend.


Several of the legacy systems that you support are reaching end-of-life. You’re wondering what the future holds, and whether you’ll get the time needed to gain modern web and mobile development skills before your role is placed at risk.

Action Plan

If this sounds like your situation, then you too should have a quick read of the IOOF case study mentioned above. Here are the relevant highlights of the story:

  • IOOF recognized the valuable business knowledge of their mature and experienced legacy developers and didn’t want to lose that from the business, even though the legacy systems were being shut down.
  • IOOF provided these developers with two weeks off, which was all it took for them to complete the OutSystems self-study training course and build their first prototype app.
  • This was much faster than the months it would have taken to retrain these developers on C#, JavaScript, various frameworks, and DevOps tools.
  • These legacy developers are now re-tooled, re-motivated, and delivering beautiful, responsive web and mobile applications around four times faster than their hand-coding counterparts.

You can start learning OutSystems today for free. Sign-up for the personal edition, and you get access to the entire self-study training curriculum. Then take the idea to your CIO.

If you draw a blank, there are at least 250 partners listed on the OutSystems website, and many of them are hiring. As mentioned previously the market is growing at around 50% per year, and as OutSystems is the low-code market leader, we’re growing faster still.

Want to meet up?

You can join OutSystems, Truewind, and DZone in our upcoming webinar “Exploring the Myths and Realities of Low-Code” on 30th October. Can’t make it? Register anyway, and we’ll rush you the recording.

Webinar Mythbusters

Alternatively, check out of Events and Webinars page for other opportunities to meet.

More Reading on Low-Code Myths

Here are the links to previous articles in this series.

Myth # 1 – The Fear of Inflexibility

Myth # 2 - The Fear of Vendor Lock-in

Myth # 3 – The Fear of Low-Code Insecurity

Myth # 4 – The Fear of Unscalability