I recently made a post on LinkedIn where I simply provided a link to an article posted by someone else, and that produced some interesting responses and a bit of a discussion. Now that post does seem to require a closure, so this is what I’m going to write about today.
The original LinkedIn post is stating that low-code often falls short of the expectations, but, in general, I would go on to admit that it’s not necessarily a problem with the low-code – it’s a problem with the expectations.
After all, you wouldn’t try to cross an ocean in a fishing boat, but you might still choose to do so either of of necessity or when you are not aware that your regular fishing boat is simply not meant for crossing the oceans.
When it comes to the low code, the problem is not that low code cannot do stuff. It certainly can, but it’s, normally, far not as versatile as pro-code.
For example, one way to think of the solution development would be to consider a funnel like the one below:
At the top of the funnel, there is a wish list. At the bottom, there is a solution. In between those two, there is a bunch of filtering layers. This is not so different for pro-code and low-code, but, from my perspective, there are two major caveats to low-code:
- Framework and Platform capabilities will always introduce some constraints, which is not necessarily the case in the pro-code world, and, often, this won’t be expected
- Licensing costs will start adding up – there could be licensing costs in the pro-code world as well, bt the structure there might be different. For example, you might be looking at the per-user monthly subscriptions in the low-code world vs per-component perpetual subscriptions in the pro-code realm
In other words, even though the funnel above looks more or less the same for low-code and pro-code, at least two of those layers are, often, much more limiting on the low-code side (namely: framework/platform capabilities and licensing costs)
You may also want to consider skills – as strange as it sounds, low-code solutions do require developers to acquire certain skills to work with the low-code framework/tool productively, and you may not always have proper skillset on your team. Which is very similar to pro-code, though.
Now, you probably want to envision the final solution before you start the implementation, since you want to have at least some idea of which part of your wish list can potentially make it to the final solution.
In case with the pro-code, the limitations are, mostly, around the skillset you can hire and the time you can spend (since both of those affect your project cost).
In case with the low-code, though, if you wanted to do this kind of envisioning, you’d have to know which of those requirements would have to be filtered out or sacrificed because of the framework capabilities and/or because of the licensing.
And how do you do that if you don’t have enough experience with the platform? Well, you just don’t. You can try, but you will probably miss something, and you will miss more on the more complex projects.
This, in my opinion, leads to the next statement “low code tools often fall short when tasked with more complex scenario”. It’s not that low-code tools can’t work in the more complex scenarios, it’s simply that the limitations start showing up in those situations, and, if you don’t consider them upfront, they become costly to work around / to resolve.
In other words, strange as it sounds, when dealing with the low-code, you actually may want to pay even more attention to the initial assessment, planning, and high-level design, since, if you hit an unexpected limitation with low-code once you’ve started implementing the solution, you may not be able to resolve that problem. Pro-code will usually be much more forgiving from that standpoint (of course you would still need to spend time and money, but, from the technical perspective, there will likely be a solution).
PS. And this is exactly why I came up with an e-book earlier this year which is talking about some of the Power Platform limitations: How (not) To Fail a Power Platform Project
PPS. And I am assuming this is why Steve Mordue’s “The Works” service could be very useful – see here Although, I think this is something I could/should be offering, too 😂