4 ms·

The issue with low code tools is that they typically solve the easy problem. 1. What happens is that it is usually very easy to get a simple thing up. Then yo

The issue with low code tools is that they typically solve the easy problem. 1. What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way. 2. Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers. Guess what. Software engineers do not just code. They know how to build stuff, which includes a huge amount of knowledge of how to construct maintainable and reliable systems. Put non-engineers on the problem and you will get an unmaintainable mess that is going to be failing a lot. 3. You try to string your system from a bunch of low-code tools. You quickly integrated a dozen different online tools. Now you find out nobody can understand what is going on. If you hire a person, they will spend a huge amount of time learning all of those tools. If you build an application let's say in Java, it is much easier to get around the system and understand how it works. If you can read and understand one module, you can pretty much read and understand all of them. But with low code tools strung together there is pretty much new problem, new language, new paradigm for every of those tools. 4. Part of software development is ability to modify things in a safe way. Having test environment, code versioning, integration and deployment pipelines, etc. Having practices around building stuff. Almost no low-code tools respect any of it. At best you can build your own custom solution for each one but forget trying to prepare v2 of your system and deploy it in any organised way. Your production usually becomes your test environment and your deployments will typically result in some minor drama. ** I get the appeal of low/no code tools. It is super fun to get something working very quickly with no resources. If you have a simple problem that matches the tool perfectly and you will never want to make it much more complicated -- it might even be the best solution for you. The issue is that management wants more and you will have to field requests for new functionality and requirements. And you will quickly find adding those will start taking exponentially more effort while you are necessarily spending time talking to your sales reps trying to figure out if/when they can provide the functionality. All this while you have trouble hiring and onboarding people to maintain it because there is just so much magic that only your initial staff is only ever able to understand what is going on.

msla 4y ago
> What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way. I'll repost an old post of mine: https://news.ycombinator.com/item?id=33703563 https://news.ycombinator.com/item?id=33703563 The Curse Of Almost: Your tool is great, it's almost perfect... except for that one little thing it can't do, which your users need to do, which, therefore, leads to masses of ugly hacks unless you provide access to an escape hatch where sufficiently motivated experts can drop down to a real language which doesn't have your DSL's limitations and get the job done. It's the Curse Of Almost because, if it were too much worse of a fit for the problem, nobody would even think of using it to solve that problem. Getting someone 90% there and crapping out puts your users in a more awkward position, especially if they feel they've invested effort in whatever tool they have. An example is Talend versus CSV: Talend is an ETL Solution which Extracts data from some source, Transforms it according to a graphical DAG of ideally stateless components, and Loads it into some other storage. It's also a happy, friendly GUI on top of Java, which is nice, because the Real World isn't kind to happy, friendly GUI solutions which expect CSV is going to conform to any of your syntax rules or other misguided preconceptions about files having structure. So, when you have to run a Talend pipeline on vaguely-comma-delimited text files which may once have been machine-readable, you can make your own component which is literally just a block of Java code to parse the file using the Zerg Rush Of Ad-Hoc Rules Technique, an oft-overlooked method for designing parsers. You can also use that kind of thing to make components which are tasteless enough to demand state variables other than the stereotyped kind Talend itself provides. > Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers. Or you can cheap out on engineers, because they don't have to code, just use a GUI (which must be easy, it's just point-and-click right? /s) and don't realize that, to solve any problems except the most stereotyped happy-path examples, you need more expertise because now you're actively going against the grain. This isn't as bad in Talend as it is in other things I've worked with, but even in Talend once you start writing actual Java in the components you need to worry about scoping rules because your Java code is just dumped into the middle of a great big method written by Talend itself and the Java compiler isn't in on the gag.
- deleted 4y ago

msla 4y ago

> What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way. I'll repost an old post of mine: https://news.ycombinator.com/item?id=33703563 https://news.ycombinator.com/item?id=33703563 The Curse Of Almost: Your tool is great, it's almost perfect... except for that one little thing it can't do, which your users need to do, which, therefore, leads to masses of ugly hacks unless you provide access to an escape hatch where sufficiently motivated experts can drop down to a real language which doesn't have your DSL's limitations and get the job done. It's the Curse Of Almost because, if it were too much worse of a fit for the problem, nobody would even think of using it to solve that problem. Getting someone 90% there and crapping out puts your users in a more awkward position, especially if they feel they've invested effort in whatever tool they have. An example is Talend versus CSV: Talend is an ETL Solution which Extracts data from some source, Transforms it according to a graphical DAG of ideally stateless components, and Loads it into some other storage. It's also a happy, friendly GUI on top of Java, which is nice, because the Real World isn't kind to happy, friendly GUI solutions which expect CSV is going to conform to any of your syntax rules or other misguided preconceptions about files having structure. So, when you have to run a Talend pipeline on vaguely-comma-delimited text files which may once have been machine-readable, you can make your own component which is literally just a block of Java code to parse the file using the Zerg Rush Of Ad-Hoc Rules Technique, an oft-overlooked method for designing parsers. You can also use that kind of thing to make components which are tasteless enough to demand state variables other than the stereotyped kind Talend itself provides. > Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers. Or you can cheap out on engineers, because they don't have to code, just use a GUI (which must be easy, it's just point-and-click right? /s) and don't realize that, to solve any problems except the most stereotyped happy-path examples, you need more expertise because now you're actively going against the grain. This isn't as bad in Talend as it is in other things I've worked with, but even in Talend once you start writing actual Java in the components you need to worry about scoping rules because your Java code is just dumped into the middle of a great big method written by Talend itself and the Java compiler isn't in on the gag.

deleted 4y ago