3 ms·

I been at one very large enterprise for the last 15 years; the amount of low/no code apps I've been through is...well you know when neo is in the matrix, he is

I been at one very large enterprise for the last 15 years; the amount of low/no code apps I've been through is...well you know when neo is in the matrix, he is shown the previous matrix versions by the architect? its that feeling, but in this case there is no version of reality where there is a win. The biggest problem I see even if this were to work, is that you don't really want non-developers using these tools. Who's to blame when the low/no code user makes a booboo ? These people typically don't want this burden, so I've always seen it pushed back to a developer...and the requests are usually beyond the scope of the low/no code tool such that it eventually always becomes a worse burden for devs than code

ethbr0 5y ago
That's an organizational problem. If you use this stuff right -- citizen-developers should be developing their own work. Or at most, the work of their immediate group / team. Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer! And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer. The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise. And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in. And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.

ethbr0 5y ago

That's an organizational problem. If you use this stuff right -- citizen-developers should be developing their own work. Or at most, the work of their immediate group / team. Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer! And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer. The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise. And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in. And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.