No-Code and Low-Code Software Is a Disruptor You Should Pay Attention To | Hacker News Reader

No-Code and Low-Code Software Is a Disruptor You Should Pay Attention To

inc.com

13 pointsecliptik11 comments

This is definitely an underappreciated thing. There is no reason an awful lot of programmy stuff can't be automated away using gui doodads that morons can use. The entire UI profession of hand coding up HTML and javascript on an electron (or web; whatever) app is a total make-work program: this problem was solved decades ago with drag and drop gui tooling. Most of EC2 type stuff could be drag and drop; drag and drop works fine on other platforms.

Something like Labview applied to common devops workflows could be an extinction level event for a lot of people on HN. People have no idea how bad interfacing equipment to the outside world was before Labview. I think the only reason tech like this is kept out of the current year is the popularity of open source software. The first company to adopt it will slay on labor costs.

This has been the case for a while. For lack of a better term, I call it the Word Press Effect, where a less-technical person can put together a functional PoC that makes money.

Eventually, they hit the limits of their technical skills and they need to hire talent to expand their business. This is good for programmers, IMHO, because companies seem to be much more willing to pay when they have a business entirely dependent upon some software. It's still totally possible to make a good living consulting on WordPress sites.

> Instead of taking weeks or months to develop a custom application, it can be done in a few hours or days.

In other words, "pile up massive amounts of technical debt"

That's a bit snarky.

I've been engineering software for a long time and I've never come across a code base (associated with a successful product) that was debt free.

Perhaps a bit snarky, but sincerely spoken.

This concept reminds me quite a bit of the "applications" I've seen floating around in big companies. They are creations of convenience, based on MS Office documents because there weren't any real programmers around. They may have been initially fine, but grow and grow until they are completely unwieldy. By that time they are critical path and mission critical, and nobody can handle the complexity.

Then that is a failure of management – that they didn't make the proper investments when the time came. It doesn't necessarily mean that taking on that debt early on didn't make sense.

I mean, so what though? I feel like we complain about technical debt often without acknowledging that the point of taking on debt, traditionally, is to capture potential growth. Sure it'll be a hassle to be the guy who has to handle the eventual revamp, but that's just a reason for that guy to ask for more money. At the point of turning a week into hours you're playing a totally different game than you were before.

> that's just a reason for that guy to ask for more money.

It sounds like you're arguing that technical debt is no big deal because you can leave for greener pastures before the bill for that debt comes due. Am I misunderstanding you here?

I work at a non-IT place & am seeing these types of low/no code automation attempts first hand. It's equal parts inspiring and terrifying to see.

Inspiring because they are actually getting stuff done.

Terrifying because they lack all the basic caution programmers learn over time. (Don't test in prod etc)

Nor are the safety rails programmers assume are there necessarily in place in non-IT shops. e.g. Roll back mistake with version control

Interesting times ahead

I've seen this, and it's horrific.

It was 2008, and I worked for a large investment bank (think in the Goldman Sachs echelon). I was on a transition team moving risk analysis for $1bn in synthetic CDO assets from Excel spreadsheets to a formal system.

There was zero documentation. Formulas were not internally consistent. Their version of version control was saving a new copy of the spreadsheet every day. Their version of day-to-day analysis was copying tabs with a specific naming scheme so that the macros would pick up yesterday's data properly.

Have you ever seen a spreadsheet generate XML? Shell out to a command line program? Import the XML that command line program generated? Generate a CSV file? And then FTP that CSV file to a central reporting system?

I have, and it haunts me to this day.

haha yes exactly that.

Finance crowd with VBA macros can be daunting once they've built an edifice that is as unstable as it is mission critical.

Noobs armed with RPA point & shoot cannons isn't far behind. Only a matter of time before that ends in a self-inflicted data leak.

Reply on news.ycombinator.com