Hacker News new | ask | show | jobs
by matus_congrady 1287 days ago
For me, the main issues of low-code/no-code tools are:

1. Leaky abstractions. Our industry has been developing software for decades, and we almost generally agree that MVC-like architectures offer the best ratio of flexibility-to-productivity. How am I supposed to trust that an abstraction made by the low-code/no-code tool will allow me to implement even a slightly less-common use-case? When I use these tools, I'm constantly 1 use-case away from having to throw everything away and start from scratch using something else.

2. It doesn't solve the most prominent problem - designing the system. Implementing the software is in fact very straightforward and isn't that time consuming. On the other hand, having to think of all the use-cases that your application needs to support, thinking of all the edge-cases and less-obvious quirks is 2 orders of magnitude harded.

3. The highest degree of vendor-lock.

4. Not clearly stating what their limitations are.

I'm not entirely dismissing the idea, and I believe these tools can be helpful in some cases. But I believe that more often than not, people don't get the promised outcome, or even if they do, it doesn't come without significant tradeoffs.

In my oppinion, the better approach to save the time of your development team is to just give them better tools. Tools, that don't require them to completely dismiss the workflows and architectures they are used to. But rather tools, that just improve and simplify what they are already doing.

This was also my main goal when designing https://stacktape.com

I wanted to create a tool, that provides the highest possible level of simplification of DevOps, while at the same time being flexible to cover any-use case. I also very clearly state our limitations - it's only for AWS. If that's a dealbreaker, you won't need to spend 2 weeks to figure that out.

1 comments

I think the end goal of most low-code/no-code tools to be something where you can get an 80% solution without hiring a real engineer. The second part of that sentence is really important.

Should large businesses going to build their most critical functions into a low-code solution? No, not at all. But one slightly technical person in e.g. the marketing department can unlock a lot of business value but automating a few workflows.

Salesforce does this pretty well. Allowing users to put something together to automate a business process quickly.

Their concept of custom tabs, custom objects, fields, page layouts and the way different layouts are assigned to groups of users by profile make it easy to stand up a lot of record keeping and management that's needed in a lot of plain boring business.

Granted, Salesforce is so immensely wide and deep that many of those advantages get lost in the complexity of the platform itself.

This is exactly something I don't necessarily agree with.

I think that this "slightly technical person" won't be able to create that application/workflow with a sufficiently high-enough quality.

Is he going to think about all of the edge-cases? Does he know how to properly validate user inputs?

Also, quoting from the article: "Interestingly, while low-code/no-code are seen as the tool of citizen developers, its primary users are IT professionals, the Capterra survey also shows."