3 ms·

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 enhance

by 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
    For me, none of the learnings is a direct result of using a low-code, arrow-boxes environment. I can deploy instantly to production using any programming environment, if I don't automatically have design documents when using a much-code environment. Without discipline, any programming environment can lead to failures. It is true that there aren't any well-defined workflows for using an arrow-boxes environments but that does not mean that these environments don't support specific workflows.
    - closeparen 3y ago
      Are these environments attractive because boxes and arrows are actually better than characters for expressing programs? Or are they attractive because they encourage you to skip steps that turn out to have been important? Sure, you can replicate a normal, responsible development process with a no-code tool, but at that point do you really have a compelling alternative to a more traditional programming environment?
throwup238 3y ago
Low-code tools have a market fit problem because of that escape hatch. The players keep trying to sell it as a solution to IT deficiencies but it should be sold as an IT empowerment tool. It really doesn't matter how good your last mile delivery is if the shipping container with the product isn’t where it’s supposed to be to begin with. All the components and modules that low code tools provide should be nothing more than an onboarding tutorial like the first few levels of Factorio, before letting the engineering team loose hand in hand with the users. It shouldn’t be an escape hatch, it should be the front door. As such all these low code tools make the mistake of making it really difficult to bring the engineering team into the fold: modularization, logging, debugging, version control, and development tools are absolute garbage so instead of engineering providing a few sane company specific building blocks that they can tend and nurture, it inevitably turns into a shitshow because you can’t use a tool that ultimately depends on the IT department to fix the IT department! The best “low-code” tools have already been around for over a decade: it’s the headless CMS and autogenerated admin pages ala Django and Wagtail. They’ve been focused on solving the content management problem for e-commerce and marketing, but IMO it’s the write path for other groups too. The engineers write the pages and blocks and components while defining an input/configuration schema for an automated tool that is usable by laymen. Up the level of abstraction to a well curated (by the engineers at the customer level) IFTTT layer and bam, you’ve 95% of use of low code without the 5% that inevitably ruins it.
- TristanBall 3y ago
  I totally agree on the "IT empowerment" perspective, but unfortunately the price model of these tools makes it hard for many IT departments to introduce them, at least in established corporate environments, for internal use. Startup and public facing stuff is different of course but my experience is medium enterprise internal IT.. Per end user rather than per developer means they're far too expensive to introduce as a general IT toolbox item, they need to be part of a major strategic project where the $5-30/month per staff user has a hope of being justified. But that also often takes it outside the "IT Dept", which is often just "infrastructure and pc fleet" support, not development ( at least, that's my experience ). IT might do internal scripting and some service interface tooling, but business tooling and software is rarer, that's usually either dev teams or ERP teams. The ERP teams will already using ERP platform tooling, so that further narrows the market. I don't have a good solution for this, but it's always been the hurdle I've tripped on working for medium size enterprises. There would seem to be an opportunity for "open source platform, commercial training and support" here, but vendors seem to gravitate to per user head and cloud only for more immediate revenue and easier support., but again many enterprises still have huge internal only IT landscape's, because cloud is still expensive and the value often isn't seen in relatively static envs. It's possible this niche has been filled now too, it's been a while since I looked... Possibly they can be introduced on a "just those who need it" basis, but honestly that's just so bloody tiring for internal tools, not to mention demotivating as you can no longer build tools for "everyone or anyone", it's back to specific narrow business cases, not IT empowerment, but narrow business case also means your usually competing with cots tools or consultants.
mgl 3y ago
I really like your take on the escape hatch. The success of low code implementations often comes with a curse of investing man-years of development effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor. I believe there is a place for enterprise app platforms which are a) open source, b) not based on proprietary languages, c) with low code capabilities, fueled with AI code generation, d) runnable anywhere without staying dependent on typically user-based commercial model. Shameless plus: we are working on such a thing, and competing with traditional low code platforms is not easy, I could tell a few stories about what we have tried, what works and what not really, if you are interested. I would be also extremely thankful for any comments and hints you may have, see https://openkoda.com https://openkoda.com
- bb88 3y ago
  > effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor. That's the definition of vendor lock-in. Once the vendor has it's hooks in your organization, good luck removing it. Sometimes it's just the cost of doing business, but the more the hooks, the greater the chance that a vendor triples or quintuples the cost of their product that affects your organization's secret sauce. I feel like the goal of low-code solutions is to get you over the barrel. Much in the same way AWS tries to get into your company's operating costs.
- vinibrito 3y ago
  I'd love to hear some of your stories about marketing it! I create nocode plugins on a specific proprietary stalled platform, for a living, for a few years now, so I am definitely aware of the pitfalls in the area. For me the problem is that the API to it got created in a nice format but then got abandoned, if they just listened over the years and added the changes we third party devs needed it would have been great.
addled 3y ago
Having escape hatches is critical, but they should also be well built, or it can cause just as much headache. Example from us using Azure Data Factory: You can add a step to call out to an API, which we did for a data flow that had a lot of calls. Performance was atrocious. Dug into it, and the API getting called was replying in 100ms or so, but ADF's "escape hatch" was adding 5-10 seconds of overhead to send the POST and parse the HTTP status code. Microsoft Support said that's normal, expected behavior for the service. In the end, we had to write an additional batching layer ourselves.
- nnurmanov 3y ago
  This ADF abbreviation remind me of another framework we used, it is Oracle ADF (application development framework) and it was awesome low-code tool! You can literally create CRUD with entry form within minutes, we Spring Boot and ReactJs it could take substantially longer. The good part of the tool is that the code is available and you can make any changes you want. In the enterprise they prefer time to market over beauty or UX, so it did its job perfectly.
- jwoq9118 3y ago
  In Microsoft land the best escape hatch is writing an Azure Function.
onion2k 3y ago
That escape hatch is absolutely necessary for longevity though. I'd be really interested in knowing how often escape hatches like that are actually used. I'd guess it's less than a fraction of a percent, if ever.
- vinibrito 3y ago
  I develop plugins for a specific nocode proprietary platform, sixth year now doing it for a living, 95% of all apps use plugins, which are the custom code interface, the escape hatch. The ones that don't are very CRUDy apps with no remarkable features, like just some pretty design to input and show information. And most apps use about 10 to 20 plugins.

by Groxx 3y ago

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
  For me, none of the learnings is a direct result of using a low-code, arrow-boxes environment. I can deploy instantly to production using any programming environment, if I don't automatically have design documents when using a much-code environment. Without discipline, any programming environment can lead to failures. It is true that there aren't any well-defined workflows for using an arrow-boxes environments but that does not mean that these environments don't support specific workflows.
  - closeparen 3y ago
    Are these environments attractive because boxes and arrows are actually better than characters for expressing programs? Or are they attractive because they encourage you to skip steps that turn out to have been important? Sure, you can replicate a normal, responsible development process with a no-code tool, but at that point do you really have a compelling alternative to a more traditional programming environment?

throwup238 3y ago

Low-code tools have a market fit problem because of that escape hatch. The players keep trying to sell it as a solution to IT deficiencies but it should be sold as an IT empowerment tool. It really doesn't matter how good your last mile delivery is if the shipping container with the product isn’t where it’s supposed to be to begin with. All the components and modules that low code tools provide should be nothing more than an onboarding tutorial like the first few levels of Factorio, before letting the engineering team loose hand in hand with the users. It shouldn’t be an escape hatch, it should be the front door. As such all these low code tools make the mistake of making it really difficult to bring the engineering team into the fold: modularization, logging, debugging, version control, and development tools are absolute garbage so instead of engineering providing a few sane company specific building blocks that they can tend and nurture, it inevitably turns into a shitshow because you can’t use a tool that ultimately depends on the IT department to fix the IT department! The best “low-code” tools have already been around for over a decade: it’s the headless CMS and autogenerated admin pages ala Django and Wagtail. They’ve been focused on solving the content management problem for e-commerce and marketing, but IMO it’s the write path for other groups too. The engineers write the pages and blocks and components while defining an input/configuration schema for an automated tool that is usable by laymen. Up the level of abstraction to a well curated (by the engineers at the customer level) IFTTT layer and bam, you’ve 95% of use of low code without the 5% that inevitably ruins it.

TristanBall 3y ago
I totally agree on the "IT empowerment" perspective, but unfortunately the price model of these tools makes it hard for many IT departments to introduce them, at least in established corporate environments, for internal use. Startup and public facing stuff is different of course but my experience is medium enterprise internal IT.. Per end user rather than per developer means they're far too expensive to introduce as a general IT toolbox item, they need to be part of a major strategic project where the $5-30/month per staff user has a hope of being justified. But that also often takes it outside the "IT Dept", which is often just "infrastructure and pc fleet" support, not development ( at least, that's my experience ). IT might do internal scripting and some service interface tooling, but business tooling and software is rarer, that's usually either dev teams or ERP teams. The ERP teams will already using ERP platform tooling, so that further narrows the market. I don't have a good solution for this, but it's always been the hurdle I've tripped on working for medium size enterprises. There would seem to be an opportunity for "open source platform, commercial training and support" here, but vendors seem to gravitate to per user head and cloud only for more immediate revenue and easier support., but again many enterprises still have huge internal only IT landscape's, because cloud is still expensive and the value often isn't seen in relatively static envs. It's possible this niche has been filled now too, it's been a while since I looked... Possibly they can be introduced on a "just those who need it" basis, but honestly that's just so bloody tiring for internal tools, not to mention demotivating as you can no longer build tools for "everyone or anyone", it's back to specific narrow business cases, not IT empowerment, but narrow business case also means your usually competing with cots tools or consultants.

mgl 3y ago

I really like your take on the escape hatch. The success of low code implementations often comes with a curse of investing man-years of development effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor. I believe there is a place for enterprise app platforms which are a) open source, b) not based on proprietary languages, c) with low code capabilities, fueled with AI code generation, d) runnable anywhere without staying dependent on typically user-based commercial model. Shameless plus: we are working on such a thing, and competing with traditional low code platforms is not easy, I could tell a few stories about what we have tried, what works and what not really, if you are interested. I would be also extremely thankful for any comments and hints you may have, see https://openkoda.com https://openkoda.com

bb88 3y ago
> effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor. That's the definition of vendor lock-in. Once the vendor has it's hooks in your organization, good luck removing it. Sometimes it's just the cost of doing business, but the more the hooks, the greater the chance that a vendor triples or quintuples the cost of their product that affects your organization's secret sauce. I feel like the goal of low-code solutions is to get you over the barrel. Much in the same way AWS tries to get into your company's operating costs.
vinibrito 3y ago
I'd love to hear some of your stories about marketing it! I create nocode plugins on a specific proprietary stalled platform, for a living, for a few years now, so I am definitely aware of the pitfalls in the area. For me the problem is that the API to it got created in a nice format but then got abandoned, if they just listened over the years and added the changes we third party devs needed it would have been great.

addled 3y ago

Having escape hatches is critical, but they should also be well built, or it can cause just as much headache. Example from us using Azure Data Factory: You can add a step to call out to an API, which we did for a data flow that had a lot of calls. Performance was atrocious. Dug into it, and the API getting called was replying in 100ms or so, but ADF's "escape hatch" was adding 5-10 seconds of overhead to send the POST and parse the HTTP status code. Microsoft Support said that's normal, expected behavior for the service. In the end, we had to write an additional batching layer ourselves.

nnurmanov 3y ago
This ADF abbreviation remind me of another framework we used, it is Oracle ADF (application development framework) and it was awesome low-code tool! You can literally create CRUD with entry form within minutes, we Spring Boot and ReactJs it could take substantially longer. The good part of the tool is that the code is available and you can make any changes you want. In the enterprise they prefer time to market over beauty or UX, so it did its job perfectly.
jwoq9118 3y ago
In Microsoft land the best escape hatch is writing an Azure Function.

onion2k 3y ago

That escape hatch is absolutely necessary for longevity though. I'd be really interested in knowing how often escape hatches like that are actually used. I'd guess it's less than a fraction of a percent, if ever.

vinibrito 3y ago
I develop plugins for a specific nocode proprietary platform, sixth year now doing it for a living, 95% of all apps use plugins, which are the custom code interface, the escape hatch. The ones that don't are very CRUDy apps with no remarkable features, like just some pretty design to input and show information. And most apps use about 10 to 20 plugins.