5 points to consider about low-code/no-code (LCNC) solutions

9-minute read

Developer shortages, shareholder demands, and digital-first competitors are a combination that fuels the most recent popularity boost of low-code/no-code (LCNC) solutions to business application needs. The idea is not all that new. I remember building some feature-rich functionality using MS Works back before we had Google to search for shortcuts on and AOL was mailing floppy disks every week to the same addresses.

The tools have been getting better and better over time, with a major acceleration in quality as developers began using drag-and-drop to quickly outline complex applications that could then be tweaked for robustness and complexity. Business spent tons of money on tools to make developers more efficient, so the tools kept getting better until they evolved into something that non-developers could use to create fairly sophisticated functionality (and the developers went back to the command line). Some of the leaders in the space are the Salesforce.com platform, Microsoft Power Apps, and Appian, to name a few.

Why you should be thinking about LCNC

It’s easy to see why business buyers are attracted to LCNC options. Developer shortage? No problem— your knowledge workers can drag-and-drop their own tools together. Need to improve margins? Tell your developers to always use clicks over code and reduce the time to deliver functionality. It is definitely that easy, because you saw a YouTube video where someone built an app in 10 minutes or a live demonstration at a conference where the presenter solved a problem in 20 minutes that your developers took six months to complete two years ago. You might still need developers for the really complex stuff, but now they can do more, faster, with fewer people, and why do you need architects anymore?

Now, in a quickly written post I might just say that the entire previous paragraph is describing something that only exists with smoke and mirrors and is mostly vaporware, and that you are doomed to difficult, time-consuming solutions. I’m not going to say that, but I hope you haven’t gotten rid of those architects yet, because they can help make the right decisions about clicks over code.

1. It’s never really no-code

Hopefully you have heard the expression “there is no cloud; it is just someone else’s computer.” Well, in that same pattern, there is no LCNC; it is just someone else’s code. The great thing about this is that when there is a problem with the code, or the code can add more features, you rarely need to make any changes to get those updates. However, there are always updates, because the people using LCNC always seem to find the limits of imagination applied to the underlying code, and then you can’t go any further until it is updated. And if there aren’t enough people sharing the same problem, that might be a long wait. Thorough testing will help find these limits and let you know if you need to go another way.

2. Easier isn’t always faster

Those slick demos on YouTube? Not all, but many, have been edited for time and flow. I watched a video about writing CI/CD configuration files recently and was both impressed and amused that the person kept using the wrong term and added a correction notice on the screen each time, at one point including “I don’t know why I kept saying the wrong thing.” This honesty was refreshing, and it bleeds over to the live demos, where clearly they aren’t editing out extra time or typical mistakes that result in doing something over. Live demos are the result of multiple rehearsals and (usually) careful selection of use cases that seem complex when seen for the first time, because the audience’s experience with that challenge is how hard it has been in the past, and they don’t consider the demonstration is of a tool that has been purposely designed to solve that issue. As Arthur C. Clarke said, “Any sufficiently advanced technology is indistinguishable from magic.”

That said, for the right use cases, LCNC will be easier and faster. The most important thing to remember about LCNC platforms is that they continuously mature. Just because it was not up to the task two versions ago doesn’t mean that it won’t fit the bill perfectly now. Take time to review the latest capabilities for any solution rather than falling back to an earlier approach. Conversely, don’t take LCNC claims at face value. It may not address your specific use case, or it may be an immature solution that will become unavailable in the next release.

3. Faster isn’t always cheaper

“Act in haste, repent at leisure,” is both an incorrectly stated idiom and perfect description of why LCNC is not “eating the world” as software itself did. The bad rep of citizen development and shadow IT isn’t as much about solutions not being controlled by IT as it is about there being no organization of the solutions. Redundancies and inefficiencies always occur when there is too much reliance on LCNC, and these are the least bothersome of the side effects. More of a concern, and less obvious (until it is too late), is the lack of testing in non-production sandboxes. Automation is a key target for LCNC, and while it can make doing tedious tasks much faster while reducing the effort, it can also create havoc much faster with less visibility into the root cause.

Another ill side effect of LCNC is the attitude that since it is very clear how implementation is put together at the time, it will be just as clear to anyone else at any future time. This is usually an illusion (or delusion, depending on perspective). I know senior developers who, when rushed to deliver code without documentation, can look at something they wrote only a few days ago and have to laboriously trace everything back to remember why they wrote it. Now take something that someone with little software experience threw together (literally or figuratively) that did something really useful that people began to depend on, and then the person who built it leaves the company. Sooner or later, that solution will have an issue, and the odds are very much against someone finding where it is running, how it is working, and what needs to be fixed. Everything grinds to a halt until it is recreated from scratch. Even worse is when the orphaned solution clashes with another and very automatically creates havoc with the data in production.

This is not to say these tools and solutions aren’t valuable. They just need some supervision, documentation, and monitoring to ensure they are assets rather than liabilities.

4. Simplicity can be complex

This particular area is similar to the previous one, but a little different in how to prevent it from being a problem. Doing one simple thing with declarative programming (another type of LNCN) is very powerful in that saves time and decreases maintenance. So, doing many things, all strung together, is even better, right? Well, sometimes. Some processes require a lot of steps, and when initially building them out, where that is the only focus of the person doing the work, it all seems perfectly clear. But later, if there needs to be an update or an unforeseen problem arises, it can become extremely hard to trace through dozens (or more) configurations on a palette or file to locate where to make the change or fix the issue.

The solution to complexity from too many simple things strung together is to break the steps up into logical units. “Logical” may be in the mind of the developer, which is where architects come in. The steps can be categorized and segmented and then used (and re-used) in a simpler configuration. Sometimes steps are complex enough that it is better to have some custom code that can then be used by the configuration to complete certain pieces. Decomposition is something not often thought of with LCNC solutions, and it’s what makes the difference between great solutions and great re-writes following great disasters.

5. There is no one-size-answers-all

Well, like some of the shortcuts in the use of LCNC, this last item is really to round the list out to five. I think it is clear from the first four considerations that while consequences can sometimes be seen coming, and are always clear in hindsight, that a formulaic decision when to use LCNC and when to call in the senior developers and architects just isn’t possible.

There are, however, some safety rails that can help steer things in the right direction. First are enterprise architecture principles that reflect the organization’s culture around such solutions. Some businesses are built around a coding culture and LCNC needs to be isolated to specific usage. Other businesses are dependent on software to run but have a very small IT group where code is not their thing.

The reason I used the plural principles is that the best option will vary by context. A solution on the Salesforce.com platform should be declarative over custom … except when it is impractical. For example, one could probably manage very complex message routing or data synchronization using Flows, but Apex code will be much easier to maintain for the bulk of the solution. Weaving together declarative automation with custom code is often the most elegant solution to something complex, business critical, and not yet a full-fledged feature (or part of what differentiates your business). And check back each time you update it or need something that is new and similar to see if the Salesforce offering hasn’t since come up with an answer that will require less maintenance on your part. Missing the need to change the solution when the requirement changes is not limited to LCNC, though it is identified more quickly by the nature of LCNC being designed and built “top down” where custom code grows “bottom up”, delaying and obscuring the accumulation of technical debt.

Summing it up

Click, drag, and drop is what moved computers from the basement to the backpack, and even though “Internet speed” is a 20+-year-old term that now has different capitalization and meaning, we continue to look for ways to do more, faster, and easier. Low- and no-code is one way we continue to pick up the pace. We just need to remember to check that our laces are tied and we have the right shoes for the right track before really pouring it on to reduce the possibility of a face-plant at the finish line.

Senior Technical Architect Scott S. Nelson has over 20 years of experience consulting on robust and secure solutions in areas such as multi- and hybrid-cloud, system integrations, business process automation, human workflow management, and quality assurance innovation.