How to Not Lose Your Job to Low-Code Software

When I was younger, my best friend's uncle was slowly reversed over by a party bus. At his funeral, underneath the sorrow, was a question in everyone's mind: How did he not see or hear the party bus in time to step out of the way? A similar question pops into my mind when I hear about enterprise software developers losing their jobs to low code software. Surely they could have stepped out of the way of that bus!

My friend's uncle couldn't get out of the way because he was caught in a pinch point - a spot where he had nowhere to move to. This article shows you the low-code pinch points for software engineers and how to avoid them.

Setting the scene

Let's carry on with the party bus analogy. Imagine you are an enterprise software developer in a mid to large sized enterprise. You and your team spend your days building, deploying and maintaining a variety of applications used by your company. Some of the applications you've coded yourselves, other applications were "off-the-shelf" but required customization or integration.

Suddenly you notice that a bunch of business users are riding around in the low-code party bus building their own applications. Should you be worried? I think not.

Pinch-points will be rare in larger enterprises

From 2010, with the rise of Blue Prism and then UIPath, you may have seen the dramatic impact of automation on your colleagues in Finance and HR. This is because there are lots of pinch points in those operational areas. When Accounts Payable is largely automated it is difficult for an accounts payable team member to slide into a different role - their entire job is gone. 

But software engineering is not accounts payable. The amount of work you have is driven by the ability of software to make a meaningful difference in your organization. Take a look at your current queue of work. If your team is like most IT teams there will be a mountain of unmet demand for new applications or additional functionality for existing applications. Thinking that any amount of automation will reduce that demand to zero is like thinking that a faster car will get you to Mars. If low code software starts taking some of your work, there will likely be other projects you can work on. If you handle this right, you can even shuffle some of the painful projects over to the party-goers on the low code bus.

The work performed by software engineers may be deepened rather than diminished by the introduction of automation.

-- Ralph Aboujaoude Diaz, HFS Research

Secondly, and more fundamentally, there are certain aspects of software engineering that are harder to automate than others - making it unsuitable terrain for the low code party bus to drive across.

For example, low code tools make it easy for non-developers to create a table to store data. But they can't do much to help the non-developer structure their tables to best map to the business problem they are trying to solve.

Low code tools also make it easy for a non-developer to build and deploy an app. But the tools don't ensure that the right stakeholders have been involved at the right parts of the project to comply with your risk and compliance guidelines.

Rather than losing your job as an enterprise software engineer, you are more likely to spend less time coding and more time on the other parts of your job as low-code spreads through your enterprise.

For most software engineers, the arrival of low code software in their company will give them the opportunity to add a lot more value to their company now that they don’t have to do the boring, repetitive stuff.

-- Jan Oberhauser, CEO, n8n

Enough with the party bus analogy! What kind of projects are we talking about?

Low code software can be used for lots of different types of projects from process automation through to apps that help users do their jobs faster and more consistently. As you read through the article picture one of the following scenarios:

1. an app that helps realtors send reminders to their customers about upcoming contract dates
2. a behind-the-scenes application that reads and reviews medical notations to identify patients who may not be prioritised correctly.
3. an app that builds a machine learning model to extract relevant fields from insurance policies

The anatomy of a software project

There are lots of books on how to structure an enterprise software project (See Blair Reeves' Building Products for the Enterprise for a good quick read). For the purposes of this article, let's categorise a project into four stages:

1. Planning and overall design
2. Building
3. Deploying
4. Maintaining

To help understand how low code software tools will impact your work, let's look at their current capability across each of these stages.

1. Planning and overall design

Of the four stages this is the last stage that low code software will take over. The planning and design stage encompasses everything from getting the right stakeholders involved to ensuring there is sufficient budget and resources to build and maintain the app and checking that you are building the right app. For example, imagine you work for a real estate company with customers complaining that there is too long a delay in getting contract documentation over to them. There are several ways to solve this problem but determining which way is best for your company depends on understanding the source of the delay and the various ways that delay can be minimised. This type of analysis won't be handled by low code software anytime soon.

2. Building

This is the core capability of low code software today. Once you have your overall design then your team or your business users can crank out an application using low code software faster than ever before. The key advantage of getting your users using low code software for this stage of the project is that low code software helps them determine what it is they truly need. Instead of attempting to draft and communicate detailed requirements and a spec they can iterate over the solution until they have something that suits their needs.

One of the key areas of low code disruption is its ability to abstract away the complexities of infrastructure - which makes it possible for non-experts to build and deploy surprisingly complex applications

-- Rick Lamers, CEO, Orchest

There is one area of this phase that will still involve your team - that is tackling the tough problems that aren't handled neatly by your selected low code solution because they are specific to the business problem you are tackling: For example, how do you extract relevant data from real estate contracts? How do you get access to a particular government dataset that doesn't have a standardized interface? How do you build a machine learning model that can categorize claims based on risk? But even if you don’t have the expertise in-house, a new category of software companies such as Managed Functions are emerging to handle these bespoke requirements.

3. Deploying

This stage is currently the wild west of low code software. Each type of low code platform takes a different approach to deployment.

• The RPA companies are building monolithic control centers that handle deployment and maintenance of applications. This solves the problem of deployment and maintenance but at the expense of requiring your team to use different tools to deploy and maintain low code apps than you do to deploy and maintain your other apps.
• Microsoft is building two views of low code apps. A graphical user interface for business users and a code-based interface that developers can use. This allows developers to deploy apps using the same git-based workflows they use elsewhere.
• AWS and Google haven't yet settled on how they are going to tackle this problem.
• And the hundreds of other low code applications take a variety of different approaches.

The upshot is that your team will need to set some guidelines on how this should be handled and who should handle it. I covered this in an earlier article in this series. Once the guidelines are set the low code platforms will help follow the guidelines - but responsibility for this rightfully sits with IT rather than the business.

4. Maintaining

This is currently the trickiest stage to address. Maintenance involves both break/fix activities as well as ongoing enhancements. Most business units are not set up to do this work but need to be involved because, if they built the application themselves, they are the only ones who know how it works from a business perspective.

Over time, low code solutions will handle this phase better but it will likely always require a combined effort from software engineers and the business to manage properly.

Pinch points to avoid

If you are a software engineer in a mid to large sized company and you’re able to communicate well with business users then you don’t have much to worry about. You’ll always find a way to add value to your company.

But, there are two areas low code will have a big impact on software engineers and, if you work in one of these areas, you should be aware of the larger trends at play:

1. Smaller companies (or larger companies with small tech teams)
2. App development companies

In smaller companies, the decision to use low code software rather than building custom apps makes a lot of sense. Look at it from the perspective of the CEO of a smaller company: He or she must choose between hiring a React developer to build a few custom apps (and then hope they never leave, retire or die) or use low code software to build the app. Going with the latter is a no-brainer. Software engineers employed in these companies will lose their jobs or will transition over to building low code apps for their company.

The greatest job losses will occur in app development companies. In these companies, the junior to mid-level developers rarely have the opportunity to utilise their communication skills in the same way a directly-employed enterprise software engineer can. If you are a junior to mid-level developer cranking out apps or building ETL pipelines and you look around your office and see dozens of your peers doing the same thing then it may be time to look at how you can enhance your communication and client-facing skills.

Conclusion

Technology change happens slowly and then all at once. It feels like we’re at the cusp of the all-at-once inflection point for low code software. The next couple of years will see dramatic changes in the type of work performed by software engineers. If you stay away from the pinch points, these can be very good years indeed.

The Low Code Road is a series of articles written for InfoQ by Doug Hudgeon, CEO of Managed Functions. You can read the first articles in the series here and here.

About the Author

Doug Hudgeon is the chief executive officer of Managed Functions, an integration company specializing in helping enterprise low-code and RPA teams deliver projects faster by providing bespoke components to handle the thorny problems they may encounter on a project. Uniquely, the components can be deployed as serverless functions to the enterprise’s cloud (AWS, Azure or GCP) so the solution runs entirely on their infrastructure. He is also the co-author of the Manning book "Machine Learning for Business" which shows your users how to solve real-world business problems using AWS SageMaker. You can find him on Twitter.