Are Low Code/No Code tools “prime time” ready?

Are Low Code/No Code tools “prime time” ready?

Being ardent supporter of “Let’s automate if we can” philosophy, I was naturally curious regarding recent noise around “Low Code/No Code” (LC/NC) development tools. Also, realization that AI/ML technologies have shown decent improvement (in terms of effectiveness) in recent past, further impelled me to explore the state of current LC/NC tools. Current blog is the summary of understanding I formed after evaluating latest offerings in LC/NC space.

Idea of developing amazing applications and that too within short timelines is enticing and explains continuous interest in area of “Automatic Code Generators" (ACG’s) (a term that preceded LC/NC). Also understanding that it will reduce application developer’s (who are perennially overloaded and in short supply) effort further explains the reason why ACG’s seems to be regularly appearing in different avatars - it won’t be entirely incorrect to say that “LC/NC” tools is nothing but old wine (ACG's) in new bottle. “Increasing developer productivity” has been on senior management’s “wish list” and part of line manager’s KRA for almost five decades now.   

LC/NC tools come with jazzy interfaces, under the hood, however they are just a mechanism for enhancing code reusability. “No code” refers to the scenario where complete application code is automatically generated by relevant tools/platforms. Concept of “no code” excites business users (who generally don’t have much programming experience) as they can quickly create simple applications without waiting for developer’s to finish their ongoing tasks. Another less obvious reason which drives business users towards ”no code” tools is the “impedance mismatch” that typically occurs when business users explains market requirements to technical team (Business users are “generalists” whereas “specialists” dominate technical teams).

Essentially, “no code” involves some form of visual designer IDE (Integrated Development Environment) using which business users can perform “drag and drop” operation for enabling specific features in desired application. These features are prebuilt libraries/recipes that help in quickly generating apps. “No code” tools also provide ability to weave together selected components by generating code for “plumbing logic” (code to invoke modules in desired sequence and for integrating with other data sources). In contrast, “Low Code” tools requires “plumbing logic” (and certain degree of customization logic) to be hand written by technical team. In other words, “low code” tools is more enticing to technical users as these tools give them more control and also enable them to generate “boiler plate” code which they can further tailor by adding their own customization and/or plumbing logic to create fully functional apps.

Seen from another perspective, LC/NC tools are next stage of programming language abstraction trend that has shaped software industry for last seven decades (refer below illustration): 

No alt text provided for this image

LC/NC tools are overly hyped by respective vendors (for obvious reasons ??), however these tools still need to trudge a long journey before they can be considered for “serious” and “general” application development purposes. Although, continuous advancements in AI/ML space have accelerated evolution of LC/NC tools, however these tools still operate by first generating “code template” then performing “context sensitive” string replacements. By “serious”, expectation is that these tools can be used to build non-rudimentary applications i.e. moving beyond very basic applications/PoC’s (Proof of Concepts) that are limited in terms of functionality as well as performance. “general” signify the breadth of use cases (ability to cater to diverse domain and/or application needs) that can be covered by these tools. Current LC/NC tools have some relevance in UI (user interface) heavy applications (e.g. mobile applications) with minimal backend logic which further explains keen interest shown in them by business users (sales, presales, product managers etc.). Reasons why these tools still have a long way to go before being suitable for “serious” and “general” application development aren’t difficult to decipher:

1.      LC/NC tools inherently suffer from “lowest common denominator“ effect, whereby their output is (to a large extent) predetermined by tool designers based on their ability to “guess estimate” market needs - flip side of which is that it renders these unsuitable for any app development where unique/specific functionality is required. Implementation of these unique/custom functionalities invariably necessitates need to add “hand crafted” logic.

2.      Most of the LC/NC tools are sold as “black boxes” which limits the flexibility of end user for further modifications/customizations. Any change of functionality needs to follow time consuming “change management“ process with the vendor –  which neutralizes the much touted benefit of “fast app development!!”. As most of the tools in this space are proprietary and commercial, risk of vendor lock in is also high.

3.      Developers already incorporate best practices for ensuring “code reusability” as it directly benefits them in terms of reducing their timelines and improving quality - “Let’s copy paste” is part of developer community’s lingo for quite some time??.

4.      Regardless of the way LC/NC tools are marketed, these tools still require programming knowledge (basic programming concepts) for developing any non-trivial application, thus severely limiting its adoption among non-technical/business users. Additionally, there is a learning curve involved in learning/understanding features and capabilities of LC/NC tools. As most of the tools in this space are proprietary (each with its own set of bells and whistles), learning curve gets reset every time user switches from one tool to another.

5.      LC/NC tools (by their very nature) optimize just the coding phase which is but one of the phases in the overall development lifecycle (requirement analysis, architecture/design, validation/verification are equally important and time consuming phases – effort wise coding phase consumes just ~30% of the overall development lifecycle time). Additionally, integration of these tools are not easy in overall development lifecycle (in phases other than coding/implementation phase).

6.      Serious and generic application development by generating code in contemporary programming languages is much harder problem for AI/ML technologies to solve than NLP (Natural Language processing). This explains fact that although AI/ML technologies have made decent strides in application areas like NLP, text to speech, language translation, etc.; their contribution LC/NC space is still limited and there are practical reasons for the same:

a.      Natural languages rely heavily on overall context and as a result, even a sentence which is grammatically weak can be understood by the listener/recipient. However, constructs in programming language needs to be 100% correct (from semantic and syntactic standpoint).

b.      In contrast to natural language, programming languages operate at a much lower abstraction level – best exemplified by the fact that a toddler can speak/ understand natural language whereas teenager (or even adult) struggle to express himself/herself through programming languages.

To summarize, LC/NC tools do contribute to assist developers in making their development work easier by virtue of features like automatic code completion, performing rudimentary refactoring etc. As pointed earlier, these tools are definitely suitable for catering to the needs of “run of the mill” and simple applications development. Empirical calculations suggest that these tools do help to reduce around 10 to 15% of developer effort during coding phase and considering that coding phase takes 30% of the overall project effort, this translates to reasonable effort saving of 3 to 5% for complete project lifecycle.

Capability and maturity of LC/NC tools is steadily improving, however they still have lot of ground to cover before they can be considered as a serious competition to application developers.

R Madhava V.

Co-Founder, CTO at TrusTrace | Sustainability Tech

3 年

Great post as always Jasbir. To me, rather than looking at grounds up development of a new application in No Code platforms we shld look at them to extend capabilities of existing systems... Google appsheet etc pitch that way. I think for extensions they are great...

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

社区洞察

其他会员也浏览了