Hacker News Reader

Comment by ignoramous | Hacker News Reader

I think the basic reason why low-code / no-code works is down to software bugs.

Bugs are a function of number of engineers, features, moving parts, and significant lines of code.

No-code takes out engineers, moving parts, and SLoC from the equation (as far as the enterprises buying these solutions are concerned), but leaves a lot to be desired in terms of feature set; low-code brings down number of engineers, and SLoC, whilst providing flexibility in terms of bespoke feature sets.

Also, another reason is, in essence, No-code and Low-code are natural extension of the cloud computing model in which capex is traded away for opex. And economies of scale, over time ensures, Low-code / No-code is going to be cheaper yet more reliable than anything one (tech-enabled) enterprise can roll on their own.

View on HN

Excel-based solutions are almost infamous for being fragile and buggy. Excel itself is quit reliable, but so is javac and gcc.

Low/no code seems like they’ll eliminate some types of bugs but probably not the ones that really hurt (it does what I told it to do, but what I told it to do was non-sensical).

I was recently looking at Bubble.io. The main reasons I didn’t like it was it didn’t have version control, it wasn’t easy to test, and the UI wasn’t that intuitive for the types of things I like to do. When I started thinking about it, I basically realized is that by the time one adds all the features I’d want, it’d no longer be a no-code tool. So as a developer, I’m not concerned about being replaced by a no-code tool, because it’s literally can’t be appropriate for solutions that require code.

And I believe we've had a swing in culture of preferring the system/compiler to point out -possible- errors at the expense of "just working". Aka js -> typescript and c/c++ -> rust.

I do firmly believe that the subtle bugs of "this seems to work the way I intended" is far more nefarious.

Albiet this is something that can be aleviated with better tooling, which no-code stuff generally lacks (how do you debug your kizmit code?).

I remember spending many hours trying to debug what was going on with teamcity and just ultimately wishing I could get a fully dumped XML describing the config rather than going through every single damn menu item/config drop down. (I believe Tc only allowed a partial XML config of the current screen and not the whole build process).

Well said. This is exactly what we find when building applications with Lowdefy [0]. Because we are writing applications in a “schema”, implementations becomes more and more consistent. To the point where if I pick up an complex application written by a colleague, it takes me only minutes to understand what has been done and start contributing. In an enterprise space, this greatly reduces risk in project handover.

Since the logic operators and ui blocks are consistent and tested across all apps, code errors reduces over versions. But implementation errors still exists. This normally happens because the app builder does not fully understand the application data.

So by using a DSL we effectively reduce the moving parts. With the remaining problem being - does the developer understand the data - and as a business, this is where you want developers to spend their time to extract the most value.

[0] - https://github.com/lowdefy/lowdefy

> Because we are writing applications in a “schema”

I call this "metadata-driven programming", and try to use it whenever I can get away with it. It's amazing what you can pull off with a FSM, external configuration, and some ingenuity.

Totally. Most developers stop at decoupling the ui components, backend connections etc. It is not very common to see developers extract the application logic to be configurable from these components.

Logically loaded React classes is a common example of this. Filling up these components with bugs and making them hard to test.

Once I experienced how well it works to abstract logic from components my code simplified immensely and writing good tests became easy. And then making the logic configurable truly elevated the capabilities of our “meta-driven programming”.

You ought to have a look at the Zapier zapps our marketing team has created. Buggy, brittle, and just oh-so-better than nothing.

For Budibase, we often hear enterprises talk about two reasons for their interest: Cost of devs Speed of delivery (leading to faster growth and operations)

That's kind of funny. Back in the early 00's I built a big perl "engine" for an internal LOB platform which roughly looked like your product. The business built their apps on it. But neither me or the business saw the value in the platform on its own. Big fail - perhaps I could have been the original Salesforce.com or something...

I’m really excited by Budibase but having some trouble getting up and running. Do y’all have any open work sessions for questions or demos? I found some on YouTube previously.

Reply on news.ycombinator.com