| > don't scale past a certain level of complexity I'd say that's a given, both that they're not very complex and not intended to scale past a few users. > tend to fall apart as they become successful. There are lots of definitions of success. A dashboard on a phone app so that the boss can see the green lights on his servers is successful. It gave him what he wanted: green lights on his phone. > By and large the target market for No Code doesn't value testing. This seems to be your qualifier of why they aren't 'good'. I don't own one, or work for one, or even subscribe to a platform that makes them, I'm just a passer-by here, but I can see the value in them. The only one I have used is open source (NodeRed). When there's no time and you need to glue two or three API's together in 30 minutes, I see nothing wrong with them. It goes without saying that the result will be fragile and only for a handful of people, probably only one of which will get write access. Here's my use case: co-founded a disaster relief non-profit in 2017 (hurricanes). Our window of opportunity to do good deeds was about 3-4 days, by then the red cross and fema trucks would arrive. When we need to process data it's probably a job with a roughly $0.00 budget and needs to be done in 30-45 minutes, then there's something else to do. For that? They are wonderful. I built a phone bar-code scanner that could pull price data from Kroger's API to account for food donations in about an hour and a half. Can anyone else do that writing code by hand? I say no, the UI alone would take longer (however rudimentary that UI is). Was it tested? Yeah, a quick manual once-over and me face-to-face telling the person admining it that if the bar code didn't read just google it and plug the price in by hand, or don't and we'll do it later if that isn't feasible due to volume. We were just trying to do a slightly better job than a pencil and a clipboard could do, not a perfect one. |