 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Low-code app development is here, and thanks to the rise of work from home (WFH) over the past couple of years, it is here to stay.
Businesses that transitioned rapidly to WFH saw how quick and affordable it was to digitize their simple and manual processes with low-code applications. But behind the scenes, all things were not glitter and gold. As business users cheered for the rise of low code, the groans of IT departments and their full-stack engineers, whom we’ll call “pro coders” for this article, rattled the walls.
To the full-stack engineers who can make anything out of ones and zeroes, a graphical interface is the bird cage that prevents them from soaring through the skies.
Take an app and ask two developers to work on it. When one pro coder does something that conflicts with another pro coder, there are well-defined, tried-and-true processes to settle these merge conflicts. Some low-code app platforms do not have a process to settle these conflicts — they often just automatically accept the newest version.
Seasoned developers spend years developing the expertise to create scalability in an application, and now we are being asked to trust in the scalability of a low-code platform? “This works great in your demo describing a two-step process that will benefit the 10 users using it, but what if ten thousand users use it at the same time?” I have joined enough low-code app demos on Zoom to see these kinds of questions flood the chat.
Those are valid concerns and actual problems. But they are actual problems only because of the lack of process.
Low-code app development is not the silver bullet that marks the end of full-stack engineering and traditional IT, but it can be the shiny new tool you want everyone to use. Before using a low-code app platform, you should understand its limits and the best use-case scenarios for it. To deny the usefulness of these low-code platforms because they are too simple or cannot do everything is openly admitting that you did not read the documentation.
Low-code tools like ServiceNow’s App Engine can spin up a database with a collection form that automatically sends out approval requests and action tasks, all in a fraction of the time it would take for a full-stack engineer to do it from scratch. Could more functionalities be added to this if done from scratch? Absolutely. In the end, it’s up to you to determine which solution should be used while factoring in level of effort, resources available and timelines.
There are building blocks in traditional app development that everyone deals with. Things like databases (lists and forms with SQL queries) and frontend interfaces (websites, reporting engines and notifications). If a low-code app platform does these things for you the way you want — or even if it only does 90% of what you want, but does it nine times faster and you do the last 10% manually — then those building blocks are no longer your problem. Now you can focus on more interesting, specialized, innovative projects.
The rise of citizen development is not coincidentally correlated with the rise of low code. When I worked for the University of California, my team often had a backlog of requests for new apps and features that, if we were to say yes to everything, would’ve taken months or years to get through, on top of ongoing maintenance operations. While it gave us the benefit of showing that we needed more resources, it help that customers were complaining about our slow timelines. Low-code app development meant we could train non-developers to fulfill their own requests for apps and features. The more we equipped others with the platform, training, best use cases, etc., the easier it got for us to work on everything else.
Working at a university, I hired student developers to work on these low-code platforms. One of my student developers was trained to first use low-code app solutions and within one week of her cohort’s onboarding, we were releasing apps to the campus created entirely by new student developers. Low-code apps equip developers with skills that allow them to hit the ground running and have a foundation to build from. According to that same student developer, “these skills have led me to become a junior developer post-college, and a product developer for a partner company.”
