Low Code: Viable for Developers?
With the rise of the low-code movement comes the question, is low-code viable for developers? The short answer depends on the tool and the requirement.
Join the DZone community and get the full member experience.
Join For FreeLow-code platforms are often praised for their ease of use and understandability by business users; however, some developers may not be too excited by this prospect. What if there is an alternative to low code that follows coding principles? Will such an interface feel more natural for developers? Before asking that question, we must ask, is low-code a viable solution for developers?
In this post, we will explore if low code is a viable option for developers and what low-code platforms can do for developers.
Low Code for Developers
We came across an article stating that a survey by the IDC (International Data Corporation) pointed out that 68% of developers are of the opinion that low-code platforms can be used to develop critical applications. They also point out that 79% of developers believe that low-code platforms can increase job satisfaction and 80% of those developers believe that those platforms are useful to automate repetitive tasks and free up time.
Numbers say one thing, but what of actually working with low code? I was in a fortunate position to work as a developer in many enterprise environments. Some of those organizations used traditional coding practices and tools; others used low-code tools. Here is my opinion: It depends on your needs and the environment. All low-code platforms have their strengths and weaknesses. Be sure to do proper research on the tool before committing. See if you can use it for a while before deciding to make it your platform. That said, I can recommend that low-code tools be used to enhance your development. When taking into consideration how busy software development can become, it seems, at least to me, like a no-brainer that low-code tools be used to automate repetitive tasks. As an example, importing a file. You can either write code to import that file every time (and chances are you will have to import many files in your career as I have), or you can use a low-code tool to quickly build a process that will import that file into your database.
Integrations are becoming more complex. Business requirements are also evolving as organizations grow. You certainly can code something in C#, Python, or JavaScript, but do you want to spend so much time and energy ensuring that your code is scalable, maintainable, and flexible enough to bend to changing user requirements?
What Can Low Code Do for Me?
It truly depends on the tool. You have to start by asking the question "What is my requirement" and "What do I need the tool to do, and what should it not do?" Low-code platforms can automate a near-infinite number of processes and jobs, but what is important is to truly understand your requirement and expectation of the tool. This is the same with traditional coding, you likely won't use C# to program a self-made microcontroller, and it is certainly not preferable to read a file with assembly. There is a tool for every job.
let's look at a few common examples where a back-end low-code tool like Linx shine:
Creating ETLs
File handling (reading, writing, archiving)
Automating manual business processes
Creating a mailing system
This list looks generic, so let's look at an example: A user asks you to read a file and make the data available for their team via REST API. We have a post where we did that, and honestly, it took me less than an hour from installing Linx up till the REST service was able to be called.
It's important to note that there are many other places where low-code can shine. A front-end low-code tool can also greatly assist in creating great-looking user interfaces; again, it all depends on your use case.
Constraints on Resources
There is no need to go into detail about limited time. Every developer only has a certain amount of productive hours in a day. Beyond that, we can also look at a limited amount of development talent that is available. Many organizations find themselves in a situation where finding the right developers to meet increasing demands is becoming a challenge.
Low code platforms can assist with both these problems. By reducing time spent on mundane tasks or requirements, we can spend more time and energy on difficult and challenging tasks. One such task can be something as simple as importing a massive amount of custom files or creating an automation process to do this. I actually wrote a blog post on how this can be done with a low-code tool, and I was able to do it in minutes. If we take something like automating back-end processes with a low code tool, we are able to save an incredible amount of time and energy.
Weighing the Options
Before selecting a low-code tool, there are a few things that must be considered:
What is the existing architecture that the low code platform must integrate with?
What is the requirement?
What future requirements or constraints will the low-code platform need to accommodate?
Many times low-code tools get a bad wrap because they are perceived not to fulfill the need quite as expected. But we need to as the question here: was the wrong tool perhaps selected for this problem? Surely we won't be using a paintbrush to wash a big floor? It might be possible, but that does not mean we should.
With the rise of low code, many new tools exist. If you can, see if you can get a version to test it out and ensure that it will work to solve your problem and if it will work in your environment.
The Verdict
From the viewpoint of a developer, low code can feel intimidating, limiting, and even unnatural. And we can not blame them; many low-code platforms have been marketed as “the end of the developer.”
I am of the opinion that low-code platforms are not the “end of the developer”; it is a tool in their tool belt that is supposed to make their lives easier. As with traditional tools, let's say a hammer or a hand saw, if you choose the incorrect one for the job, you are sure to have a hard time.
Opinions expressed by DZone contributors are their own.
Comments