Gradually Disappearing Code

With all the media buzz surrounding no-code andlow-code development, one could be forgiven for thinking that these twoconcepts represent some brand-new inventions. But do they really?

For years now, our company, Xmethod, has beennot only tracking, but applying these approaches in various client projects,which we think affords us a certain perspective. So, let's dig a bit deeperinto how no-code and low-code came to be.

The pre-Internet days

First computers, history teachers tell us, cameon the scene in the middle of the 20th century and were at first ratherunsightly (or at least very large). Programming them was the domain ofengineers who had to know quite a bit about computer architecture to get justabout anything done. Their work lingo was their specific processor's assemblylanguage and instead of an IDE they had to contend with a punch card reader.Whenever you hear a software engineer complain about their work tools, feelfree to remind them of those early programmers' predicament.

Punch cards or keyboard, the important idea toretain is that at the dawn of the era of computing, getting things done foryour business meant having to know lots and lots about the computer you wereusing. From this low starting point, however, things started improving.

One early improvement came in the form of a"formula translation" language better known as Fortran, which freedprogrammers a little bit from knowing the nitty-gritty of their computer'shardware peculiarities. Fortran also made the process of coding much faster andmuch less bug-prone, thus giving us more portability, productivity, andreliability. Cobol and Algol followed a few years later and further improved onall three dimensions.

In very broad strokes, one can say that from the1960s on, programming languages have been getting increasingly sophisticatedand increasingly abstract. It was getting easier and easier to formulate what"needed to be done" and leave the compiler (or the interpreter; let'snot get side-tracked discussing the differences here) to work out the details.

The Internet era

The explosion of the Internet in the 1990sbrought us the first truly modern language, JavaScript, which should probablyhave some sort of a title for having been incorrectly explained and/orintroduced more than any other programming language in history (suffice it tosay that it neither is a scripting language nor does it have much to do withJava, which had already existed when JavaScript launched). It's a language that"lives" inside every browser we use today – Chrome, Safari, Firefox,Brave, or Edge, though it has also migrated to the server side since.

Though the full story of JavaScript deserves notjust a separate article but a book (or several), what's particularlyinteresting about it is that it took another, often under-appreciated step inthe direction toward more abstraction: it allowed programmers to manipulate the"document object model" underlying every web page. At first, peoplewere content with handling low-level page elements, like titles, paragraphs,and table cells, but pretty soon, libraries started appearing that made thelist of objects to manipulate much longer and the abstraction powers – muchgreater. This is how we eventually got to enjoy the monster-sized frameworkslike Angular.

Right tools for the job

Though one could make the argument that using alibrary or a framework doesn't completely liberate the programmer from havingto code something, the important point here is that the structures and conceptsbeing "programmed" (or manipulated by code) are getting more and morehigh-level.  

A similar trend affects business processes.Gradually, businesses tend to develop their own "vocabulary" ofobjects and operations, which get farther and farther from their low-levelrepresentations. These concepts need to be expressed in appropriateabstractions.

To give an oft-used example, imagine having toprogram a few spreadsheet formulas in a programming language. To be sure,everything you can do in Excel (and much more) you can also do in a languagelike Python – from data formatting to calculation to graph plotting. Thus, youdefinitely can “program” your spreadsheets and get usable results. But whowould want to? Think of the barrier to entry (a business analyst or anaccountant would need to learn Python *before* they could make anything usefulat their job), lost productivity, and the time wasted going about a simplebusiness task in a very roundabout and inefficient way. And in the end, unlessthere was a highly specialized requirement to implement, it would be almost acertainty that simply using Excel would have produced a better result.

Excel is far from the only no/low-codeapplication that revolutionized a particular business task. Nearly allspecialized software packages today can be utilized to create great productswith zero knowledge of coding. Examples are legion. Most bloggers happily typeaway and publish essays, unaware of the internal workings of Wordpress orMedium or Substack. Musicians can sculpt their sound and design uniqueelectronic instruments using point-and-click interfaces of programs like Max.

The key for any business project to besuccessful is to select the right mix of tools and abstractions and then... execute. Fast. If something can be done in a code-free way, chances are, itshould be. Some things can't be done completely without coding (at least, notyet) and those need to be programmed.

The difficulty, therefore, lies in properlystructuring a business project and determining which parts of the puzzle can behandled by no-code tools, which should be implemented in low-code, and whichleave you no choice but to roll up your sleeves and code it the old-fashionedway.

Wait, you're probably saying to yourself. Sothis "modern" process seems to have gotten more complicated thanbefore: not only do you need to know how to implement those things that need tobe implemented but you also have to be able to decide which parts of yourproject you should not code. How is this progress? Well, it is, becausethese sub-problems are now more manageable and can be solved faster.

Furthermore, you can leave both the structuringand the coding part (if necessary) to a trusted partner.  May we humbly suggest our own agency? Withover 150 projects under our belt, and utilizing our signature blend of no-code,low-code, and full-stack solutions, we are always ready to help your businessmeet a new challenge – whether it be an internal planning system, a custom CRM,or a new app. We work fast (most projects can be completed in just a few weeks)and our rates will pleasantly surprise you. If you have a business task youneed a custom tool for, don't call head-hunters… at least not before you talkto us: a solution may be ready faster (and cheaper) than you have thoughtpossible.