BACKGROUND IMAGE: traffic_analyzer/iStock

E-Handbook:

Mistakes to avoid in low-code app development

Manage Learn to apply best practices and optimize your operations.

A low-code platform can do a lot, but it has limits

If you're ready to jump into low-code development, you'll want to know what these platforms can help you accomplish and how to sidestep common troubles.

Low-code platforms can build you an application prototype in five minutes. Click generate, and you might have 50% of your functionality. With some work, you can get it to 80% in a day or two. What you have at that point might not be pretty. It might not be tested well. It could require an integration or two. Still, you will have made an impressive demo in very little time.

Before you commit to low-code development, however, stop to consider what you'll be able to accomplish with it and take note of the limitations of a low-code platform. Tools available in low-code/no-code development platforms put great capabilities into the hands of people who aren't necessarily trained in development, and these citizen developers might do fine with them. That does not mean they won't make mistakes.

Think carefully about the extent of customization you'll need. Plan ahead for the coding depth your projects will require. And, yes, testing and security should be part of your efforts right from the start.

Don't make assumptions about style

You want to do more than fill in the database. You'll want the website or mobile application to look like it came from your company. That means custom styling.

Organizations use a logo, colors, fonts and so forth that are specifically theirs, and most low-code platforms accommodate some forms of styling. The more precise your requirements and the more detailed the work, the more you will probably have to pay. If advanced styling features have a cost, make sure to budget for that.

Your company may have digital accessibility requirements. These can be particularly difficult to implement in software that is based on a template and generated by someone else. To address the accessibility requirements, create a low-code prototype, run the accessibility tests, then try to bring that prototype up to your standards. It might be harder than you think. It may be impossible. (Even if not legally required, having your content available to as many people as possible is just good business.)

This brings up the great risk of using a low-code platform: If the platform does not offer what you need, you're out of luck.

Don't underestimate the depth of code you'll need

Exactly how much code can you write, and what can that code do? You might want it to change the size of the elements on the screen to resize with the device. Or you might want it to do something special when the device is turned sideways. Maybe you want to call a web URL, which might require authentication, then use the results to change the elements in a drop-down list.

Getting a nice site or phone app up and running in hours or days at a low cost is wonderful. Unless, of course, it doesn't quite do what you need it to.

Some applications are composed of pages and can be expressed as a graph, with connections between the pages. You might want the page flow to be based on inputs, which are then calculated. For example, if a person's income is too low for the loan, the app moves to a rejection page. This will take a bit of code, more than what a simple next button in the demo can accomplish.

It is possible that some of these features simply do not exist within a platform and you will not be able to add them. At that point, you'll either need to accept the constraints or start over.

Don't overlook lock-in and security

Some low-code tools, and especially no-code products, can be created entirely in the cloud. That means the database you create will exist in the cloud. Getting data out to a local database can be problematic.

Some CIOs and CSOs might not be particularly comfortable with their data in the cloud. And what happens if your vendor goes out of business? Maybe low-code mobile applications are really just a skin that executes code the vendor stores on its servers.  To trust a relatively new company that relies on venture capital instead of profits is not a popular play for some senior executives.

Be sure to think through these security-related challenges and how data governance will be handled.

Don't trust that integrations will integrate

The idea of calling an API in order to perform some common task, such as authentication or social media posts or reads, is so common that it is taken for granted. Even if the platform doesn't supply it, programmers know they can code an authentication themselves -- unless they aren't able to.

Whatever it is you want to integrate with, be it a system used in accounting, HR or social media, prove it with a demo before wading too deep into low-code development. And don't get it 90% there. Even 99% is not good enough. With a low-code platform, that troubling last bit of integration might not even be possible. Prove it before moving forward.

Don't forget that simplicity can be a problem

Traditional software has versions. Programmers make changes to the code, check it into version control, perform a build and move that to a test environment. When the application has gone through its paces, programmers can push it to production.

Low-code environments don't always work that way. Instead, some are more like desktop publishing or a content management system. Click save or publish, and your application is available for the world to see. Made a mistake and need to roll back? Well, that isn't the way things work. You need to make your changes again and republish. If you forgot the old code you deleted, you may need to re-create it. Without a test environment, you'll end up testing in production.

The problem gets bigger when it comes to custom code. In traditional software development, we have code libraries that are versioned. In a low-code platform, the code could stay right along with the application. The only way to re-use that, say for next year's conference, might be to cut and paste.

Likewise, if it is even possible to create code libraries that are true functions, those might not be sharable or version controlled. If those are things you require, or would like to have, check the platform carefully. It might be worth it to create a separate project to see if code can be shared. Some software engineers will want to copy code back to a traditional source-code control platform, with all the awkwardness that would entail.

Getting a new site or phone app up and running in hours or days at a low cost is wonderful. Unless, of course, it doesn't quite do what you need it to do. Before you give permission to the marketing department to create a low-code event or recipe application, take a hard look at what could go wrong.

Between security, branding, third-party integrations and basic feasibility, there are some downsides to a low-code platform. If you can get past them and set some reasonable quality standards, the platforms offer some amazing capabilities that can jump-start application development.

Just be sure to look before you leap into the brave new world of citizen development.

Dig Deeper on Test-Driven and Model-Driven Development

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

What worries you most about bringing low-code development into an organization?
Cancel

-ADS BY GOOGLE

TheServerSide.com

SearchAWS

SearchBusinessAnalytics

SearchHRSoftware

SearchHealthIT

Close