Low-Code/No-Code limitations

Read this article tonight and was a bit surprised. I hadn't really read many articles against this strategy outside of perhaps developers feeling threatened or generally spread FUD because they feel threatened.

Was interesting because I specifically dislike low and no code platforms, but not out of any sense of fear. And the linked article is the closest anyone has gotten to expressing my concerns around it. Now, don't get me wrong, I DO feel that these platforms have a place. But, I think that is mostly for savvy end users or quick fixes from a services perspective.

As the article points out, these platforms tend not to be Turing complete. Which is the understatement of the century. They often fall FAR flat of Turing completeness before you need to get more advanced and either write code, or change platforms if the platform can't support your needs.

Anyone working in the software field knows this; requirements never remain static and they rarely get simpler.

I have two general beefs with low and no code strategies; they treat developers like idiots and they don't give them a chance to own the code. Now, you can tell from that statement, I'm looking at this from a software developers perspective.

SDKs and templates are the right way to go. But, keeping those concerns in mind, it is also important how you go about implementing these things. My first experience with an internal SDK had a lot of generated code which was "Ok" because there were also templates which could be modified to change that code. But, not great because most classes were split into two with a "safe" to edit portion and the more heavily templated "generated" code. And then there was the mountain of deep reaching compiled libraries which were used as a crutch.

Addressing the generated code first. 95% of the time you could accomplish what you wanted inside of the "safe" portion of the implementation. Which meant that most developers never needed to open the "generated" files. Which in turn meant that they often didn't know what went in there. Some didn't even know they existed. But, often they were even larger than the portion of the code which the devs worked with. Incidentally, this sounds an awful lot like the same sort of problem with low-code solutions. Because it is. While the intent was not to treat developers like idiots, the outcome was the same.

The result? There were a few developers who truly understood the platform and a LOT who did not. They were crippled as developers. Their growth stymied. The code was there, and they technically could have gotten into, but it was well hidden. When I had the opportunity to write my own SDK, this was one of the first issues I addressed. Code generation is wonderful and can save a lot of time. But developers cannot be spared the burden of at least having to understand what was generated.

The next issue was the compiled DLLs. Again, no problem with compiled DLLs in general. But, such files should be sparse, configurable and wherever possible optional or at the least, replaceable. 

In our case, once again, we were doing far too much heavy lifting. Basically, the entire guts of the web service was hidden and configured in compiled code. It would have been near impossible to retrofit it to an existing application, and it was just as impossible to make technological leaps forwards using it as a basis. This lack of flexibility is actually what I owe the opportunity I had to write my own SDK. We simply could not reuse the existing code for where we were headed.

So, when I wrote my SDK, each piece of functionality implemented an interface or abstract class and was registered using .Net Core's dependency injection framework and components were made as independent as humanly possible. I was completely possible (and frequently done) to selectively disable un-needed Platform features by simply commenting out a line of code from the generated template. Or to replace a service (once again, actually saw this used).

It was easy to compare the teams that worked with the two different SDKs. Those who worked with the newer SDK which avoided some of the low-code pitfalls of the earlier SDK were the more proficient software developers in general. And they were learning and applying more generalized skills. They could use what they learned and apply it in future endeavours and we could also more readily hire existing Asp.Net Code developers and get them integrated as well. It was a win-win.

My past experiences may be a bit biased. But, I don't think software developers will ever be wholly replaced by no-code or low-code solutions until they reach a point where they are every bit as complex as simply writing code.