Choosing Low Code or Traditional Code for Solutions

Part 1 – understanding the choices

As an Architect, you would probably be right to think that decision I make could easily affect whether or not the thing you are building would stand strong and overcome the test of time or fall apart and break with an unexpected strike at a missed weak spot. I recall the parody of the Death Star in Star Wars (insert copyright Lucas Films and parodied in Robot Chicken) having what should have been the most obvious weakness but then there was also the prequel (Rogue One) that came years later that made sure to address it specifically as something did!  In that later story comes the notion that what we do may not necessarily be a case of “missing something” to cause a failure but of actually doing something very deliberate to one end or another.  To be sure, technology has come to the point where there is so much tried and through patterns and practices alongside new innovative opportunities to the point that we are more likely to be overwhelmed by the paths to choose from. 

So, for myself as an architect working with solutions mainly in the Microsoft M365 SaaS Enterprise Cloud space, deciding begins with setting my filters to minimize the noise and bring the main melody of a little symphony of a solution into clarity or at least into a pattern I cannot just design and build upon but others can also understand and interpret in as close to the same way as possible while ultimately servicing the needs of the stakeholders relying on us to better their work. 

Now I don’t mean to say there is a simple formula to pick and choose to go Traditional Code over Low Code/No Code because if there was, you know it would be the first slide in any presentation on the subject and much of the billing work around those workshops would be directed elsewhere.  Since there is no conspiracy of that sort, I will say that it can be involved and that there is value in the companies that make a living helping people decide but like a customer/consumer who can assess when work is considered done for, say, an oil change or a paint job on a house, there are things that can be said to help make that determination without a semester in school or a heavy engagement at high billing rates. 

As it is not straightforward, what follows is a bit more intro and a lead into a series of posts that put the picture together to help the business user and even the technologist, wrangle the choices and approaches to take.  With this intro behind us, let us get our definitions in order and ready.

Traditional Code vis-à-vis Low Code/No Code defined and a small piece of history

Traditional Code is essentially the way most solutions have been built since the first on-off switches were put together.  Consider it the core for making anything happen from scratch or from some other later starting point (a concept which will be important later in the series!) to achieve the objective of the program or solution.  In the beginning, it was “machine code” or the arcane binary and soon hexadecimal-based instructions to bend the bits of the computer processer to do our bidding. 

Eventually, “short cuts” or “helper” commands in human language (mostly in English in the case of words like IF, THEN, BEGIN, END, ERROR, RUN, etc.)  made it easier to understand as the technology got bigger (well, smaller actually), better (subject to some debate) and faster.  The idea of the shortcuts and helpers lead to even more of those that further minimized the number of instructions programmers needed to put in to accomplish the same tasks as well as newer more processing-intensive ones. 

This trend kept going to the point where the concept of Low Code/No Code actually comes to fruition quite a long time ago now via things like “Natural Programming Languages” and “Macro Language” which was the basis of the superpower user revolution brought about by Spreadsheets like Excel.  Even Database programs like DBASE or MS ACCESS could be considered “Low Code” compared to all the instructions under the covers to make them do things in the frameworks that made them work to store and serve data. 

So you might now ask, why is the Low Code/No Code revolution a thing now when it clearly has been around forever?  This is the subject of the next part of the series where we take that “starting point” concept further. 

Until we meet in part 2