21 ms·

I'm skeptical of low-code

• bazil376 3y ago
  This to me is true for low code tools that are aimed at non-developers. “You can write software without software developers!” But low code tools made specifically to help developers’ workflows can be great. Maybe would be good for OP to clarify type of low code tools
  • contravariant 3y ago
    I think it's fine to use low-code specifically for the lie that the only thing preventing people from writing code themselves is a slick UI. Sure there exist applications that do equivalent things, but when people start using the word 'low-code' to describe such an application they suddenly get the weird idea that the hard part of coding is typing the damn syntax and that if only you put a GUI in front of it they can do it themselves. Conveniently forgetting that people have made the exact same promises about the first IDEs. Pretty sure there's an ad to that effect for Turbo Pascal somewhere.
• j45 3y ago
  Less-code might be more realistic than low or no code. Hard not to have platform lockin with zero or low code. As the other comment said, less code tools for developers can be quite helpful.
• kkfx 3y ago
  IMVHO the "low code" environment have a name: end-user programming. The thing the entire entire industry have done it's best to destroy it after Xerox, Symbolics. The rest is the nth failed tentative to makes users jailed by ignorance selling the idea people can do thing without knowing things. It will fail like any other tentative done before.
  • zdragnar 3y ago
    Microsoft Excel is end-user programming. The amount of businesses that have critical processes done entirely in Excel is both impressive and terrifying. It is basically a database, reporting tool, IDE and half a dozen other things all rolled into one giant mess.
    • elforce002 3y ago
      I know an SMB that has all its operations on Google Sheets. They told me they don't have time to learn any tool (all their efforts go to keep the business running), and they don't have the money to hire a full-time dev. I offered them the opportunity to develop their platform pro bono. They're thrilled since they will be the first business with that type of platform.
      • zdragnar 3y ago
        This applies up, as well. I was involved in talks with a household name (in the US at least) retail store that still managed purchasing for all of their locations via spreadsheet, and had a team of 8 people who were allowed to touch it at any given point to reconcile inventory. They had looked at getting a proper purpose-built system in place, but I don't know what happened after that.
    • CPLX 3y ago
      It's not that terrifying in my opinion, it's mostly just impressive. From a business standpoint it's probably the single most useful software platform ever invented.
    • kkfx 3y ago
      It's a mess because it try to be "made for ignorant users" instead of choose the classic desktop way. First: in classic systems the OS is a single application/framework where anything or nearly anything is accessible by end users, so there is no special integration limit that force devs to reinvent the wheel to have anything in a single modern app and reinvent it in bad way since they have no time nor resources even at the big tech sizes, plus the need to invent ways to circumvent system design limits. Being a single app means if I have a CAS installed I can solve an ODE in an email just typing it and pass the math expression to a relevant CAS function, no need to reinvent a basic or less basic calculator. No need to know all the stuff about making it. I just access the relevant functions written by some expert and tuned for that purpose. The dev does not need to know, it's the user who know and use. Secondly means an incredible simplification. Let's talk for instance about a Plan9 mail client: what kind of beast is? Well it's just a base64-to-text reader and writer. Nothing more. The connection to the webserver is just a universal system connection to a remote file server, a remote filesystem mounted somewhere under the local root. All you need to do is knowing how to access a local fs, read text files, read/encode base64. Nothing more. Sending an email is just saving a text file with a given name in the right place. Publish a website is the same BTW, so it's sharing a file. Being a single app-framework means that anything is simpler, there is not much duplication of functions, only tuning. Now try to see an example of modern Emacs in action like https://youtu.be/B6jfrrwR10k https://youtu.be/B6jfrrwR10k how much complicated is creating a slide? Well just zoom some org-mode text. A table like a spreadsheet? It's just text and can be passed to any programming language supported by org-babel as data. Doing so meaning no lock-in possible and the end-user in control, that's why all the modern IT industry starting back then with the not-so-modern IBM, have demolished this, but the result is a mess. A decade after another we tend to the old model wasting gazillions of resources to keep up an untenable business model.
• ralusek 3y ago
  Code is a way of explaining rules. If you have a lot of complicated rules, whatever system you use to represent it is going to be complicated. Best case scenario for low code is when the rules are simple or very predictable. In my experience, this is very rarely the case, no matter how simple a problem seems from the outset
  • ed_elliott_asc 3y ago
    I’ve seen this exact thing, a “low code” engineer creates an app, we asked for some changes and all of a sudden “no can’t be done” - it is almost comical tbh
    • daxfohl 3y ago
      Or the converse: We've got all this spaghetti code. -- I know, we'll rewrite it as a rules engine! ... We've got all this spaghetti yaml.
      • codedokode 3y ago
        What about compilers? They have lots of optimization rules, how do they solve the problem?
        • daxfohl 3y ago
          For compilers or anything else, if you have a bunch of spaghetti code, the first step is always to clean up the code. Refactor it to the point where you can easily swap in your low code module. Then determine whether it's still worth it to do so. What happens all too often is a hack week project that brings in some low code functionality in some simple use case gets shown off and kicks off a bigger effort. But then the edge cases buried in the spaghetti code come up in some way tangential to the low code approach, so it gets hacked in. This happens over and over, and eventually your low code model is just as spaghettified as your code was, except now that spaghetti spans yaml, some interpretation layer, and the remaining two thirds of the original code that you haven't migrated yet. For this I'll coin my law of declarative intentions: the resulting low code cannot be simpler than well factored code itself.
• debarshri 3y ago
  We started out with webflow for our landing page. Problem with low code or any abstractions in general is that it becomes leaky the moment you want to do complex stuff. The reason webflow worked for us initially was we did not have to bother with hosting, CMS etc. It because very restrictive at one point. Only couple of people know how to make certain changes. Eventually we moved to nextjs and vercel. We are faster with iterating on our landing page as well as any engineer can be pulled into the implementation. All lowcode platforms are great in basic usecases but fails when the usecases because complex.
  • xcskier56 3y ago
    We went the other direction (to be fair, just building a simple static site). I’m a developer therefore I should make the marketing site! Problem is that with limited resources that took away time from building the product. We’ve moved to various platforms over the years so that our designers with a touch of web knowledge can build our marketing site. They’re happy bc they don’t have to wait to make changes and devs are happy bc they don’t have to work on marketing sites. The designers actually enjoy the constraints to a degree bc it simplifies their job as well. But like I said, it’s just a simple static marketing site
    • debarshri 3y ago
      This is our marketing website https://adaptive.live/ https://adaptive.live/ As you can see, it is more than a static website. Implementing this in webflow was nightmare.
      • elforce002 3y ago
        That site looks tidy. It's clean, modern, and pleasant to watch. Your team did a great job.
      • bb88 3y ago
        Webflow does seem to at least dogfood their own product. https://webflow.com/blog/webflow-at-webflow https://webflow.com/blog/webflow-at-webflow But the big issue seems to be that they're not marketing anything to the developers. They're marketing everything at the managers -- particularly the kind of manager that doesn't really understand software.
• cirgue 3y ago
  Low-code is just good libraries and good frameworks. My hot take is that anything “low code” beyond that is just an aggressively user-hostile config interface.
  • xnx 3y ago
    Most(all?) self code self-hosts, which is extremely valuable. There no shortage of smart people who can creat complex tools (see Excel for examples) if hosting it wasn't currently such a ridiculous prospect.
    • twic 3y ago
      My version of low code is writing HTML pages with a big script element full of vanilla JavaScript, and putting them in this one git repo we have which gets deployed to a web server. Obviously it's not actually low code, it's 100% code, but it creates a space without a lot of the complexity and ceremony of 'real' software development. I don't write tests, I don't future-proof, I don't set up deployment or monitoring machinery, I don't worry about anything except solving a small, well-defined problem quickly. It's definitely not a good approach to everything. But it's quite common for one of my users to say something like "I need a dashboard showing how the current reactor temperatures compare to the averages for yesterday, and also the available cooling water for each one", where that's all data we have existing websocket feeds for, and I can get that to them very quickly without it becoming formal feature development. Lack of testing and monitoring means the products often break. But when they do it's typically benign - the page doesn't load, or shows no data, and if a user needs to use it, they'll complain, and I can fix it. If a page ever got too complicated, or too critical, I might want to port it onto real software. But that hasn't happened yet.
      • globalise83 3y ago
        Reactor temperature monitoring is surely the exact area of software engineering (along with medical software) where you'd want the most robust processes isn't it? If your solution says everything is fine when in fact it's not, someone will have a big problem on their hands.
• nixpulvis 3y ago
  The gap between low-code and AI assistance is narrow and deep.
  • callalex 3y ago
    The security threat models are wildly different though. A “no-code” solution won’t be convinced to export private data with the right conversational English smooshed into the username field, for example.
• deleted 3y ago
  [deleted]
• djangelic 3y ago
  I use n8n.io hosted locally to abstract away authentication when building complex api integration mvps that I use to show as possible and working, and then that gets sent to engineering to convert to something that follows better best practices.
• cgrealy 3y ago
  Horses for courses.. If you want to build a shed, go to your local hardware store and buy a kit set. If you want to build a skyscraper, get an architect, some engineers and a competent building company.
  • jbsmith1 3y ago
    Bingo
  • agentgumshoe 3y ago
    Which of course becomes the CTO saying of course the business can build skyscrapers with these simple kit sets.
    • givemeethekeys 3y ago
      I've seen the opposite. Business hires new CTO who has no knowledge of existing stack and why it is breaking but sells the top brass on a low code replacement because of how quickly he can build with it. Spends a year building the replacement, forces a hard switch and fireworks ensue.
  • quickthrower2 3y ago
    If you want to bank land, build a shed and rent it out, then if you successfully get rezoned build the skyscraper.
  • _heimdall 3y ago
    I've never seen a local hardware store shed kit that wasn't complete garbage for the price. Building a simple shed isn't hard, if you can handle assembling the kit you can buy and cut the basic materials yourself. The trickier parts like getting it watertight or installing doors and windows have to be done either way, all the kit gets you is a bundle of inferior materials and a bit of time savings cutting studs.
• dexwiz 3y ago
  I am on the other side of low code, building the builders for the most part, here is what I see. Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool. Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Wiring up a form shouldn’t take html, js, and a serverside language. On the flip side, don’t put your core business logic in low code. Low code builders assume anything complex will be offloaded to a specialized system. The best ones provide escape hatches by calling remote APIs or calling a code module. Low code gets sold to smaller customers because it’s touted as a developer replacement. But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It’s easy to get them to configure something in a SaaS they already use, than get a custom solution from IT. Also low code often comes with guardrails and permission sets tied to existing users. I see low code as a tech equivalent of the last mile problem in logistics. It addresses a large number of concerns with simple tools, but doesn’t scale well and needs to work in tandem with a stronger central system. End to end low code is a trap, but low code at the fringes is a multiplier.
  • actionfromafar 3y ago
    Very mature comment grounded in the human experience as opposed to "tech" pros and cons.
  • kfk 3y ago
    I like your analogy to the last mile problem in logistics. I would argue in that case people know they are using bespoke, last mile only, systems because there is no other option. Low code vendors promise much more than that, end to end capabilities.
    • travisjungroth 3y ago
      I adopted an official personal policy of not working on any data project referred to as "last mile". It's a big sign it's going to be under-resourced and under-appreciated. The last mile is brutal. And that's in the physical world! You can tell when your last warehouse is close to the customer by looking at a map. You can't tell when your tool is close to what the user needs with nearly the same accuracy. There are a ton of gotchas, and as part of the "last mile", it's now your responsibility.
• smitty1e 3y ago
  Frameworks at all levels of _aaS are great, given the stipulation that your greenfield requirements are completely boring. This falls apart when: * legacy systems/data must be integrated * the requirements get interesting There is just no substitute for a good working understanding of the tools, and that means staff that can go past the low-code facade when needful.
• siliconc0w 3y ago
  As an SRE that occasionally encounters low-code things I'm also pretty skeptical.. * there is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control. * the workflows are poorly if at all documented. * they still require a lot of custom code but that code isn't as reusable, tested or testable * they often require a proprietary runtime, worse this may only run on windows * they are difficult/impossible to instrument and so are difficult or impossible to monitor. Or if they do have monitoring it is going to work differently than the rest of your stack - likely using email based alerting which isn't ideal. * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs) The only tool that was semi-reasonable here was Looker which isn't exactly marketed as low code but at least in the version of the product I used did integrate with source control. Though generally the people writing lookml were still engineers. I'm much more a fan of composable platforms that compress complexity but still make it possible to delve, customize and extend when necessary.
  • bb88 3y ago
    > * the workflows are poorly if at all documented. Ideally it would be easier to understand if there's less code involved. Things should be more declarative, or the low-code solutions would generate good descriptions for what is actually happening. > * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs) Or worse: "Why does this connection to this server fail with SSL Certifcate Invalid? Oh, nm, we'll just uncheck the SSL validation box."
    • fieldcny 3y ago
      “Ideally” is quite a word, highly subjective. But really you are missing a key piece of the puzzle, it matters less what is happening and more why. Sure a low code tool could churn out a textual description to say if the value of some variable is < some threshold branch to X else branch to Y, but thats generally easy to figure out, why is that threshold important, that’s a question that requires understanding the intention of the user of engineer who set it up, that’s not something you can just puke out of an auto-doc tool. I would go so far as to say the inability to capture intention is one of the sharpest edges for low-code tools, it makes the solutions built on then extremely brittle and creates silos of knowledge. Expanding on that further this is why most auto generated documentation is worth the effort put into it.
• fnordpiglet 3y ago
  Where I use low code is in essentially expert systems, where I need to encode the expertise of some SME. For instance, a lot of places have regulatory compliance burdens. The detailed rules for compliance changes by jurisdiction constantly. Most enterprises setup some sort of requirements to engineer pipeline that everyone’s bitterly unhappy with. It is never fully compliant, has tons of errors, the engineers resent their jobs, and the SMEs resent the engineers. Instead by instrumenting the system with a low code surface area with a policy management system overlaying it you get an excellent platform engineers like to develop, SMEs can author and manage their policies directly, and you capture a rigorous workflow which auditors and regulators really dig. This doesn’t make the engineer less important, in fact they’re much more important to ensure the policies are expressive enough and touch enough business data to ensure the policies are complete. They’re just not playing regulatory policy telephone games in code.
  • JonChesterfield 3y ago
    There's definitely something to this. What comes to mind is things like tax compliance. It's a moving target, software devs almost universally do not want that domain knowledge and accountants/lawyers almost universally do not want to represent that knowledge in C++.
• icedchai 3y ago
  My experience with low code is it's easy to get an 80 to 90% solution. Getting that last 10 to 20% may be very difficult. Also, source control, versioning, deployment may be open questions depending on the platform and project. Additionally, you will be locked in to a proprietary platform. Perhaps that is okay.
• peteforde 3y ago
  My personal view is that you're right to be skeptical, but perhaps not for the reasons you mention. I think that GPT-4 today is good enough to replace about 80% of programmers in the right hands. Put differently: we probably don't need bootcamp grads anymore. The folks who keep their jobs are the ones who intuitively grasp what needs to be done, how to break that ask down into iterative tasks, and how to word those tasks as prompts. Instead of scrambling to replace application stacks with layers of dumbed down abstractions, we are actually replacing the less experienced people working with application stacks. Dramatically better outcome for everyone but the people who thought they could take a bootcamp and create generational wealth.
  • faeriechangling 3y ago
    ChatGPT is nice but it’s not a 5x speedup.
    • kaashif 3y ago
      Was the comment edited? I don't see anything about speedups.
      • faeriechangling 3y ago
        If you can replace 80% of programmers with GPT-4 and maintain the same output, the remaining 20% would have 5x higher productivity.
        • peteforde 3y ago
          Yes, and I strongly suspect that this is conservative. Mid-term future iterations will quickly get to 10x and beyond. Also: your math is based on the random elimination of 80% of programmer roles. I was specifically talking about the elimination of the worst 80% of programmers. By worst, I mean "the least productive" - not "terrible persons".
          • faeriechangling 3y ago
• simonw 3y ago
  I'd find this article more useful if it named names - I still only have a loose idea in my head as to what qualifies as a "low-code tool". I'd like to know which low-code tools in particular the author has experience with.
  • jeremyjh 3y ago
    Salesforce is the most well-known example but it’s so popular that actually it’s not hard at all to hire experienced developers who know it’s custom server-side language and all its workflow automation and reporting tools. They just hate their lives.
    • aleph_minus_one 3y ago
      > They just hate their lives. Triple their payments, and they will be fine. :-)
  • abound 3y ago
    I keep a list of them, I think I originally got most of these from https://news.ycombinator.com/item?id=33592990 https://news.ycombinator.com/item?id=33592990 * Retool - https://retool.com https://retool.com (not OSS) * OpenBlocks - https://github.com/openblocks-dev/openblocks https://github.com/openblocks-dev/openblocks * Saltcorn - https://saltcorn.com/ https://saltcorn.com/ * Interval - https://interval.com/ https://interval.com/ * Bracket - https://www.usebracket.com/ https://www.usebracket.com/ * Windmill - https://docs.windmill.dev/ https://docs.windmill.dev/ * Budibase - https://budibase.com/ https://budibase.com/ * AppSmith - https://www.appsmith.com/ https://www.appsmith.com/ * ToolJet - https://www.tooljet.com/ https://www.tooljet.com/ I only have direct experience with AppSmith.
    • jinen83 3y ago
      Founder of DronaHQ here - a Retool alternative. would love if you can include us as well in your list. unless its just a list of open source
      • 3y ago
• dventimi 3y ago
  I'm skeptical of code. Code is needed to create operating systems, database engines, game engines, network servers, graphics and plotting libraries, and other tools that are typically used by software engineers but not end users, and yet most of us are not creating these tools. Most of us are using these tools to serve end users. This isn't a demanding task and it doesn't demand much code. Maybe in the UI, but for the vaunted "business logic"? Please. You don't need reams of code in a general purpose programming language to provide business logic.
  • iimblack 3y ago
    Have you done a lot of low code work? I’ve found it just ends up with escape hatches everywhere because the low code platform can’t handle some edge cases or gets too complex for the non engineers to reason with. Other issues are observably, logging, testing, debugging, etc are often impossible or very difficult. Could work for small shops but the enterprises it gets marketed to usually need the normal code.
    • dventimi 3y ago
      I do almost all of my work in the database. I don't know if you want to call that "low code" or not. Evidently, it doesn't look like code to many other developers but then again it precedes current low-code platforms by about 40 years, so who knows?
      • iimblack 3y ago
        I wouldn’t call that low code but yeah the definition is ambiguous. I’m mostly experienced with and referencing flowchart type tools.
        • dventimi 3y ago
          I'll grant I'm pretty skeptical of those.
      • rcbdev 3y ago
• jauntywundrkind 3y ago
  I feel like we are kind of trapped between simplistically polar notions. There's coding as we know it - complex & interwovenines of code - and there's this low code ideology. Any area of code itself is usually fairly boring & irrelevant. It's systems that accrue mass & complexity. Low code systems sound good by demonizing the weird symbols & incantations that make up the lower level fo coding, but it's this systematic complexity, it's the aggregation of many things happening that makes things opaque & difficult. Finding patterns to suss out broader-scale understanding is what really tempts me. I don't have super strong vision here, but I'm interested in projects like Node-RED, or even to a degree works like jBPM. Both kind of speak to going beyond coding, but I think the valuable thing here is really that they are assembly toolkits for modules of code & data. They are just examples and not even good ones but this quest, to me, to get to the next levels of computing, is to make clearer portraits of what happens, that either are above to code level, or where the code's running creates higher level observability surfaces. Code is so easy to demonize. The layering is often so implicit, handlers and DAOs and routes in different layers maybe but with no clear overview layer. Figuring out how to make legible these systems, without diving deep into the code, is what, I think, will make systems less intimidating & will serve as a bridge to make businessfolk and novides better able to intuitively grasp & meddle with these these artificed put before them, with courage. And making people less afraid of the machine, more interested in peeking in and meddling, that's where so much hope lies.
• talldatethrow 3y ago
  I'm sure this has been asked a thousand times, but does something like Visual Basic exist for the web?
  • reidjs 3y ago
    JavaScript? Or the developer console perhaps.
    • talldatethrow 3y ago
      The ease in which I can just drag and drop things, and write some logic behind it, and it later compiles the code for me to execute elsewhere.
  • zubairq 3y ago
    Not yet, but I am building it here: https://github.com/yazz/yazz https://github.com/yazz/yazz
  • Poliorcetes 3y ago
    I heard good things about outsystems
• tmn007 3y ago
  I was involved with a project to decomission a low code on premise platform (Sharepoint 2013). What we found was there was a lot of user enthusiasm to create stuff but when the platform was end of life and had to be decomissioned the users enthusiasm melted away. The "IT" dept had to spend a fortune re-validating the user requirements for the various applications, documenting and then converting them into a new platform. Obviously a lot of feature creep and previously accepted bugs (no longer accepted now that responsibility was no longer theirs). A lot of the applications were frankenstein efforts from people over the years - lots of dead code no longer used, no docs etc. As others have mentioned people create mission critical stuff for their project or team, and then leave or be away on extended leave and it breaks etc.
• Eji1700 3y ago
  I used PowerApps. It is so so so close to being a silver bullet tool for quick front end crud that can use your AD to authenticate. Instead though, it’s got the most absurd pricing model that even their own reps don’t understand and is missing critical or basic features, requiring strange workarounds (fucking UTC dates vs what’s actually in the DB). They USED to have no way to reuse code as well but they fixed that. I feel like the issue is they’re still too married to basically low/no code environments. Having a “I’m going to need to do a custom script in whatever” option would smooth out the edges so much
  • beckingz 3y ago
    And PowerApps is slow as balls. Power Automate is great, but PowerApps is just a mess where every click in the dev interface takes like 5 seconds. On paper it looks so good, but in practice it is so painful to get that on paper performance and functionality.
    • Eji1700 3y ago
      Hooooooooly shit you weren't kidding. For unrelated reasons i've had to hop back in to tweak an app we made a few years ago that's been buzzing along in production ever since. Last time I touched it was more than a year ago. The actual editor interface is horribly unresponsive, but it seems to fix itself if i close and reopen the browser (firefox). Still it gets worse with time and it used to be no where near this bad. As bonus points, functionality that is working in production no longer works in the editor! I found that I had to add yet another clause to all my functions because for some reason it no longer pulls all data from a sql table unless you use show columns to specify you do in fact want all of them.
  • fulafel 3y ago
    Using AD to authenticate is not much of a barrier since it got OpenID support some years back.
  • YurgenJurgensen 3y ago
    You'd think that a tool intended for automating business processes would have a builtin for counting business days, but apparently not.
• ChrisMarshallNY 3y ago
  Define "Low Code." Is it a programming language, a framework, a compiler/linker/IDL, etc.? I mean, there are some that could argue that C is "low code," because it isn't Machine Code. I started in Machine Code, and, these days, write mostly in Swift. Swift seems like "low code," compared to Machine Code. I assume that they are talking about things like Qt, React Native, Xamarin, Electron, or Ionic (You can tell that I develop host apps). I write native Apple, using established Interface Builder SDKs, mainly because of the first point. I like to have 100%, and Highest Common Denominator approaches don't allow that. Also, I find that upgrading can be a problem. I have been in the position of not being able to support the latest OS, because a library hadn't been updated, yet.
  • iimblack 3y ago
    IME is much higher level than that. These are when you program by essentially just making a diagram (ideally).
    • ChrisMarshallNY 3y ago
      I remember when Rational Rose was supposed to let you create a giant server system, just from a "Booch Blob" diagram. I don't think I ever heard of a system that was successfully shipped, using that.
      • ahepp 3y ago
        It's interesting to think about this in the context of model based development / UML. Both are situations where people are trying to make the primary source something other than written text. I guess I'm biased, but I think written text has been wildly successful. The more experience I've gained, the more I use text based tools and generally prefer text to alternatives. Even in a recent case where I wanted a diagram, I used graphviz to automatically generate it.
  • LikesPwsh 3y ago
    Generally low-code are those gui-driven development tools. E.g. You can write a data pipeline in SSIS by just dragging boxes around and entering connection details. Sometimes the abstraction doesn't expose something you'd like, so you add a bit of code (SQL/C# for SSIS), but that's the "escape hatch" rather than the default workflow. You've also got the approaches like Power Query, where a frontend action is automatically recorded as code (M in that case) , but the code is largely hidden from the end user and only used for source control/escape hatch.
• jbsmith1 3y ago
  I think the point are valid but it comes back to a much simpler idea - what’s the right tool for the job. Figure out what you want to do then find the right level of abstraction to get it done. And salespeople are one data point, generally not to be relied upon. Or have I over simplified?
  • nobaelazum 3y ago
    I agree. It isn't useful to think of "low code" or not. You think of what the tool offers and if it can be extended easily to do what you want. If you choose it and it isn't as advertised or doesn't fit, it was the wrong choice. We rely on all sorts of "low code" stuff and it works great because it's battle proven and provides the right abstractions. "Low code" is a misnomer, just say "esoteric specialized tool that isn't customizable".
• nextworddev 3y ago
  I’ll go against the grain and say low code will eat software engineering. But not the conventional low code platforms like web flow or retool or power apps. It will be AI native and built in a visual+conversational manner.
  • toomuchtodo 3y ago
    As someone who worked at a low code workflow SaaS, I agree with this. The automation is a commodity, the value was in discovering that people wanted to talk to the LLM to orchestrate their automation vs bespoke workflow design UX. You can also decouple models from API scaffolding like Gorilla LLM (or rather, broad models that dive deep into use case specific models on demand).
    • flimsypremise 3y ago
      Congratulations you have just invented yet another query language with the special fun addition that the result is non-deterministic.
      • toomuchtodo 3y ago
        Doesn’t matter, as long as users are getting value. How you solve the problem is less important than solving the problem. I expect LLM output to improve over time, along with mechanisms to coax deterministic behavior.
        • nextworddev 3y ago
          Yeah developers sometimes overrate precision when in reality being precise is not as good as getting the job done
  • quickthrower2 3y ago
    Software Engineering will be fine: it has been eating itself since Lisp invented macros. Maybe software engineering should be called “The operations of automation using data on general purpose machines”. That will not die. It will look different though.
• uraura 3y ago
  Database mess is unavoidable because it needs to support different kind of customers.
• anyonecancode 3y ago
  "Low code" means a low surface area of code you can directly interface with, but there's plenty of code shoved out of sight and out of reach. Total amount of code is probably actually quite a bit larger, actually, given all the code needed to create the abstraction layers to give the appearance of low code. Layers of abstraction are powerful when they're tight and well-suited to their purpose (I'm happy to never think about memory allocation -- thank you garbage collected languages!), but when leaky or ill-suited can be very frustrating and make things harder or impossible. It's hard -- probably impossible actually -- to build a "general purpose" abstraction layer that will work for specific purposes, but that's essentially the pitch of low code -- we don't know your specific use case, but we have a tool that will abstract away all the code previously tailored to that use case. Now, in fairness, there's a lot of code that has too much accidental complexity in it. A good abstraction layer strips away that accidental complexity and leaves only the essential complexity that's specific to your domain and use case. But that's hard to achieve -- it takes skill and experience (and not just general experience, but specific to your domain experience) to achieve. Most companies don't have that available to them, and don't want to pay rates to build teams that do have that skill set and experience. Low code holds out the promise of being a short cut to that, but clearly if your own dev team can't manage it, the odds of a generic platform doing it for you is slim to none.
  • bsdpufferfish 3y ago
    Good comment. > It's hard to build a "general purpose" abstraction layer that will work for specific purposes I would phrase this a little differently. It’s impossible to make good tradeoffs without an understanding of the specific use case. “Lossless abstractions” are possible, just rare as they usually come from understanding essential mathematical properties.
• phamilton4 3y ago
  I have been since the first people at my previous employer told me it would replace all the programmers. Then I found out the developers assigned to working on the low/no code parts had a component where they could write Java inside their low code process. There were hundreds of lines of code in each business process in the low code parts. They were writing giant methods in their process wired up by the true low/no code part. To make matters worse the tool did not support unit testing of the custom code. It ended up being like dozer mapping entity to entity and then passed along to custom code. All wrapped in some crummy UI. It produced a jar file which would be deployed anyways. Maybe the tools are better now. We had some Tibco product at the time.
  • quickthrower2 3y ago
    VBA reborn!
• netman21 3y ago
  All I know is that I was quoted $50K from a Ukraine team to build an MVP, as long as I could provide detailed specs down to every function. I hired an intern who used bubble/airtable to build our product in two months and had ten paying customers in 6 months. After almost two years have yet to find a reason to move to a traditional stack. We have had 6 hours of down time in those two years thanks to bubble issues. I can live with that.
  • haolez 3y ago
    Please, do tell more! Where I see no/low code fall apart is when complex input data validation is required. However, I can also see that this might be our old practices getting in the way of innovative forward thinking. Maybe you've found a way, since you are starting from scratch :)
    • voltaireodactyl 3y ago
      FWIW I run the IT dept for a mid-level talent agency. I moved us off an old system and into Airtable specifically because it’s flexible enough on every front. The killer feature for me is the concept of “views”, which means we can have all the data available at all times, but only surface the data that a particular user needs for them. In a company full of less than technical people, this has been an absolute godsend. And when we continue to grow, there are ways off of Airtable since it’s all just CSV underneath.
    • vinibrito 3y ago
      What would be these complex data validation requirements?
  • quickthrower2 3y ago
    Not a fair comparison. One you were asking for fixed price contract the other you are paying a salary. The salaried person is more likely to be able to be agile and not need requirements (if you said to the intern $20k once I am happy with the job they’d say “define happy” and you are back to requirements!) As for code vs. no code. If (big if!) bubble can do what you need it can be a cheaper route to launch an MVP.
• msla 3y ago
  I guess Talend is low code. Talend is an ETL tool: Extract data from a data source (file, database, API), Transform it, and Load it into another data source (file, database, API), all in a pipeline. Talend's happy path is the same as Unix shell's happy path: A pipeline of data with no side-effects and no globals. Try to deviate from that and you hit walls, some more climbable than others. For example, Talend absolutely will not allow you to re-combine a pipeline you've split; you can combine two separate data sources, and you can split to two separate sinks, but you absolutely cannot go from one pipeline to two pipelines back down to one. The saving grace is that Talend is fundamentally a GUI for writing Java. You can see the Java it's writing, and you can add your own Java in a few ways, from adding jar files to just plopping a pipeline component that allows you to insert your own Java into the big God Method that the rest of your pipeline helping to form. Be sure you know how scoping works if you do that. In extremis, you can "use Talend" in that you use the Talend GUI as an Eclipse IDE to write the one pipeline component that does everything because it contains all of the useful Java code. You can use it the way I often used it, to take care of some tedious "plumbing" code to route the pieces of data created by the hand-written component to their respective outputs, including handling some minor output conditioning that can be done in a stateless fashion. It can even be used as it was intended to be used, as odd as that sounds.
• shermantanktop 3y ago
  From what I can tell, the market for these low-code tools is as much non-tech managers as it is the actual users. Slick demos go a long way to convincing people who own budgets and are tired of expensive engineering salaries. Which I can understand, because engineers are expensive and behave in ways that are unintuitive for non-tech people. But I fear “generative AI coding tools” appeals to the same people for the same reasons, leading to the same results.
• bombcar 3y ago
  The most successful low code is Excel.
  • tedheath123 3y ago
    At my workplace they are replacing spreadsheets with web apps. The users are very proficient with Excel. I would rather set the data free and let people play with it in spreadsheets however they want. For complicated functions you can make an add-in if you really need it, which I understand are a pain to deploy and manage. Web apps are twice as much work though and more restrictive for users. Plus we have a big cloud bill now and everyone’s beefy workstations are idle. I shouldn’t complain though, this stuff keeps me employed.
• maccard 3y ago
  Low code is what IBM, SAP, Salesforce have sold as "the solution" for the past few decades, but packaged in a different way. This is no farther along than we were 20 years ago IMO.
  • te_chris 3y ago
    Not true. SF low code is great because the platform is closed. It saves a lot of time - up to a point of course, but it's a pretty complex point.
• outlore 3y ago
  My interpretation of low-code includes headless CMSes, authentication as a service with pre-built components e.g. Clerk, plug-and-play collaboration e.g. Liveblocks. Those services save me a lot of time without having to worry about underlying implementation, and they also have some nice escape hatches. However, I share the author's skepticism about other low-code tools that involve a lot of UI/visual flow building with limited insight into how the black box works and what its constraints are.
• cassepipe 3y ago
  ...said the carpenter to the Ikea manager. Wordpress, Excel ?
• tim__ 3y ago
  [dead]
• zzzeek 3y ago
  didnt know WTF "low code" was. googled. OH, it's those stupid visual IDEs that pretend you can connect blocks and lines together and get a program. "I would get clients who had been drawn to low-code all the time for the promise of fast development time and low maintenance cost." Oh I'd not go anywhere near silly "clients" like that. Who wants to fight with that level of dumb
• ubertaco 3y ago
  Can I check a "low-code" implementation into version control, using standard free tooling? Can I, when something inevitably goes wrong, do a `git log` equivalent to spot the source of the problem? Can I then roll back to a specific commit, using off-the-shelf free tooling? I find that generally the answer is most often "no," which is kinda a nail in the coffin for serious usage of "low-code."
  • deleted 3y ago
    [deleted]
  • bruce511 3y ago
    You do realise that there were ways to debug things before GIT came along? Indeed before source control came along? What im saying is that you should be wary of ignoring things that don't fit into your current work-flow, because sometimes that "critical" thing in your workload is less critical than you think.
    • 8organicbits 3y ago
      Those tools are in the current workflow because of industry-wide lessons learned. What are the alternatives you allude to?
      • foldr 3y ago
        To a significant extent, yes, but there's also a lot of people just following fashions. There are whole teams of devs who really have no idea how to use git, but who are using it because everyone else does. I'm no git expert myself, but I can't count the number of times I've seen people, e.g., comment out large sections of code 'in case I want to add it back in again later'.
    • syndicatedjelly 3y ago
      What was it like to work on software before version control? What are some pros and cons to that kind of workflow?
• pylua 3y ago
  Low code has been used for decades successfully. Think about ladder logic and scada systems. I always find this missing from these discussions. The main point is it has its place — and choosing when and where to use it is critical.
• somat 3y ago
  is "low-code" this generations version of "4gl"? The only 4gl I know of that held the test of time was SQL. Every other one ended up being an embarrassing wart of "technical dept". The same could be said of most "enterprise software". For them that don't know enterprise software is code for "It's 70% done and we will charge well to finish it for you"
• appplication 3y ago
  Maybe it’s just me, but I assumed almost all devs with basic coding ability would be against low code. It has so many issues, from poor version control to never (and I do mean never - would love to be proven wrong) doing more than or even meeting the feature set of whatever competing “some code” solution offers. In the end, you end up with either less skilled people getting in too deep, or highly skilled people unable to fully avail their skills. I get the appeal, but it always seemed like a local optima to me. It turns out code is a pretty good interface.
  • sfn42 3y ago
    That's what people don't seem to get. "Low code" is literally just a software library with a gui on top. They could just provide the software library as a standalone but then there's too much competition and the competition is often free to use. So they don't even bother because their whole product is redundant without the GUI, and the GUI itself is just a pointless obstacle to a developer.
    • JonChesterfield 3y ago
      A programming language is a pointless obstacle in the way of writing the compiler IR directly. And the compiler IR is a pointless obstacle in the way of writing the machine code directly. Low code GUIs are a weird code generator, just the same as all the other programming languages. Whether it's an obfuscation or an enabler depends on your perspective and what you're trying to do with it. In particular, programming languages are pretty much a library (called the compiler runtime) with a text user interface on top.
      • sfn42 3y ago
        No, a programming language is a useful tool. There is absolutely nothing stopping you from writing machine code directly, go right ahead if you think that's easier for you.
        • JonChesterfield 3y ago
• ctrlp 3y ago
  A lot of useful MS Access and Excel apps written by non-programmers beg to differ. Sure they have their problems, what doesn't? But these low-code tools allow smart, but less technical, people to get a lot done without getting in line to beg time from a bunch of grousing devs stack-hopping their way to their next job. Use a commercial vendor and you might even get documentation and support. 80% solutions usually do more than was needed if the requirements had been thought through carefully. Most business apps are tables, filters, queries, detail views, and workflow. So what if a product with 5 users in a department is trash? Works well enough most of the time. Startup can't afford more than one developer? Product owner can hack the thing until you get customers, funding, or go out of business. Oh, and that bus factor goes up to boot. No more pager duty. Code things that are core to your business and plan for the TCO. Use low-code for internal business apps and let your smart intern or low-code consultant make and own it.
• tdeck 3y ago
  The term "low-code" is in itself a compromise based on the very issue the author is identifying. The old term was "no-code", but too many people needed custom functionality. Aside: The contrast on this website is really borderline. Extremely light gray, low font weight, white background. I thought we were past that particular trend in web design.
• doubloon 3y ago
  Eh the thing is that Worse is Better and "Actually available to people in Operations without having to beg for permission" is the best of all. VBA (Visual Basic available in Excel and Outlook) had a lot of the same issues as low code, as in no version control, no workflow for review or continuous testing and integration, no ability to do lots of custom things, that did not stop it from running the planet. I mean if you did the VBA version of Thanos-snapping half of all VBA code out of existence, most of society would cease to function within a week. Power Automate is going to replace VBA soon because VBA can no longer talk to web pages thanks to the end of Internet Explorer and lack of VBA updates. And like VBA, Power Automate has all of the same problems - no concept of code review, version control, history, logging, actually its worse. VBA at least let you have custom Types and Classes but in Power Automate everything, literally everything, is a global variable. Power Automate is lower code than VBA. But I think it will be used even more. Because it is already installed on every almost every office computer in the world. This is the only tool ordinary Ops people will have available to them to automate stuff, so that is what will get used.
  • YurgenJurgensen 3y ago
    So how long until we get the scenario "Billion dollar company suffers major outage of business-critical system because person that wrote Power Automate script went on holiday for too long and their connections timed out"?
• andrewstuart 3y ago
  I spent years building tons of big applications in the worlds first true low code environment - Lotus Notes. Sure it had limitations but you could get an awful lot done within those limitations.
• MetaWhirledPeas 3y ago
  I'm 100% against enterprise-level low code stuff. If you're big enough to afford that junk you're big enough to afford proper development teams with proper planning and organization. In general I see little value in any large system intending to reduce the amount of code or the needed skills of the developer. Code is not costing you money. Good developers are not costing you money. You know what costs money? Bad developers making bad decisions using bad tools, necessitating years if not decades of paying armies of lesser-skilled developers to maintain the mess, slowing overall progress to a glacial pace.
  • tonyedgecombe 3y ago
    Most enterprise software is terrible, it's the lowest quality software you will come across. Paying more for good developers won't fix that because the problems all emanate from the enterprise itself.
  • abeyer 3y ago
    Largely agree... and to top it off, the pricing models mostly work against ever having a successful deployment of one. Either you price per end user, and optimize against building anything that is widely adopted, or you pay per developer, in which case you need to figure out up front who are the people with unmet needs who also happen to have the knowledge, skills, inclination, and time to build their own solution. (and this is enterprise pricing, so you need to know up front for at least a year how many of these you'll have, or you'll end up in a contract renegotiation or paying expensive overage fees.)
  • elicksaur 3y ago
    > Good developers are not costing you money. I’m assuming you’re taking a rhetorical liberty here and really mean “net money”, but then what if you can get a similar end product for lower price? That’s higher net money.
    • MetaWhirledPeas 3y ago
      What counts for "similar end product" typically ignores all future needs of the business. One project gets accomplished and everyone gets a pat on the back and a bonus. Then as the years go by the accomplishments become more and more mundane. For example, upgrading the enterprise software to a newer version suddenly counts as progress and everyone once again gets a pat on the back. Eventually everyone wonders why the IT expense is so huge and why the company's software seems to be treading water. So someone bites on another sales pitch and years are spent transitioning to some awful alternative enterprise turd, and the cycle continues until bankruptcy or acquisition.
• prakashn27 3y ago
  Low-code or no-code is okay with small apps. But as complexity increases, you won’t have fine control or scalability needed using these tools. Low code may be better for mvp. Once you have enough revenue moving to a code based solution will be better in long run.
  • Towaway69 3y ago
    > Low-code or no-code is okay with small apps. But as complexity increases, you won’t have fine control or scalability needed using these tools. Won't a better approach be a low-code tool that grows with your needs? It would seem to be a waste to build an mvp in a low-code* environment and then throw away all the learnings and rebuild it in a code-based solution. *=the assumption is that low-code is not no-code, i.e., the mvp would have some amount of code that would be throw away.
• jayd16 3y ago
  A great example of a low code tool that works is Unreal Blueprints. Full games are made with blueprints. It's not for everyone and it doesn't support text diff but it plays well enough with source control and other tooling.
  • YurgenJurgensen 3y ago
    I think this only works because a lot of games can be shipped and never touched again. A self-contained single-player experience doesn't really need to be maintainable.
    • jayd16 3y ago
      I guess I don't have the data to refute you but Unreal is used for many live games; Fortnite, for example. They're probably not all 100% blueprints but BPs are used extensively.
• b33j0r 3y ago
  I love that this piece talks about the database. That is a problem I focus on. It’s API versioning all over again, and we never _actually_ solved that before we moved forward. I see this being our reality anyway. In many cases; not all. You can’t ask the LLM, nor a hypothetical AGI, nor anything, to build the aqueducts. Especially if you don’t know you need them. And they won’t solve the problem if neither a human nor an AI know what the problems actually are. Let’s make em out of lead! And they definitely won’t waste tokens on a postgres rollback migration unless we make that essential in the acceptance criteria. An LLM is all of our ideas, in a search UI that dang nearly passes the turing test. (That says more about us than the state of AI technology.) We are pattern machines in many ways, and many things we code are even lovingly called Software Patterns. The promise is not that software engineering goes away, it’s that we’ll all be managers for a while. Low-code, to me, is different from “statistically generated solutions that pass the requirements.” Genetic programming was an idea for decades, but that is also different from stuff that combines yours and my most relevant github commits into a 90% best guess. Not random, hoping for the best, in this regime. Educated guess.
• brucenanner 3y ago
  Aren’t modern day programming languages low-code relative to assembly and/or binary? It’s all relative to the previous layer.
  • timcavel 3y ago
    [dead]
• bruce511 3y ago
  There's lots of good general criticism about Low Code tools, and certainly lots of it is valid depending on the tool and the context. Of course, just like say the SQL or NoSQL debate there are contexts where one wins, and another fails. I did have to smile at this though; >> "Now, rather than being to recruit from a large pool of ubiquitous, open-source language developers, the company has to find maintainers who are very specialized in this tool." From a company point of view this is correct. You cant just discard programmers and get a cheap, out-sourced one as a replacement. On the other hand, as a somewhat older programmer, I like the idea that I get more valuable with age not less. I like that I can't be replaced by some ubiquitous open source freelancer who works for $20 an hour. For the record I've been working with a low-code tool for 30 years (since long before "low code" was even a description) and I've seen thousands of one-man companies be successful developing programs where the owners actual programming skills are, well, in most cases, somewhat poor. Turns out, making something useful has more to do with fixing pain, and less to do either writing code. And yes, all the points listed in the article, and these comments, are true. And ironically almost none of it actually matters. There are a million reasons it -shouldn't- work and yet, somehow, at least in my world it does.
  • jwoq9118 3y ago
    I think this is the key a lot are missing. It’s about solving the problem, not necessarily doing so in a way that’s preferred or familiar to you. Low code has prod/cons but it has a place in the industry that many developers seem to be too arrogant to acknowledge.
• 29athrowaway 3y ago
  The problem of low code is vendor locking.
  • Towaway69 3y ago
    "Node-RED: Low-code programming for event-driven applications"[1] It's open source and built using NodeJS. No vendor, no lock-in and very extendable using javascript. It's all a definition of low-code. [1]=https://nodered.org/ https://nodered.org/
• danjc 3y ago
  A few comments here about lack of version control being a problem generally with low code. We're a low code platform (app integration) and what's worked well for us is to have the platform store the generated workflow design (yaml/json) in source control. Additionally, we map environments on to source control branches so merging to a branch is what promotes a design version to qa or prod.
  • v-erne 3y ago
    Anyone who lived through Model Driven Development era (late 90 and early 2000) knows that this solves only like 20 percent problems that those who complain about lack of version control are really talking about. The real unsolved problem is lack of visual comparators that could show what really changed between versions. If you try to do diff those text serialization formats (those being yaml, json or, in old days, xml) you have to do a lot of mental gimnastic to map those onto visual changes that are meaningful. And most potential users of your low code tools are not capable enough to use it this way. If you take into considetation that visual comparators of workflows is extremely hard problem to solve (probably only bunch of people in the whole world is cable enough to do this in a way that anybody sane would use) then you easily see why all visual dev tools of last 30 years went bankrupt. And if you did any sensible research you would know there were hundreds attempts at it with some spending hundreds of millions of dollars (Rational and later IBM being main ofenders here)
    • jsunderland323 3y ago
      I wish I could show you something I’m working on — I’m just finishing up documentation now. I don’t think many people get this too. I haven’t launched yet but I think I solved this problem, my email is in my bio if you have any interest in talking about sane visual diffing and merging
      • v-erne 3y ago
        You mean floro (your nearby comment mentions it)? Hmm this looks more like na attempt at building better merger by getting rid of unstructured text and replacing it with some kind of structured/hierarchical data. I think that this can be useful but I don't see how this helps to solve general problem of visualizing diffs between workflow versions (and making it readable and mergeable for mere mortals)
• zubairq 3y ago
  This post about low code seems to be about companies using the wrong tool for the job. I would be interested to know which low code tools the blog author has actually used, and what they see as the viable alternatives are?
• codeptualize 3y ago
  I agree with this take. These tools can be useful for non devs to make very basic things, but they won’t be able to handle anything complex, and it’s hard to test and proof the correctness of the result. If you take it far enough you are always going to end up hacking around the tool. For people who do write code these tools could be useful, but code is much easier to use as you are not stuck within the constraints of the tool and know what you are doing. I think there is one success story for low code and its basic websites, mostly the part where a design is turned into code. I use Framer because it’s objectively quicker than code, with great results (I even design in framer), and once it’s set up non technical colleagues can make changes. Great for a landing page, but it won’t work for apps. I think the article is right in pinpointing the logic as the problem. Coding is not about syntax and the language, it’s about the logic and ability to map that out into a program with all the edge cases and details.
• hackerdad 3y ago
  low code should be a result not the goal. Let me explain: When you choose the right platform to build the applications, the platform should take care of gluing services, adding visualization, handle common concerns such as reliability, ease of debugging, documentation (with the visualization) etc. This is an often overlooked aspect of application platform that otherwise takes the bulk of the time to create apps. tools focusing in low-code does not solve them and the tool that solves typically don't market them as low-code - because the are not. low code comes as a result.
• merelysounds 3y ago
  I wish the author named the low code tools. There's so many of them, they can be very different, and offer different levels of control. Having specific examples would help me get a better understanding. Since this is in MS context, I'm guessing Power Apps; description: https://uk.pcmag.com/cloud-services/89779/microsoft-powerapps https://uk.pcmag.com/cloud-services/89779/microsoft-powerapp... (2018).
  • Towaway69 3y ago
    Not being the author but I agree with your request. For me: * no-code Basically all SaaS solutions that provide a web form to integrate and link services. Changes cannot generally be reverted nor is there any sense of version control. Only limited approaches for collaborative workflows. * low-code Things such n8n.io and nodered.org - visual programming environments that place a focus on data flows and not algorithmic code, alternatively known as visual flow based programming. These tools currently lack proper workflows for version control, collaboration amongst folks involved in the project. Hence these solutions generally do not have alternatives for the much-code development workflows. * much-code Textual code solutions using any one of a number textual programming languages. Very clear workflows and well defined processes for version control, testing and collaboration. Being extended by using AI for code completion and code generation. It interesting to realise that much-code solutions have been around since we stopped using punch-cards and many developers believe there are no alternatives to the classic keyboard,screen,mouse approach to software development. Perhaps it is time to rethinking our approach to development. Perhaps a two dimensional approach is more appropriate. Text, for me, being one dimensional: text is read from top to bottom, there is no left and right with textual code (in its basic presentation).
• noobermin 3y ago
  If you generalise to llm gened code in the hands of non developers then...
  • deleted 3y ago
    [deleted]
  • prakhar897 3y ago
    Like this? : https://www.resurrect.ing/ https://www.resurrect.ing/ LLM Gen code is far from perfect.
• kukkeliskuu 3y ago
  The expensive part of software development is not coding, but figuring out what needs to be done. It appears people are trying to optimize the less important thing.
  • onion2k 3y ago
    It appears people are trying to optimize the less important thing. ...which is also the expensive thing in most cases.
    • kukkeliskuu 3y ago
      Why is it expensive? If somebody can describe the problem with sufficient detail and unambiguity, the core coding part will be very straight-forward, fast and cheap to do, regardless of the programming language. The problem is that very often it is impossible to do.
  • kybernetikos 3y ago
    Low code is absolutely not about optimising coding (although I can see how you might get that idea). It's about moving the executable work away from specialised coders and to the people who actually have the problem. And when you can do that, you should. Low code is all about optimising the more important thing. The downside is that all those software engineering concerns that the average business practitioner is poorly placed to cope with often find a way of reasserting themselves and when they do, you typically end up with a mess worse than if you'd started with a code solution in the first place. However, in the domains that they don't, or where the negatives are not business critical or can be adequately mitigated, low code can be incredibly empowering to noncoders (excel is probably the canonical example).
    • kukkeliskuu 3y ago
      I think we agree more than you seem to believe. What I mean is that if the people who actually have the problem could describe the problem with sufficient detail and unambiguity, the core coding part would be very straight-forward, fast and cheap to do, regardless of the programming language. Of course the additional things beside the core, like change management, monitoring, security, APIs etc. would add to the cost, but they are at least possible if you are not on low-coding platform. The problem is that for anything basides the simplest applications, people cannot describe what they need in sufficient detail and unambiguity. This is where the cost of the application development comes from. There are many means to bridge this gap: user interface design, prototypes, agile development, waterfall requirements gathering etc. Excel is a way to iterate, that many professionals learn to use. If the end users can develop software that solves their problems, and does not cause other problems, there is no problem. From what I have seen, low-coding is sold to IT departments with promise of cost savings in the coding part, and to other departments as a means to bypass IT that they consider slow, expensive or not delivering what they want. So we need to get down to what we mean by low-coding and what context we are talking about. In addition to Excel, Django appears to hit another sweet spot in many contexts. It is very fast to develop and iterate with, comes with built-in admin UI, but it is still possible to add fill all the corporate technical requirements as well. The low-coding platforms the link points to that seem more problematic usually have some custom programming language, abstraction layers that often limit the extensibility for more complex applications, graphical ui designer, have difficulty supporting enterprise requirements (those security, auditability, monitoring etc.)
• redleader55 3y ago
  Unpopular opinion: low-code always existed. Examples: stored procedures, Oracle/MSSQL, SharePoint, SAP, "Cloud"(in the dumb, use-these-20-services-to-make -your-app, not in the IaaS sense), Docker, etc
  • mpweiher 3y ago
    "Since FORTRAN should virtually eliminate coding and debugging…" 1954 https://www.softwarepreservation.org/projects/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf https://www.softwarepreservation.org/projects/FORTRAN/Backus...
  • gardenhedge 3y ago
    How are stored procedures low-code?
    • cpursley 3y ago
      Not having to write messy business logic in whatever the hot programming language of the week is (which typically means many more lines of code than SQL and an order of magnitude slower).
      • gardenhedge 3y ago
        I am just surprised you think writing out sql and the logic surrounding it as low-code. To me it is coding.
• alserio 3y ago
  I've used AWS Amplify in the last two years. As the others low-code tools it's fine until it isn't, then it's a nightmare. But with time they've started to allow for more and more escape hatches. They've recently announced a V2 marketed not as low code but as code first, built on CDK. They've probably found that most of their users are devs and code is the right interface for devs.
• rikroots 3y ago
  My low-code horror story contribution. Big Important Company decided to develop some in-house learning courses for their Marketing and Sales folks. They used a trendy-for-the-time low-code learning course creation software package to develop the courses, and a different piece of software to deliver it to staff on their on-site intranet. A few years go by. Someone in Big Important Company decides the courses need updating. Work ends on my desk as my bosses have the contract to maintain various other bits of BIC's creaking self-hosted intranet. I ask questions like "What software did BIC use to develop the courses?", and "can we charge BIC the cost of getting the software so I can do the work?" Of course, the answers are all along the lines of: no. So all I have to work with is an extensive set of hefty change requirements to the courses, and a SCORM package downloaded from BIC's intranet. A huge amount of learning (how to manually edit SCORM packages) and frustration (how to test changes to SCORM packages), and a few months of time when I could've been doing something better without deadlines harassment ... I completed the work. Which I wasn't allowed to test on BIC's intranet servers for "security". So I just uploaded the new SCORM package to their production servers and went on 2 weeks leave.
• zby 3y ago
  Is there any good definition of low code and no code solutions?
• lovasoa 3y ago
  I make a SQL-only website builder (SQLPage) that could be qualified as low code. I think all the points mentioned are valid, but some of them are easy to work around: > They wanted truly custom functionality that the low-code solution could not handle. It's important that the low-code solution has an escape hatch, or a way to to interact with external "high-code" APIs. In sqlpage, we have sqlpage.exec > They implemented a bunch of custom functionality in a product-specific or even proprietary language and now their pool of potential developer talent is tiny. I agree that low-code makes sense only if the low code is in a standard, popular language. In SQLPage, it's all just SQL. > Upgrades to the low-code platform would break their custom implementation. This is a true problem. The low-code solution really has to be careful with updates. > The underlying database structure was an absolute mess, especially after a bunch of incremental modifications This! Most low-code tools take your data hostage. You shouldn't use them. In SQLPage, we add a layer on top of a database that you still fully control.
• hiAndrewQuinn 3y ago
  Python is already low code enough with the use of GPT-4, I'm good.
• ejb999 3y ago
  Much earlier in my career I built an entire business converting MS-Access database/forms solutions that were created by non-developers/end-users to solve a particular problem without involving IT folks, most of them 'sort-of' worked, but only up until the point things got complicated, or the requirements changed, or it needed to scale and nobody (the non-developers) could figure out how or even realized their entire foundation was built on quicksand. (I would generally convert them to true .net client/server applications with MS-SQL Server as the back-end or web front-ends with a proper database on the back). I suspect there is another opportunity coming along to make some good money bailing out folks who built 'no code' solutions that their business now depends on, but no longer meets the needs and has become to fragmented and complicated to tinker with and difficult to change, scale or adapt. That said, I am not opposed to no-code - it is a good and often inexpensive way to solve some problems, or at least get a POC working - many of those solutions may never need to scale or adapt. ...but some will, and thus the coming opportunity.
• anonymous344 3y ago
  was really interested about MS low code platform, but then... it's a mess glued on top of another mess(o365), glued on top of another mess (azure) what seemed to be true that you can easily build a gui that will break in the next months and only have terrible default ui-elements, like calendar selector you cannot really prevent going past time or 99 other akward user interface gimmicks. why should company try to save 2000$ on development, but then loose 10-100$ every single day with bad usability?
• Poliorcetes 3y ago
  maybe low code is the next step after text- based programming? There is a comparison here to be made with ascii graphics and they could be quite charming, dwarf fortress for example looks great but there is only so much you can do with text some languages it seems to me are running out of symbols and their meaning is not obvious at the glance, for example what is the meaning of ', @, $, !: in diffent languages? why should it have that meaning in the end code is much more logical and better understood if it is a diagram of blocks, after all that what code is supposed to represent, a series of decisions that lead to a desired state in the data
• bazoom42 3y ago
  Python is low-code compared to assembler. SQL is low-code. Much discussion around low-code (and no-code) miss that it is just abstraction. The question is not if we should use abstractions or not, but what constiutes good and bad abstractions.
  • lioeters 3y ago
    Another term for "low code" is end-user programming. > Despite forty years of commercial products, open source, and deep academic work, we have yet to reach an end-user programming utopia. In fact, the opposite: today our computing devices are less programmable and less customizable than ever before. https://www.inkandswitch.com/end-user-programming/ https://www.inkandswitch.com/end-user-programming/ COBOL, BASIC, SQL. HTML, CSS, JavaScript. All these started as relatively low-code solutions to what came before. And surely textual programming languages aren't the only way to empower users to take control of personal computing. Excel formulae to express dynamic values. Visual builders that internally compile to syntax trees. They all have their own problems and room for improvement, but one could say the same for "high code" programming languages. It's a means to an end, and for computer users who don't have time to dedicate to become a high-coder, they will use whatever is available to solve their needs.
• skeeter2020 3y ago
  >> A lot of low-code solutions seem to hit about 80% of a company’s requirement. The 80% is not evenly distributed. Marketing might have problems that are 95% satisfied by low-code and they can change their process for the last 5%, or accounting can do 100% of a 50% subset of their job with low-code. Logistics can't really do any of their job so they steer clear. All the other points are related to trying to satisfy 100% of a custom problem with a generic low code framework. Don't do that. You run into all of these problems with custom code solutions too; The debate should be about investment vs. control, of which no/low/custom coding is a component but not the differentiator as presented here.
• tyingq 3y ago
  It's a hard topic to discuss sometimes because low-code means different things to different people. There's a space, for example, where it mostly just replaces spreadsheets on a shared drive (or being emailed around). And there's also "mostly web forms with a little bit of workflow and approval hierarchy". Then "simple-ish database with reasonable basic CRUD gui". The various vendors usually start with one of those, then feature creep into more customization support, including code that's invariably hobbled in some way that makes some tasks impossible.
• gregd 3y ago
  Having worked in PowerApps the last year and integrating a rest API in Azure that then updates Dataverse, low code is just short for abstraction layers. As a developer, this irritates the hell out of me. Sure, you can view your Dataverse database in SSMS, but it's read only and you get no autocomplete. And don't even get me started on XRM Toolbox.
• Poliorcetes 3y ago
  one thing that seems to me is that there are no open source low code platform, that is as easy to get as python or java is there any of them out there? all i see is proprietary software with hefty prices
• lerpgame 3y ago
  actually, software itself and any sort of interface/automation in general is really just an interim solution before transition to just having real-time access to scalable raw intelligence and hyper awareness through wetware.
• arey_abhishek 3y ago
  I'm a founder of Appsmith, a well-known open-source low-code platform. We offer an alternative to tools like Outsystems, Retool, and PowerApps. I often meet people who share the skepticism about low-code seen in this post. It's crucial to understand the advantages of low-code for specific situations, especially in developing internal applications. These tools, often neglected due to limited resources or developer disinterest, can be rapidly and effectively created with low-code solutions. Low-code excels in scenarios where internal teams are overwhelmed and business users face long waits for features. Although it's not a cure-all, low-code is highly effective for certain tasks where speed and ease are key, despite sometimes facing limitations in customization. Some modern low code tools are also evolving to be closer to web frameworks. Plasmic is one my favourite examples of this.
  • knappe 3y ago
    > Some modern low code tools are also evolving to be closer to web frameworks. Plasmic is one my favourite examples of this. So this hits on one of my questions/observations. How different is low code to the generators of various web frameworks? I'm thinking things like Rails, Django and the like where a lot of the "low code" appears to be templatized. They sure feel VERY similar.
    • m3047 3y ago
      People have the wrong mindset about all this. The most continuously integrated / continually deployed code process in the world is desktop publishing. You draw. You press print. Something prints. Contrast to printing per se: You have some text and graphics. You do wire frames. Now you have to decide about the next part of the process: are you going to go with litho or a more traditional layout process? Now you do either cut & paste or cast / etch / burnish plates and / or masks. Now you print, which actually involves doing multiple prints in different colors which all have to line up. (And that's the simplified version, it's a lot more complicated than that.) Desktop publishing is actually a code development process. A Postscript(r) printer knows a programming language called "postscript" which interfaces to something in the printing engine which is called the "raster image processor". Postscript programs have libraries, and the printer gets transpiled code for the RIP to execute. (Does this sound like your web dev shop?) The location of the RIP has meandered back and forth on the workstation <-> server <-> print engine continuum due to various factors; this looks a whole lot like the compute / display continuum and the endless debate about how smart a display device needs to be. Now, the color is never quite as good with DTP, mach banding, dithering, blah blah blah. Like I tell my wife, the artist, the only person who knows that's supposed to be insane blue, and that over there is outrageous orange is you. (When she prints cards she secretly does hand touchups with the true pigments which are a mote in her mind's eye.) For most things on the planet, normal people will settle for desktop publishing's shittiness. What's not shitty about DTP is the democratization. Instead of one person publishing to a million, it's (potentially) one to one. I wish, I truly do, that all of this mattered for the web but it doesn't. The web is largely free, and at the scale of free everybody gets the same unique experience. On the other hand if I have a $1,000,000 warehouse facility even if there are 100 people working there I want them to have the best experience possible. I'm going to tailor that experience based on job function, where in the facility they operate, what they do. If someone is missing a finger, they should have an interface which takes account of that. $50,000 piece of machinery with one user? Optimize that user to optimize that machine. Welding gloves, or gloves covered in fish guts? Special interface for you too. A good low code solution comes with OT drivers, speaks to SQL and microservices; produces true and correct (legally speaking) audit / transaction / snapshot logs (because if someone gets poisoned by the product or loses a hand working with the machinery...); has MES (workflow) as a low code function.
• rubin55 3y ago
  Very recognizable.. I've done a few projects at large-scale government and retail where me and team have been brought in after-the fact to fix "performance" and tech-debt issues with these things. In particular these platforms: "Be Informed" and "MuleSoft AnyPoint". The story is exactly like the fine article mentions. Heavy reliance on proprietary stuff making the organization heavily reliant on very expensive consultants to get stuff done, no way to sanely version things.. I now go out of my way to avoid working rescue jobs like these, unless the client is actively migrating away from them.
• iamleppert 3y ago
  I am for whatever tool I can sell to frustrated executives for a handsome commission and be half way on to my next job by the time they figure out it’s pure, 100% snake oil.
• deleted 3y ago
  [deleted]
• FrustratedMonky 3y ago
  Isn't it a continual upshifting of concepts. C is the low code version of Assembly Python is low code version of C Some visual basic like thing is low code Python WordPress a million other web tools Etc... But in the end, someone with a 'programmer' mindset, that can understand problem solving, is needed to make it work, at whatever level we are at.
• astrobe_ 3y ago
  To me that's 4th generation languages, RAD and such, with new cloths. They have their uses, but they also have the same drawbacks.
• hm-nah 3y ago
  Low-code platforms like PowerApps and PowerAutomate are great LEARNING and PROTOTYPING tools. Give an analyst with some technical acumen PowerApps and ask them to mock up requirements, and after awhile, they can produce a click-through prototype. That same analyst will likely improve their UI, API, JSON and SQL skills in the meantime. Low-code tools are also good for digitizing CRUD forms. Much beyond that and things get very proprietary, very fast.
• ivix 3y ago
  The opinions of developers about low code solutions are not very relevant. Low/no code solutions exist for when there isn't enough time or budget for a developer created solution, which is to say, pretty much all always. In the real world of business problems, almost nobody has access to a professional developer.
  • RaftPeople 3y ago
    Maybe I'm misunderstanding your comment, but typically companies have teams (architects, developers, etc.) on staff to help solve business problems.
    • cookie_monsta 3y ago
      Why would you assume this? The company that I work for (~ 1000 employees) has one part time employee who manages sharepoint. Any new software we wanted had to go through the procurement pipeline before we discovered we could use powerapps without asking anybody's permission.
    • alphager 3y ago
      Sure, but they are there for the /big/ problems. The myriad of small real-life problems that sometimes are solved by an intern with Excel and VBA are way too small to get handed to the professionals. Those things that would cost just 2 developer days are never handled (because the dev org doesn't keep a bench of developers sitting around for these small one-off tasks and thinks in multi-year projects).
• nickfromseattle 3y ago
  I used a low code platform to ship a product that has generated $170,000. It can't do everything we'd like, but there is always a workaround that is "good enough".
• Poliorcetes 3y ago
  I don't think anyone mentioned matlab's simulink or it's free clone, scilab xcos, which are more targeted at modeling electronic and mecanical systems, solving differential equations, that sort of thing, I have fond memories of them from my classes, but never got to use them in the workplace then there is also labview, the programs for the equipment were mostly made by former students in that program low-code is old as dirt by now
  • __loam 3y ago
    I had to use labview once in college. It's garbage.
• hacknews20 3y ago
  I have been a proponent of no-code low-code and in the last year or so your second point has been the biggest problem we encountered on projects “…developer talent is tiny.” The talent is now more expensive than code developers. However, the net benefit for most web apps is still there, that once you established the “platform” i.e main aspects of your “thing” the low maintenance burden starts paying big dividends. With rapid prototyping we do traditional dev, then transition web apps to no-code because the burden is in the through life aspects and no-code wins there.
• syndicatedjelly 3y ago
  At my last company, I inherited the reins as custodian of a low-code application. Except this low-code application was designed in the early 2000s. Back then, "low-code" still involved HTML, CSS, Javascript, and a database scripting language - so I at least FELT like a programmer. That job paid a round-robin of 10 developers in 3 different locations over the course of ten years. In total, it probably took a total of 30 person-years to develop and maintain the software in its lifetime at the company. This is on top of the $1 million/year licensing fee for the proprietary tool in all its own glory. This included a: - proprietary, closed-source database - proprietary, closed-source scripting language - proprietary, closed-source "CI/CD" (more like, barf out some arbitrary, insecure mash of HTML, CSS, and Javascript into the browser) We spent a significant amount of time trying to peer under the hood. Except, it was more like we were trying to rip the head off the cylinder block with a bunch of vice grips, and then safely put it back together. I cringe thinking back to the tactics we used to "research" - it was like hitting an engine with a hammer and trying to figure out what it does. We came up with all sorts of theories about hammers, about sounds that engines make when hit with hammers. But it was a complete waste of time. That's not how you study an engine. No transferable skills are learned in the process. I try to make sense of my time there - I'm only a few years removed from that job still. I sometimes feel embarrassed that I didn't get out of there sooner. Why did it take me so long to figure out my software career would go nowhere if I worked on stuff like that? I'm in a much better place now, working on good software in real languages with smart people. My skills have grown unbelievably in just a short space of time. === Low-code applications are worse than what everyone is saying. They are career-destroyers. It's okay to dip your toes in the water. But it's too easy to become reliant. You'll find that database details, CI/CD, even version control are handled by some mythical low-code tools that you don't understand (and can't configure). Work on software where the company is in full control of every line of business logic they own. You might own only one small slice of the software, but it's so much easier to sleep at night knowing that every bite of the pie can be fine-tuned according to SOMEONE at the company.
• intrasight 3y ago
  >Upgrades to the low-code platform would break their custom implementation. Likewise an upgrade would break our custom SAP implementation. Most all big ticket business apps are "low code" and suffer this problem. >The underlying database structure was an absolute mess, especially after a bunch of incremental modifications. Ditto with all enterprise software I have used. All big businesses depend on low code enterprise apps. For that matter, a SQL database is a low-code platform.
• GabeIsko 3y ago
  Man, y'all haven't been around software consulting long enough. First, you have to sell low code based on the premise that you don't need coders to make your software. Than, for custom functionality, you explain that you need developers on the platform to get certified. Finally, you make sure to not document anything so that consulting firms with legacy experience have a monopoly on developer talent in order to keep them happy and recommending your software to others to score large consulting contracts. Everyone is happy! Especially the people who actually have to use the software made this way! As we all know, enterprise software has a reputation for being extremely user friendly...
  • vsskanth 3y ago
    I think you just perfectly described the MO of SAP
• EntICOnc 3y ago
  a research done by a Portuguese university on "Preparing Students for the Software Industry New Demands" and as documented in https://www.i-programmer.info/professional-programmer/103-i-programmer/16667-why-software-engineering-will-never-die-.html https://www.i-programmer.info/professional-programmer/103-i-... found that " that low code platforms, while allowing for fast learning development processes, enabling a more systemic view of software projects and providing easy integration with other application endpoints, can't escape good Software Engineering, as low code's inherent abstraction requires following good development practices" So no matter,you have to a developer and not just citizen developer
• atoav 3y ago
  The hard part about programming isn't code. It is wrangling complexity, it is understanding cause and effect, anticipating edge cases and by clever design choices avoiding catastrophal (or sometimes just annoying) problems from the start. Low code is a dumb persons idea how to make programming easier — the kind that thinks memorizing all the weird letters and signs is what makes programming hard. The result will be that you will have non-programmers learn how to become programmers by failure — in production — on the job. I always welcome things that bring complex system interactions closer to learners. But it comes with considerable risk : )
  • JonChesterfield 3y ago
    The hard part of programming should be the problem you're solving. Fairly frequently, the hard part of programming is all the incidental crap that gets in the way. You change the existing system slightly and a bunch of not obviously related parts fall over. Someone updates the OS on the CI box and now you're dealing with dependencies with dubious ideas about semver for the rest of the day. Nothing changed overnight but now the performance bot is reporting a regression.
    • atoav 3y ago
      Yes and the problem you are solving is always about complexity. It is extremely rare that you have a problem where your solution can be a simple black box with a few inputs and one output. Most of the problems have many inputs, some of them malformed, many outputs, race conditions, multiple writers, time dependencies, weird edge cases, etc. If you really wanted to punish me you would force me to reimplement the good software I wrote in no-code tool. And I am a fan of node editors in VFX. I know how to wrangle complex node graphs efficiently. But in VFX you have a clear direction of flow and it is the simple black box described above. Structured text is a great and extremely efficient way of describing, editing and manipulating programs. Your node editor has to beat that for anything non-trivial — because even the simplest scripts I wrote for my employers had to handle any number of non-trivial cases. You are aware that dependency problem would be literally the same if your dependencies were made out of nodes and connections? Only now the debugging is harder. If you hate dependencies fucking your day up in code, you could always just not have them and write everything yourself. Like our fictional node wrangler would have to. I mean I can feel you. But nodes don't make these problems go away and structured text didn't create them. I meant what I said about complexity. This is not about code, it is about complex systems. A programmer who knows race consitions is also likely to be able to predict one in a completely peoples based procedure that doesn't involve computers. A programmer who knows about distributed systems will be likely to predict the same problems emerging from multiple distinct departments of a company, etc. If you want to tackle a problem involving complexity, you get people who know how to do that and you don't care whether they use nodes or structures text to do it as long as it gets the job done. Or you could make the tools look harmless and give that power to people who have no idea what they are doing. In many cases it might go fine, in many it will lead to much more complexity for when you finally hire aomeone to clean it up.