Comment by codingdave | Hacker News Reader

Comment by codingdave | Hacker News Reader

Parent Full thread

I do not believe the concept of low-code to be hype. It has existed in one form or another since at least the 80s. Lotus Notes, Sharepoint, and finally Salesforce were always the enterprise powerhouses in that arena. And they also show its weaknesses, because they all have taken serious reputation hits due to poor apps written by inexperienced developers. Still, I'd estimate there were dozens, if not hundreds of small low-code apps in every large company I've been a part of, for my entire career.

The bigger question in my mind is quality. Almost all those apps, if they became a success within the business, eventually were given to the professional software folk in IT, who would fix them up and make them really work. At some point, low-code needs to be migrated to high-code.

So for all the smaller and newer players in the space, I have high hopes that some of them will become terrific solutions. But I don't know which of them truly understand the life cycle of a low-code app, nor do I know which of them will still be around in 5 years, so I'm hesitant to put much work into them today.

Interesting, based on this experience, what must-have criteria would you look for in evaluating a tool? Ability to export the code if the tool proves too constraining? What else?

It is not so much about the tool helping a future dev re-invent the solution in a high-code platform. It is more about preventing lock-in. I'd like to see a vendor whose business model embraces the fact that their most successful apps will move to something more powerful. Where they consider themselves to be a stepladder up to a fully developed app, and not a platform that will take over all of enterprise IT. So they would be more of an internal app incubator, not a permanent app hosting platform, focusing on service to their customers, and therefore when it comes time to move on they are a fully engaged partner, not an adversary.

At the same time, it would be terrific to help the devs on low-code platforms avoid mistakes. Flag redundant data, point out when they have written sub-optimal workflows, give them easy ways to implement re-usable code blocks when the system notices they just wrote the same function twice with one parameter change. Data imports are also always a struggle, because most anyone can figure out how to get a CSV or Excel file brought into a system, but reading from a web-based endpoint, or parsing data from Word files tends to be beyond the capacity of most users, even if the system itself supports it.

I run a nocode platform with some large and global applications made/run on our platform.

During architecting phase of the application - we do estimate if nocode tooling will hit a ceiling. If yes then we explore 4 options:

- no brainer, export code and take it from there

- write custom Ui controls and patch them into your nocode tool

- write custom function and patch in the workflow engine or front end logic

- build Ui/UX using external code and use nocode to build backend process and connect front end with apis of the workflows/dbs

- generally complex algorithms - eg route optimization, would become a candidate of converting into a web service and eventually consumed in the nocode tool.

In my experience - One of the core essentials to write an application on nocode is having your sprint 0 dedicated towards a design phase.

Reply on news.ycombinator.com