Comment by xcambar | Hacker News Reader

Comment by xcambar | Hacker News Reader

I’m going to be the devil’s advocate here and vouch for no-code.

The HN crowd is not the target, so do not expect to understand it. in fact, you should expect to NOT understand it.

I’d say that no-code tools are made with the same mindset as spreadsheets: to put into the hands of non-engineer specialists (accountants, marketers…) a subset of what engineers can already do without said tools.

it’s democratizing a (small?) part of the engineering mindset. As such, it is not a threat to engineers at all, as most of the difficult tasks of engineering are still unavailable (or hardly available) within the reach of these no-code tools.

I do not care that this or that tool is Turing-complete. Actually, I find it a vanity feature and it makes me smile at best.

Some no-code tools may very well succeed someday in some non-software engineering communities, and I wouldn’t feel threatened.

When you think about it, the music production tools have had such tools for ages and no engineer was hurt in the process.

I agree with your post and want to add a second reason why HN is not the target market - which is the number of users.

I think most people on HN are building large applications that are supposed to be highly scalable, ready to have hundreds or thousands of users.

Low code tools are often aimed at applications used by 1-2 people to perform some simple business process which would otherwise be done by paper and a spreadsheet. These users never get applications built for them because the IT team has a long list of priorities for development which come before dedicating time to make the lives of some low-level administrative clerks easier.

I built a simple billing tool in Retool in an afternoon which one person uses but which we could have never approved an IT team working on. The tool I built probably saves them 20% of their time, but if we went to IT they would have said that a proper tool built from scratch would probably take a team a few sprints to build and would have had a very long ROI because IT teams cost more than one administrator. IT teams do not want to spend the resources of several engineers to save the time of one administrator anyway.

So a key benefit of Low-Code to me is that problems can be solved in low-code that otherwise will go unsolved because IT teams don't want to / can't commit the resources to solve them 'properly'.

I would agree with your point yet the no-code tools are definitely not marketed as that. And we all know how marketing influences decisions by people remote enough from the tasks at hand. So what worries me is the prospect of having to support no-code which creeped into applications important enough to make management throw fits.

Excel is exactly what people should think of when "low code" comes up. All these other tools like Retool, Accern, UIpath, Webflow etc etc are immature and haven't fully proven their use cases, so of course they're easy for an experienced developer to start criticizing.

Ask those same developers if they'd want to use code for everything an experienced finance or accounting person uses Excel for. You can -- and there are cases where you should in fact be using Python or R. But generally, no. Excel is the perfect tool for its (very large) market niche, and all this current low / no code trend amounts to is people searching for more market niches.

It's a threat to "real" engineers mental health because they are the ones that will have to fix the cluster f*ck once it stops working.

The problem is that no-code is not well-defined. It's used to label everything from Excel to Airtable to Zapier to Webflow to Bubble to Retool.

And within that umbrella, some of them are relevant to the HN crowd.

Your examples, like spreadsheets for supply chain planning or DAWs for music production, are indeed disconnected from what developers touch. Your Ableton projects don't concern them.

But other times, the tool very much impacts developers. For instance, I work on https://www.plasmic.app, which lets marketing teams build landing pages and other content on React websites. Here, the stakes are higher when it comes to page performance, design system consistency, component reuse, and so on. As such, developers heavily vet the tool, similar to picking a CMS, and virtually all of our customer adoption was driven by developers.

So relevancy to devs depends entirely on what specific tool/use case you're talking about.

I’m a competent Python programmer and am currently using PowerAutomate at work because Sharepoint. You know what’s scary about it? I can’t really write tests. My non-technical team understands why this is a problem, but it would never have occurred to them.

Reply on news.ycombinator.com