|
|
|
|
|
|
by bmhin
1437 days ago
|
|
|
It's hard to think about because I feel like when they work I don't think about them at all. And when they don't work I think about and stew about them excessively. So the good cases I forget about completely and the bad ones are stuck in my memory. SDLC is a frequent pain point. Often non-existent or hacky, e.g. export this giant XML doc and you can re-import it if needed. If any step requires clicking on buttons it generally leads to that kinda pain. Almost fundamentally, if I need to go copy paste or click on something for the product to work, I won't be able to automate it. Hence, it needs to be completely automatable. Similarly, if the config / set up / customization one does is obfuscated after it is specified it can be a headache to try to work around. Also maybe not the end of the world but many also decide to "handle" version control on your behalf, which can maybe be fine, but will also then almost by definition be divorced for your usual approach and processes. On the last question, I think this boils down to how well can one operate at the surface level. It is not uncommon in these low code apps to have to understand in detail what is happening below the hood. So yeah, the top layer abstraction might be very simple in practice, but if working with it frequently necessitates me knowing how that abstraction will be executing it leads to an extra layer of complexity that has not abstracted anything. In a way they often function like a second language going through a translator: if I have to be considering the Spanish version the no-code cares about and also how and what it will be translated to in English under the hood, it's just extra confusing for perhaps little gain. What makes it extra pernicious is you can be operating entirely off intuition for what that under the hood English really is, rather than some open spec you can at least drill into. Worst part here is I feel like this is really often something that will come with using the product. Often the use cases documented and sold really seem like all you'll need. |
|
|
> SDLC is a frequent pain point.
I've dealt with that pain before with other tools (promoting DataDog montiors + dashboards comes to mind). This area seems like it'll be even more painful so I'll definitely be filtering by that critereon.
> On the last question...
My particular use case would be for some human checkpoint in an otherwise-automated system. I'd hope to pull in all the contextual information, provide the decision-maker with a text box and an approve/reject decison.
> Worst part here is I feel like this is really often something that will come with using the product. Often the use cases documented and sold really seem like all you'll need.
Yeah, that's what worries me about low-code. I know it'll be a bit of a slog to do all these full-code, but it's a known quantity.