Gradually Disappearing Code [History of No-code]

Gradually Disappearing Code [History of No-code]

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

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

The pre-Internet days?

First computers, history teachers tell us, came on the scene in the middle of the 20th century and were at first rather unsightly (or at least very large). Programming them was the domain of engineers who had to know quite a bit about computer architecture to get just about anything done. Their work lingo was their specific processor's assembly language 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, feel free to remind them of those early programmers' predicament.

Punch cards or keyboard, the important idea to retain is that at the dawn of the era of computing, getting things done for your business meant having to know lots and lots about the computer you were using. 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 freed programmers a little bit from knowing the nitty-gritty of their computer's hardware peculiarities. Fortran also made the process of coding much faster and much less bug-prone, thus giving us more portability, productivity, and reliability. Cobol and Algol followed a few years later and further improved on all three dimensions.

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

The Internet era

The explosion of the Internet in the 1990s brought us the first truly modern language, JavaScript, which should probably have some sort of a title for having been incorrectly explained and/or introduced more than any other programming language in history (suffice it to say that it neither is a scripting language nor does it have much to do with Java, 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 not just a separate article but a book (or several), what's particularly interesting about it is that it took another, often under-appreciated step in the direction toward more abstraction: it allowed programmers to manipulate the "document object model" underlying every web page. At first, people were content with handling low-level page elements, like titles, paragraphs, and table cells, but pretty soon, libraries started appearing that made the list of objects to manipulate much longer and the abstraction powers – much greater. This is how we eventually got to enjoy the monster-sized frameworks like Angular.

Right tools for the job

Though one could make the argument that using a library or a framework doesn't completely liberate the programmer from having to code something, the important point here is that the structures and concepts being "programmed" (or manipulated by code) are getting more and more high-level.

A similar trend affects business processes. Gradually, businesses tend to develop their own "vocabulary" of objects and operations, which get farther and farther from their low-level representations. These concepts need to be expressed in appropriate abstractions.

To give an oft-used example, imagine having to program 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 language like Python – from data formatting to calculation to graph plotting. Thus, you definitely can “program” your spreadsheets and get usable results. But who would want to? Think of the barrier to entry (a business analyst or an accountant would need to learn Python *before* they could make anything useful at their job), lost productivity, and the time wasted going about a simple business task in a very roundabout and inefficient way. And in the end, unless there was a highly specialized requirement to implement, it would be almost a certainty that simply using Excel would have produced a better result.

Excel is far from the only no/low-code application that revolutionized a particular business task. Nearly all specialized software packages today can be utilized to create great products with zero knowledge of coding. Examples are legion. Most bloggers happily type away and publish essays, unaware of the internal workings of Wordpress or Medium or Substack. Musicians can sculpt their sound and design unique electronic instruments using point-and-click interfaces of programs like Max.

Learn more about No-code and Low-code in our recent comprehensive guide

The key for any business project to be successful 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, it should be. Some things can't be done completely without coding (at least, not yet) and those need to be programmed.

The difficulty, therefore, lies in properly structuring a business project and determining which parts of the puzzle can be handled by no-code tools, which should be implemented in low-code, and which leave you no choice but to roll up your sleeves and code it the old-fashioned way.

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

Furthermore, you can leave both the structuring and the coding part (if necessary) to a trusted partner. May we humbly suggest our own agency? With over 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 business meet 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 you need a custom tool for, don't call head-hunters… at least not before you talk to us: a solution may be ready faster (and cheaper) than you have thought possible.

If you have an IT product idea that you would like to launch for your business, then feel free to contact us for a free consultation. We will tell and show you how you can realize it 5 times faster and cheaper leveraging No-code approach.

要查看或添加评论,请登录

Xmethod - Nocode Development Agency的更多文章

社区洞察

其他会员也浏览了