
The Many Flavors of “Low-Code” - galaxyLogic
https://www.infoq.com/articles/many-flavors-low-code
======
rpeden
As someone who writes code for a living, I have to admit I'm intrigued by "low
code" software development tool. Or at least tools that use less code that
traditional software development.

I don't see writing code as being the main value I deliver. Instead, I see
that value as being the ability to take high level and often vague business
requirements and turn them into something a computer can execute.

Sometimes, I'll use tools like Node RED and Unreal Blueprints and can see the
value their kind of approach would bring to application development. I write
code where I need code, but can define data flow through the application
visually by connecting components together. I find that this helps me
understand at a glance an applications inputs, data flow, and outputs. I'm not
sure how well this would actually scale, though. It's not like this approach
hasn't been tried over and over for the past few decades.

~~~
petra
>> I'm not sure how well this would actually scale, though. It's not like this
approach hasn't been tried over and over for the past few decades.

I'm not sure either, but i remember reading about hospital management software
for the middle east implemented using low-code.

So maybe, the current software ecosystem, which is brilliant for innovation,
finally found the trick ?

------
munk-a
My personal favorite[1] for low code is Excel - nothing is quite like trying
to budget time to support the work other departments are doing (sales,
accounting, BI) and get redirected at "pure development work" only to end up
having to either convert or support the complexities someone built into an
Excel spreadsheet over a period of two years.

Low code is, IMO, at it's best when it's restricting the solution set to a
small category of problem, the more specific the better, and the more limited
the the low code is at it's ability to interact with that problem the better
as well - I've always ideally viewed CSS as a sort of low code setup like
this, the backend will render some complex tags in a reliable format - then
the UI folks can go through and mark it up as needed to make it pretty... CSS
has, I think, failed to deliver on this goal at this point - UI/UX has always
ended up needing to rework the markdown in some way to make things mesh well -
and with react it's losing even more power, but I was hopeful about it for a
time.

[1] /s, just to be clear.

~~~
walshemj
OH lovely having worked at a company that in part was derailed by some opaque
excel spreadsheet - you will have to forgive me if I am not so sanguine.

------
nostrademons
It feels like we always get a bunch of "low code"/"no code" solutions right
when one computing paradigm is nearing maturity and the next computing
paradigm is just getting started. Ironically, we get them on both sides - the
mature technology gets commoditized by tools for business planners, while the
new technology is still toy-like enough that you can do interesting stuff
without hardcore CS knowledge.

The end of the minicomputer era (1981-1986) gave us rules engines and expert
systems for minicomputers, and spreadsheets for PCs. The end of the PC era
(1995-2000) gave us Visual Basic and Delphi for GUIs and HTML, Flash, and
"View Source" for the web. The end of Web 2.0 (2007-2009) gave us website
builders and Flash game builders for the web and Interface Builder for the
iPhone. We're reaching the end of the web/mobile/cloud era, seeing a lot of
those domains being commoditized, and yet blockchains still feature mobile GUI
wallets and cut & paste token contracts.

In between transitions, when the next computing paradigm is growing fast, you
actually need to know how to code. Performance gets pretty important when
people actually start using your product, features need to be pumped out
before the underlying platform is ready, and best practices aren't yet well-
known.

~~~
tabtab
Re: _Performance gets pretty important when people actually start using your
product_

Depends on your product. Facebook and Twitter require a mass audience to be
viable, but not all businesses rely on the "network effect" for success. There
are a lot of niches with a small audience.

~~~
nostrademons
The "niche product for a small audience" business model is itself more popular
at the edges of a technology cycle than in the middle. At the beginning of a
technology cycle, the infrastructure is primitive, the markets are unknown,
and so entrepreneurs have to look for small markets of passionate early-
adopters that don't care about how primitive the technology is. At the end of
the technology cycle, the really big use-cases have already been filled by
giant companies that you can't realistically compete with, so you have to look
for the smaller niches that aren't worth it for them to enter.

In the middle of the technology cycle, when the mainstream market is aware of
the technology but sitting on the sidelines waiting for it to become useful
and the infrastructure is just barely getting good enough that you can build
high-quality consumer products, there's a mad land-grab to gobble up these
giant markets before anyone else does. That's when coding ability is really
crucial, because the infrastructure is not yet good enough that just anyone
can build a product that's "good enough" for a mainstream market, but it's
good enough that the really skilled, dedicated, and talented can.

------
sytringy05
Low Code / BPM / Doodleware solutions are always the pits. Instead of letting
you write code, we will give you either a half arsed UI (always Eclipse based)
that spits out a million lines of horrific XML, or else they will give you an
insanely complicated UI, that spits out a million lines of XML. And there's
always a "script node" or "java callout" that end up with 90% of the smarts.

And I hope you like testing in real environment (SIT or Prod, sometimes you
get to choose!) as they are almost always impossible to unit test.

For a sensible perspective on low code, as always, Mr Fowler has some well
thought out advice:
[https://martinfowler.com/bliki/BusinessReadableDSL.html](https://martinfowler.com/bliki/BusinessReadableDSL.html)

~~~
neurobashing
As someone who works on a "modern" low-code platform, your comment reads like
someone who hasn't used the state of the art.

I've had to manipulate actual XML maybe once in a year; and usually because of
an insane legacy DB schema. I'm sure it happens but I don't see it much. In
fact XML isn't a huge factor. You know it's there, but you don't really care.

Also they aren't "always Eclipse based", lately they are browser-based, which
will irritate people just as much (but the web is something more of a "growth
market" than Java IDEs).

Modern platforms have built-in testing suites. I have seen individual rules or
UIs with hundreds of tests. (Process models remain hard to test, though, much
to everyone's frustration)

The plugin problem is real, even in modern platforms. That said, pick any
platform - the web browser, an IDE, even a game engine. For a lot of users,
entirely dependent on plugins. It's just part of life.

~~~
sytringy05
What's an example of a state of the art platform? If I have used one I didn't
realise it was good (and although I do use one of these platforms on a daily
basis, it is old, eclipse based).

The browser based ones also drive you crazy, at least you can right click to
find all the hidden configs on the IDEs...

I agree plugins are a real problem.

------
tabtab
In my experience, the lowest-of-code solutions involve tuning a stack to the
domain or environment. Most existing frameworks try to be everything to
everybody, which gums things up with complexity and/or debugging headaches
when they don't work as expected.

The best frameworks are kits of decomposable or separable parts that make it
easy to tune to your org, including throwing out parts your org doesn't need.
Trim trim trim.

Do keep a library of handy add-ons, but don't pre-gum-up your stack by
including them by default.

The downside of this approach is that you must know the organization fairly
well.

------
jasonlhy
Low code is designed for some specific purposes. If all you need is what it is
designed for, that’s totally fine.

The biggest problem is their price and their nature. Many of them are really
expensive. And many of them is closed source, which is pretty ironic because
everyone is open source nowadays. Except it can be dominate in that area, I
don’t think it is valued for a professional developer,

The customisation is poor if you want to do something that is is not designed
for, and maintaining is also a nightmare if it is written by a non-disciplined
developer.

For quick prototype and you can’t hire skilled developer, yes. But don’t
expect you can do too much with that tool and with that person. The biggest
bottleneck in software developer is the people not the tech.

------
dy
Surprising this left out the dominance of Salesforce for business process and
general CRUD type apps.

~~~
tyingq
It's interesting that nothing open source has emerged in this space.

Lots of choices in the closed source space. Salesforce, Airtable, Quickbase,
Google AppMaker, Knack, Zoho, etc.

~~~
zubairq
Actually Yazz.com is open source and a low code environment so this is not
true

~~~
tyingq
Ahh, hadn't seen that before. I stand corrected.

------
truth_seeker
Low code is definitely the more high level and declarative way to code where
best practices are taken care of by platform itself in various areas which
matters the most while doing software development.

You don't have to focus much on "HOW to get it done" but on "WHAT needs to be
delivered"

Here is the list and comparison of some of the best low code platforms out
there in the industry

\- Zoho Creator \- Appian \- Microsoft PowerApps \- Mendix \- OutSystems \-
Google App Maker \- Quick Base \- TrackVia \- Salesforce App Cloud \- Nintex
Workflow Cloud

[https://www.pcmag.com/roundup/353252/the-best-low-code-
devel...](https://www.pcmag.com/roundup/353252/the-best-low-code-development-
platforms)

------
awinograd
Would be cool to see "no-code" as one of the flavors here. I'm betting on it
being possible to empower non-engineers to make apps in a startup I'm working
on AppsCanvas ([https://appscanvas.com](https://appscanvas.com)) which is a
platform for building out apps with integrated an API / backend. Basically a
whole app building & deployment system wrapped up for non-technical people.

I've been putting a lot of thought into low-code, and what the right escape
hatches are to allow developers to use a tool like mine without feeling
constrained. That's proving to be tough to balance though!

------
kinj28
We have explored many platforms from zoho creater, coda, airtable, outsystems
and mendix. While we are building DronaHQ.
([https://www.dronahq.com](https://www.dronahq.com)) Would love to get your
feedback as professional developer and citizen developer.

------
segmondy
It will be sad when the vast majority of developers are automated away, it's
going to hit them so hard because most of us don't believe it will happen due
to hubris. Most think it will take some general AI to happen when we don't
need that.

~~~
leetcrew
I would imagine a pretty good chunk of the work is close to being automated. I
imagine (perhaps in ignorance, I am not a web or systems dev) that computers
are close to being able to engineer stuff like site reliability (at least for
small to medium scale businesses) without human input. problems with well
defined "good" or even optimal solutions are low hanging fruit for machines.

that said, we're a long way away from feeding a copy of the latest c++
standard into a machine and getting a working compiler out of the other end.
no matter how well written, it is still quite a feat to turn a human-language
specification into executable code. even harder is to turn a loosely defined
set of requirements (often gathered from people who don't really know what
they want in the first place) into a solid spec in the first place. perhaps
this is the hubris you are speaking of, but I think most developers who are
more than brainless code monkeys are quite a ways away from losing their jobs.

