8 ms·

I am on the other side of low code, building the builders for the most part, here is what I see. Low code is very easy to sell. All you have to do is make a bo

by dexwiz 3y ago

I am on the other side of low code, building the builders for the most part, here is what I see. Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool. Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Wiring up a form shouldn’t take html, js, and a serverside language. On the flip side, don’t put your core business logic in low code. Low code builders assume anything complex will be offloaded to a specialized system. The best ones provide escape hatches by calling remote APIs or calling a code module. Low code gets sold to smaller customers because it’s touted as a developer replacement. But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It’s easy to get them to configure something in a SaaS they already use, than get a custom solution from IT. Also low code often comes with guardrails and permission sets tied to existing users. I see low code as a tech equivalent of the last mile problem in logistics. It addresses a large number of concerns with simple tools, but doesn’t scale well and needs to work in tandem with a stronger central system. End to end low code is a trap, but low code at the fringes is a multiplier.

actionfromafar 3y ago
Very mature comment grounded in the human experience as opposed to "tech" pros and cons.
kfk 3y ago
I like your analogy to the last mile problem in logistics. I would argue in that case people know they are using bespoke, last mile only, systems because there is no other option. Low code vendors promise much more than that, end to end capabilities.
- travisjungroth 3y ago
  I adopted an official personal policy of not working on any data project referred to as "last mile". It's a big sign it's going to be under-resourced and under-appreciated. The last mile is brutal. And that's in the physical world! You can tell when your last warehouse is close to the customer by looking at a map. You can't tell when your tool is close to what the user needs with nearly the same accuracy. There are a ton of gotchas, and as part of the "last mile", it's now your responsibility.
  - mycall 3y ago
    > as part of the "last mile", it's now your responsibility. You also are at the whim of the SaaS vendor to give you the help you need. If they can't do something you think it should, good luck making a hacked workaround to function as it must.
wegfawefgawefg 3y ago
The user is sort of expected to know that it should be used like this, but theyre set up for failure having it sold to them with the wrong framing. Imagine I bought a vacuum cleaner expecting it to clean all my floors, and never finding out what i bought was a pack of pocket tissues. Pocket tissues are useful but not when im trying to clean my floor with them.
siliconc0w 3y ago
This is still usually tech solving an organization problem. Launching normal apps gets gated under security, product, or technical reviews but the low code tool becomes a backdoor to all that. If you just deleted a bunch of processes, or just reserved it to when it actually matters, you wouldn't need to pay a low code vendor to basically allow your team to do their job.
- dalyons 3y ago
  I’m sure OP knows this. But practically that just never happens. Big companies are bureaucratic and process filled with exception
juujian 3y ago
I'm curious, do you ever mention anything along the lines of "don't put your core business logic or mission critical stuff in this" ? That could backfire, but it needs to be said.
- heatmiser 3y ago
  I believe the parent says exactly that, no?
  - abeyer 3y ago
    I think the question was less "Do you say this pseudonymously to other developers?" than "Do your salespeople say this to your prospective customers?"
Groxx 3y ago
Low code with an escape hatch is quite nice, because yeah - many things can and probably should be low-code. It's a big productivity and standardization enhancer. That escape hatch is absolutely necessary for longevity though. It lets you keep your low-code environment simple because you can leave it and write real code when necessary, rather than forcing everything into an over-complicated and under-capable custom thing with no editor tooling.
- mdbauman 3y ago
  Agreed, with the caveat that you also need a policy/culture that the escape hatch should be avoided whenever possible and the low-code work should not be done by developers. Whenever I've discussed this, the common theme is that business users continue to request features that would be easily achieved in the low-code platform being used. It's hard to blame them; that's been standard procedure for them for their entire career. But if you're not strict about saying "no", you still end up writing all the same methods but now on top of that you have a GUI that's not providing any value. Or maybe worse, your developers end up maintaining all of the low-code stuff too when they could have just written the code, switching context pointlessly and (probably, depending on the platform) not using source control.
  - closeparen 3y ago
    An interesting thing with developers getting involved in those boxes-and-arrows UI things is outages. I made a mistake with one once, and the postmortem quite reasonably asked: * Where was the design doc? * Where were the alerts? * Where was the code review? * Why didn't you write an integration test? * What do you mean it just rolled out to production instantly? When we're considering options in advance of building something, it's a more time-efficient, less wasteful alternative to programming. But having built it, everyone acknowledges that what we have done is programming, and now they wonder why we've programmed so badly. Maybe the standard IDEs, Git, code review, CI, metrics, and incremental deploy workflows were fine actually?
    - Towaway69 3y ago
NikolaNovak 3y ago
So from a certain perspective, the positive niche / need it would fill is enabling the local power users who might also do complex Excel queries, or have their own MS Access, etc?
- dexwiz 3y ago
  Similar, low code is a bit broader and is usually associated with a business process like taking in a lead, providing a quote, or approving a transaction. Excel can do the calculations for these things but still requires a lot of human interaction. Low code can do a bit more like generating a form, evaluating branching logic, or handling an async process over time.
- sokoloff 3y ago
  Excel is surely the most widely used low-code solution in the world.
robjan 3y ago
We tried low code (citizen development) as a solution to the "IT dept sucks" problem. It worked pretty well at the start but eventually became a data governance nightmare and as soon as we needed to restructure the business we ended up with ownerless applications and datastores all over the place. It eventually turned out there was a prioritisation problem rather than a development capacity problem.
- kukkeliskuu 3y ago
  Can you elaborate about the prioritisation vs. development capacity problem?
  - gardenhedge 3y ago
    my guess: There's enough developers but things need to be prioritised one by one. If everything is a priority and everything is being worked on at the same time then there's not enough devs to go round.
  - ozim 3y ago
    Not a parent poster - but building all kind of crap that anyone can come up with is not the right thing to do. One might think you need all of it right here right now - but in reality if you build 20% that is really really needed you get 80% or I could bet even 95% of actual work done needed for the company to improve productivity/performance etc.
jrumbut 3y ago
> But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It's not just business knowledge, it allows the people who are most committed to project success to do the work. I think that's the real pain point with IT departments in large organizations. They aren't feeling the pain that made you need the software in the first place.
- bigfudge 3y ago
  I agree, but maybe the solution is to attach developers to teams directly. Avoid the centralisation, except for infra that benefits from it.
luizsantana 3y ago
I never thought of the selling point. It indeed makes a lot easy to sell it, but from my experience, companies always regret using it. Did you have any positive experience on the after seeking low code?
deleted 3y ago
[deleted]
noobermin 3y ago
In this analogy low code is actually the brt or metro as the last mile part is the hard part.
Roark66 3y ago
>Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Oh my... Many, many, maaaany reasons. For example, your entire stack is built in a certain way and you don't want to introduce new dependencies. What if your cicd requires your config and code is separate and that you build a code artefact, and let's say 3 config artefacts (dev, cert, prod), all these are then uploaded to a central repo and handed over to some proprietary security/code scanning thing every time you merge new code. Then let's say your deployment is done the same way, you have your "deployment config" artefacts for each environment, but an infrastructure team manages all the infrastructure-as-code artefacts that take your config. I worked in a bunch of big companies each having their own version of such process. In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.
- spinningslate 3y ago
  this is simultaneously a valid reason not to use low code tools - and why they find favour in many organisations. >In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes. I've also seen the opposite. Someone in the org wants a simple site. Maybe a sign up form, or CMS/wiki for internal docs, etc. The dev team says "sure, that'll be 6 months". A large part of which is constrained capacity - the devs need to fit it in alongside a buch of other stuff. Another part is tech choice: the corporate stack uses e.g. React on the front end, calling web services written in Java, backed off to Postgres for storage (or whatever). The devs estimate for building the CMS/wiki/whatever from scratch - because it has to fit the tech stack. At that point the (internal) customer screws up their face and utters all the familiar frustrations about "IT". Someone somewhere mentions to them that there's a way to sidestep it all, and do it yourself. In their position it's very hard not to see that alternative as attractive. It's a hard problem. That same internal customer will similtaneously rail against the recharge in their budget for IT. It's a cost: a drag on their P&L. IT says they're under-resourced, and they could do it quicker with more people - but that would increase the P&L drag. Vicious circle. Software is a sociotechnical endeavour yet we too often focus on the technical and ignore the social aspect. Yet "Low Code" and similar emanate primarily from the social side. Coming back to your post though, not exclusively. Development teams can be equally culpable when zeroing in on tech stacks that aren't a good fit for the problems at hand. Or, perhaps, stacks that are a good fit for the problems they were chosen to solve - but not so much when the new requirement comes along. Of course, low code is no panacea either. Most non-technologists have no perception of the need for ongoing evolution, even if there's no new feature development. Patching/upgrading is a must. And new features always emerge - most after the original "citizen developer" has moved on / lost interest / whatever. So the whole shebang gets foisted on IT, who are expected to operate and maintain it. Usually with no tests, automated builds, documentation, ... It's pernicious. At heart, though, it's primarily a social problem that needs a good underlying relationship between the customers/users and the developers. It's Conway's Law. Of course tech choice still matters. But no tech stack is going to magic away problems rooted in organisational friction.
jrochkind1 3y ago
> Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool. I feel like you just explained how salespeople can scam decision-makers into thinking low-code solutions will do more than they can do, and in no way countered any of the arguments in the OP about it's dangers.
- throwup238 3y ago
  Not every HN comment needs to be argumentative.
m3047 3y ago
> I see low code as a tech equivalent of the last mile problem in logistics. Ironically it's the OT and logistics people who've figured this out, with low / no code solutions fit for purpose, which don't necessarily run in the cloud, which have full microservice / SQL integration... and baked in OT drivers, RFID and bar codes.
notjoemama 3y ago
Seems like the generators and gem ecosystem in Rails already solved these problems. I can easily build a devise login in less than 10 minutes. Low code in Rails is almost instantaneous and you get tests automatically too.
EGreg 3y ago
So low code is a good way for salespeople to bamboozle clients? Kind of like “consultants” coming in with advice on how to improve the organization?

by dexwiz 3y ago

actionfromafar 3y ago

Very mature comment grounded in the human experience as opposed to "tech" pros and cons.

kfk 3y ago

I like your analogy to the last mile problem in logistics. I would argue in that case people know they are using bespoke, last mile only, systems because there is no other option. Low code vendors promise much more than that, end to end capabilities.

travisjungroth 3y ago
I adopted an official personal policy of not working on any data project referred to as "last mile". It's a big sign it's going to be under-resourced and under-appreciated. The last mile is brutal. And that's in the physical world! You can tell when your last warehouse is close to the customer by looking at a map. You can't tell when your tool is close to what the user needs with nearly the same accuracy. There are a ton of gotchas, and as part of the "last mile", it's now your responsibility.
- mycall 3y ago
  > as part of the "last mile", it's now your responsibility. You also are at the whim of the SaaS vendor to give you the help you need. If they can't do something you think it should, good luck making a hacked workaround to function as it must.

wegfawefgawefg 3y ago

The user is sort of expected to know that it should be used like this, but theyre set up for failure having it sold to them with the wrong framing. Imagine I bought a vacuum cleaner expecting it to clean all my floors, and never finding out what i bought was a pack of pocket tissues. Pocket tissues are useful but not when im trying to clean my floor with them.

siliconc0w 3y ago

This is still usually tech solving an organization problem. Launching normal apps gets gated under security, product, or technical reviews but the low code tool becomes a backdoor to all that. If you just deleted a bunch of processes, or just reserved it to when it actually matters, you wouldn't need to pay a low code vendor to basically allow your team to do their job.

dalyons 3y ago
I’m sure OP knows this. But practically that just never happens. Big companies are bureaucratic and process filled with exception

juujian 3y ago

I'm curious, do you ever mention anything along the lines of "don't put your core business logic or mission critical stuff in this" ? That could backfire, but it needs to be said.

heatmiser 3y ago
I believe the parent says exactly that, no?
- abeyer 3y ago
  I think the question was less "Do you say this pseudonymously to other developers?" than "Do your salespeople say this to your prospective customers?"

Groxx 3y ago

Low code with an escape hatch is quite nice, because yeah - many things can and probably should be low-code. It's a big productivity and standardization enhancer. That escape hatch is absolutely necessary for longevity though. It lets you keep your low-code environment simple because you can leave it and write real code when necessary, rather than forcing everything into an over-complicated and under-capable custom thing with no editor tooling.

mdbauman 3y ago
Agreed, with the caveat that you also need a policy/culture that the escape hatch should be avoided whenever possible and the low-code work should not be done by developers. Whenever I've discussed this, the common theme is that business users continue to request features that would be easily achieved in the low-code platform being used. It's hard to blame them; that's been standard procedure for them for their entire career. But if you're not strict about saying "no", you still end up writing all the same methods but now on top of that you have a GUI that's not providing any value. Or maybe worse, your developers end up maintaining all of the low-code stuff too when they could have just written the code, switching context pointlessly and (probably, depending on the platform) not using source control.
- closeparen 3y ago
  An interesting thing with developers getting involved in those boxes-and-arrows UI things is outages. I made a mistake with one once, and the postmortem quite reasonably asked: * Where was the design doc? * Where were the alerts? * Where was the code review? * Why didn't you write an integration test? * What do you mean it just rolled out to production instantly? When we're considering options in advance of building something, it's a more time-efficient, less wasteful alternative to programming. But having built it, everyone acknowledges that what we have done is programming, and now they wonder why we've programmed so badly. Maybe the standard IDEs, Git, code review, CI, metrics, and incremental deploy workflows were fine actually?
  - Towaway69 3y ago

NikolaNovak 3y ago

So from a certain perspective, the positive niche / need it would fill is enabling the local power users who might also do complex Excel queries, or have their own MS Access, etc?

dexwiz 3y ago
Similar, low code is a bit broader and is usually associated with a business process like taking in a lead, providing a quote, or approving a transaction. Excel can do the calculations for these things but still requires a lot of human interaction. Low code can do a bit more like generating a form, evaluating branching logic, or handling an async process over time.
sokoloff 3y ago
Excel is surely the most widely used low-code solution in the world.

robjan 3y ago

We tried low code (citizen development) as a solution to the "IT dept sucks" problem. It worked pretty well at the start but eventually became a data governance nightmare and as soon as we needed to restructure the business we ended up with ownerless applications and datastores all over the place. It eventually turned out there was a prioritisation problem rather than a development capacity problem.

kukkeliskuu 3y ago
Can you elaborate about the prioritisation vs. development capacity problem?
- gardenhedge 3y ago
  my guess: There's enough developers but things need to be prioritised one by one. If everything is a priority and everything is being worked on at the same time then there's not enough devs to go round.
- ozim 3y ago
  Not a parent poster - but building all kind of crap that anyone can come up with is not the right thing to do. One might think you need all of it right here right now - but in reality if you build 20% that is really really needed you get 80% or I could bet even 95% of actual work done needed for the company to improve productivity/performance etc.

jrumbut 3y ago

> But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It's not just business knowledge, it allows the people who are most committed to project success to do the work. I think that's the real pain point with IT departments in large organizations. They aren't feeling the pain that made you need the software in the first place.

bigfudge 3y ago
I agree, but maybe the solution is to attach developers to teams directly. Avoid the centralisation, except for infra that benefits from it.

luizsantana 3y ago

I never thought of the selling point. It indeed makes a lot easy to sell it, but from my experience, companies always regret using it. Did you have any positive experience on the after seeking low code?

deleted 3y ago

[deleted]

noobermin 3y ago

In this analogy low code is actually the brt or metro as the last mile part is the hard part.

Roark66 3y ago

>Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Oh my... Many, many, maaaany reasons. For example, your entire stack is built in a certain way and you don't want to introduce new dependencies. What if your cicd requires your config and code is separate and that you build a code artefact, and let's say 3 config artefacts (dev, cert, prod), all these are then uploaded to a central repo and handed over to some proprietary security/code scanning thing every time you merge new code. Then let's say your deployment is done the same way, you have your "deployment config" artefacts for each environment, but an infrastructure team manages all the infrastructure-as-code artefacts that take your config. I worked in a bunch of big companies each having their own version of such process. In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.

spinningslate 3y ago
this is simultaneously a valid reason not to use low code tools - and why they find favour in many organisations. >In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes. I've also seen the opposite. Someone in the org wants a simple site. Maybe a sign up form, or CMS/wiki for internal docs, etc. The dev team says "sure, that'll be 6 months". A large part of which is constrained capacity - the devs need to fit it in alongside a buch of other stuff. Another part is tech choice: the corporate stack uses e.g. React on the front end, calling web services written in Java, backed off to Postgres for storage (or whatever). The devs estimate for building the CMS/wiki/whatever from scratch - because it has to fit the tech stack. At that point the (internal) customer screws up their face and utters all the familiar frustrations about "IT". Someone somewhere mentions to them that there's a way to sidestep it all, and do it yourself. In their position it's very hard not to see that alternative as attractive. It's a hard problem. That same internal customer will similtaneously rail against the recharge in their budget for IT. It's a cost: a drag on their P&L. IT says they're under-resourced, and they could do it quicker with more people - but that would increase the P&L drag. Vicious circle. Software is a sociotechnical endeavour yet we too often focus on the technical and ignore the social aspect. Yet "Low Code" and similar emanate primarily from the social side. Coming back to your post though, not exclusively. Development teams can be equally culpable when zeroing in on tech stacks that aren't a good fit for the problems at hand. Or, perhaps, stacks that are a good fit for the problems they were chosen to solve - but not so much when the new requirement comes along. Of course, low code is no panacea either. Most non-technologists have no perception of the need for ongoing evolution, even if there's no new feature development. Patching/upgrading is a must. And new features always emerge - most after the original "citizen developer" has moved on / lost interest / whatever. So the whole shebang gets foisted on IT, who are expected to operate and maintain it. Usually with no tests, automated builds, documentation, ... It's pernicious. At heart, though, it's primarily a social problem that needs a good underlying relationship between the customers/users and the developers. It's Conway's Law. Of course tech choice still matters. But no tech stack is going to magic away problems rooted in organisational friction.

jrochkind1 3y ago

> Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool. I feel like you just explained how salespeople can scam decision-makers into thinking low-code solutions will do more than they can do, and in no way countered any of the arguments in the OP about it's dangers.

throwup238 3y ago
Not every HN comment needs to be argumentative.

m3047 3y ago

> I see low code as a tech equivalent of the last mile problem in logistics. Ironically it's the OT and logistics people who've figured this out, with low / no code solutions fit for purpose, which don't necessarily run in the cloud, which have full microservice / SQL integration... and baked in OT drivers, RFID and bar codes.

notjoemama 3y ago

Seems like the generators and gem ecosystem in Rails already solved these problems. I can easily build a devise login in less than 10 minutes. Low code in Rails is almost instantaneous and you get tests automatically too.

EGreg 3y ago

So low code is a good way for salespeople to bamboozle clients? Kind of like “consultants” coming in with advice on how to improve the organization?