3 ms·
I've said this before, but the biggest issue with no/low code solutions is how they get abused. One of my past comments on HN: > I've seen "low code" and "no c
by bilalq 5y ago
I've said this before, but the biggest issue with no/low code solutions is how they get abused. One of my past comments on HN:
> I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards.
Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments?
> Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.
I get the appeal of how it seems easier to train people with business domain expertise on how to be no-code devs than it is to translate requirements to an engineering team or wait an indefinite amount of time for a dev team to prioritize work. But until no/low code solutions start focusing on how to maintain and operate the apps users build, they'll continue to be a landmine.
- CactusOnFire 5y agoTo hop on the maintainability point: The same is true for "High-code" solutions. If you want the ticket done quick and dirty, it'll be done in a quarter of the time. But good luck ever iterating on it with additional features.
- q-big 5y ago> I get the appeal of how it seems easier to train people with business domain expertise on how to be no-code devs than it is to translate requirements to an engineering team Why do you think this is the case?
- ethbr0 5y agoBecause writing requirements (as a business domain expert who doesn't code) or interpreting requirements (as a developer with no business context) are very difficult tasks.
- tekromancr 5y agoThe value of these no-code solutions is in letting domain experts workout the requirements and prototype workflows to their own problems. If it stops scaling; that's a pretty good sign engineers should start actually building the thing