Richard Bucker

No Code

Posted at — Nov 15, 2020

Many years ago when the “internet” was just a bunch of BBS', AOL, Compuserve, and ham radio packet networks I deployed a customer helpdesk application based on a no-code framework engineered by CA (Computer Associates). Over the years technologists and computerphiles have been prognosticating the idea of non-programmer programmers. The typical business maanger cannot manage programmers and programmers are a lot like cats. The business side seems to think they are the smart ones and the programmers do too. Both have an inflated sense of self importance… At the end of the day we are all just digging ditches.

Just as we move from monolithic systems to microservices and VMs to containers; most would-be problem solves take a stand until it’s time to migrate. One programmer’s microservice-mesh is a devops http router (see haproxy). It’s easy enough to argue both sides or either side.

No-code or low-code might be interesting, however, it will eventually swing one way or the other and most miss the real problem.

The problem is that when the developmen team chooses a language [a] they accept all the CONs that the language presents [b] at the end of the day it may cost you 2x or more to replace it if you are not going to embrace the language for all time. The same can be said as the language reaches it’s EOL specially if the source is not available or you do not have the skills to take over.

COBOL and fortran have been around since the 1960s. There is little or no interest in these languages. Sure there are still some applications out there but as mentioned in a SANS Panel this code and the compilers are old and deprecated and have their own security risks.

If you adopt Node.js there are interesting challenges in the depth of the dependecies and the potential for bad code not to mention the readline problen.

Golang nd Rust have their own issues. And anything from Microsoft comes with a tax.

Work from the position that the algorithm is separate from the compiler/interpreter. It may not be no-code but it may be familiar code. Business people can read the code and understand the concepts even though they might not be writing it. And maybe they will write some when the business demands more programmers.