Low code – how much of the promise can it really deliver ?


This blog you are reading is written on a “low code” system – it is a wordpress blog where I have not used any custom coding at all. I could have – and I am an experienced developer. And yet I chose to not even touch html or CSS because it works for my limited purposes. Few hundred thousand people have checked out my blog in the past – and literally no one has asked me yet anything that needs me to write some code. At the most – I will need to switch color schemes or font or pictures – and none of that needs me to write a line of code.

What works for me will not work for a larger and professionally run web property like Diginomica for example . They need code – lots of code. And if you go to an even bigger media company like NYT or WP, I can only imagine the talent, tech and processes they need to run it.   There is no way that 90% of Diginomica, let alone NYT can run with low code tooling today. Some day in future it may be possible – but I can’t even do any speculation on how long that is going to take.

What triggered my rant here 

This article Unqork CEO – ‘Agile has failed on Diginomica got shared on my twitter feed. That served as the inspiration for this blog. It had a catchy title – and I have criticized the poor use of agile and scaled agile  a few times in the past  . I opened the article thinking the Diginomica gang has uncovered a new angle on this. Unfortunately not only did I not find a new angle, I got very frustrated by a weird conflation of agile and low code, and some poorly articulated assertions on the applicability of low code. Usually Diginomica takes a critical take on the topics they cover – and that is the primary reason for me being a loyal reader. This one unfortunately did not cover the “so what” aspect – and honestly that disappointed me.

The fundamental premise is illogical – and poorly articulated

First – Waterfall and Agile are ways to execute a project or build a product from a methodology perspective. That has nothing to do with the actual tech that is used. For example – MongoDB came into being after Agile became popular. So if NASA did a waterfall project – should they avoid using MongoDB because it is more modern and hence only fit for agile ? The line of thinking itself is ridiculous . Now substitute MongoDB with low code tool of your choice and the silliness of that argument will be even more evident.

Second – between Waterfall and Agile is squeezed “there were vendors that claimed they could build you everything you needed into one package/stack” . I don’t know what to make of this. Incidentally, those solutions – like say SAP or SFDC – also can be implemented in Waterfall or Agile. It is a terribly illogical way to segment it on par with Waterfall and Agile.

Third – Agile has not failed universally. Poor execution of agile leads to failures as I called out above in the links to my past blogs.  But there are plenty of Agile success stories all around us. Since we already used SAP as an example – they deliver their product using Agile and so does SFDC and Workday and so on. So the fundamental premise of the title itself is flawed.

Now back to the idea of low code itself.

The principle of low code is a VERY good thing

Code has a tendency to become a liability the moment you finish coding. I am all for being a minimalist when it comes to coding. This is why engineers encourage re-use, why we establish frameworks, why we standardize tooling to the extent we can, why we encourage automation , why we like “shift left” and so on. In theory, I would expect low code based apps to be lower in maintenance cost.

We all like to do things better, faster and cheaper. Any tooling that promises that value is worth checking out. Time is precious for business and technology people.

And finally – there are only a small number of good developers to go around. Low code tooling goes a long way to mitigate this problem.

And yet, with all my positivity about low code – I think what the Unqork CEO is saying here is very far from reality today, and for foreseeable future.

You could build anything you can imagine without me needing to write a single line of code or generate code, because we think that’s also legacy. So the idea is to stop writing code, stop legacy. 90% of what any company does today, we could confidently do on Unqork without a single change today, without a single line of code. The last 10% is where 100% of their engineers should be building. Right I would say that that last 10% is purely APIs, interfaces that engineers are building that are unique to them

Low code is not new – we have lived through several avatars of this over the years. I remember SAP coming up with Visual Composer  something like a decade ago. It did not go very far. SAP was not the first – and things did get better over time. I am a fan of lighting platform that Salesforce introduced and it has several nice low code features. But even in salesforce projects – it is rare that 90% of the work is on declarative side.

Of course – history of failures is not something to worry about too much in tech. Tech usually improves with time .

A strong start to the low code story  does not mean it usually ends well

Time to market is absolutely a critical business driver today. Low code is a big help in proving out something as an MVP – as a prototype or pilot. If business likes it – great, and if they don’t you can throw it away with very little to write off. That is the good part. But that is not how this story typically unfolds.

Business will love the first version, especially the speed at which it got delivered. They will add a few more things to be done by the app. Most of the time – low code tooling can get that done too in record time. Then along the way – a high value requirement will come along which cannot be solved by the low code tooling . So it gets handed off to an engineer to enhance. This is where it typically picks up downstream momentum . There is a good chance that there is no way to make that enhancement without a significant rewrite. There goes time to market for a toss !

Mobile might be the hardest problem

Mobile is a harder problem to tackle than web. To get the best experience – I don’t think there will be a lot of debate that it is hard to challenge native development with generic tooling. Device integration, performance , Mobile UX are all hard to perfect without going native from what I have seen. If your experience is different – pls leave a comment, as I am very curious on this aspect especially.

Technical compromises just defer the costs

Low code ( and similar templated tooling that goes by other names) all are built with “general” requirements in mind. That comes with some obvious constraints – like the tooling expecting pre-existing APIs (in an enterprise world that is largely built as monoliths – or poorly designed/implemented APIs ) , some limitations in logic that can be implemented by drag/drop/click, and often performance limitations. That is the price you pay for faster development cycles. That is the price you pay with interest when your successful app gets asked to do more ! And if the tool can be extended – you have to ask yourself if it is “low code” anymore 🙂 .

There are indirect costs 

Low code also has some organizational costs that only become evident when you scale. A lot of the products are sold to business users with the promise “It is inexpensive, and you don’t need to wait on IT to get what you need – you can do it yourself”. Soon you have a proliferation of apps ( or reports or dashboard or whatever ), a lot of unused licenses/subscriptions,  and there is tremendous friction with IT ( traditional developers ) , and between business users. The typical solution – establishing a COC to “guide and govern” the low code system. Before you know – the COC gets bloated. And they put way too many constraints on governance (with good intentions usually) that the original time-to-value advantage is not true any more.

To conclude

I think low code tools absolutely have a definite place in the tool kit. It needs to be used for what it is good for – and that expectation should be clearly set with the customers who buy it. Over time, like with all technology – I totally expect low code to solve more of enterprise problems. But for now – I think claiming only 10% of scope needs engineers is an extreme overstatement.

Advertisements

One Comment Add yours

  1. Tom Murray says:

    Spot on analysis and summary VJ. Like you My point of view and have a lens of addressing larger enterprise wide client issue/needs. Low code tools have a definite place in the tool kit. Expectations need to be set with the client/customers. Absolute statement of agile is dead is a stretch. Like you agree over time, Over time expect low code to solve more of enterprise problems…for the moment and what Insee in marketplace with clients I serve – 10% of scope number overstatement.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s