English | EN 
Choosing Low Code or Traditional Code for Solutions
Part 2 – Low Code/No Code and The Starting Point
In the previous blog, I put into context what the decision to be made is about by talking about the choices and what they are. With that now in context, we look at how things are different today which makes this discussion very relevant. The key to understanding where Low Code/No Code becomes an important choice is a concept of “the Starting Point” which is essentially an acceleration to a place in the race to the finish line.
As previously posted, Low Code and No-Code solutions and frameworks existed before but the main difference is in the processing power and other technology improvements that have enhanced and supercharged the ability to “move the bits” needed to scale up and to do so in significant magnitudes to make it viable.
We know computers and processors are more powerful, sure, but the biggest thing that amplifies that to the levels that make it more viable today is the Cloud itself! Low Code/No Code systems these days are typically SaaS (Software as a Service) offerings by major vendors who do that as a specialty (Outsystems, Mendix, UI Path, etc.) or part of larger platforms (SAP, ServiceNow, Microsoft, etc.) Processing Power essentially “shares time” with their worldwide infrastructure because just as Amazon discovered when standing up AWS, not all compute time is being used 100% percent of the time and with enough scale, they can monetize the “in between” moments by “leasing it out”.
Suffice to say, a lot of the plumbing underneath to handle it has been worked out and not the subject of this blog (but perhaps one for another time?) That now leaves us with the end products which, unlike the paradigms of the past, tend to be much more robust and much more visual. A common theme of these platforms is the idea that a business analyst with little to no coding skills but enough knowledge of the business problem they are solving can connect pictures and images of things that abstractly (Workflows or Bots) or Directly (actual apps or Report Dashboards) and, with little to no effort, come up with powerful solutions that would have otherwise take much time and cost to put together in the traditional way.
Does this mean that the appropriate role to build Low Code No Code apps are non-developers? Not at all as the idea again, bringing back the “starting point” concept is that ANYONE benefits by starting a race closer to the finish line (or starting the climb closer to the start of the mountain, pick your favorite direction if you will) and Low Code No Code systems are supposed to help accelerate things and getting you there. This makes the idea certainly a likely favored path but of course, there are going to be the caveats that must be applied such that we would not go down a path that takes us further away from the objective because we picked specific tools or tech that are not appropriate for the solution.
So that brings us to where the “experienced professionals” may be brought to now help come up with the choice of the appropriate mix of choices albeit the customer/consumer should still be able to tell if the outcome of the choice or mix accomplishes what they need. A key here as a customer or consumer is that you will get what you need if you don’t focus on the “how” you got it unless that is truly critical for it such as if you wanted a solution to show up on, say, Microsoft Teams which by its requirement potentially narrows the choice of tools that are more appropriate or more aligned towards it over some “better” system that would otherwise require so much extra customization to squeeze the square peg into that round hole.
And now with that in context, we can hopefully understand that, at least from the professional standpoint, there are folks who can sometimes “eyeball” situations and give an initial assessment that can at least be used to help their clients prepare their expectations. This is the case of the mechanic telling the customer getting that oil change what they should get when it is done and how they know it was done. Oh, and yes, there should always be metrics but that’s another blog series to watch out for.
In the next part of the series, we will look at the actual Levers that help make the decision now that we understand not just what the decision being made is but why it matters more today than it did in the past.
