11 ms·

Low Code Software Development Is a Lie

282 points by jandeboevrie 4y ago

WheelsAtLarge 4y ago
I'm of the believe that low code is for small and low complexity software. Often I find myself wanting to do something that is relatively simple but it needs to be done many times. I often have to weigh the complexity of writing a script vs doing it by hand. Let's say it takes 2 hours to write code vs 1.5 hours to do it by hand in some situation. Low code could make my decision much easier if, as it promises,writing the code took less effort. But I don't think anyone would pick it to write complicated and long code. I think it has its place as a code writing tool. The big issue to me, and the article's author, is that you are locked into whatever tool you use. That and the never ending subscription makes it a very unattractive choice for any project no matter how simple it is.
kfk 4y ago
I have an Enterprise story on this. The low code tool I was using increased the price x10 on me after the first 3 years. The price increase was poorly managed, they looped me out and tried to talk directly to the IT leadership which was a disaster for them because they had 0 experience handling Enterprise contracts. I don’t think these low code tools are worth the trouble of dealing with their inexperienced sales people. Maybe some low code tool companies are better, but I am done with them anyways. Most of these tools promote bad coding practices like no clear split of dev and prod, no version control, no testing. I am not sure if these low code companies know what they are doing and how complex it is to maintain an enterprise app over 5/10/15 years.
- ethbr0 4y ago
  Name and shame!
  - cowanon222 4y ago
    Not the poster, but Microsoft Powerapps had a massive price jump a few years ago, followed by a pretty large decrease last year. Through the grapevine I have heard the same about Mendix and Outsystems - in my company we found that hiring internal developers is cheaper than paying the licenses at scale. (About a 10k employee company) It may work for smaller depts and apps, but Retool or Airtable is often sufficient for these teams, and much easier for non-developers to learn. We do use Appian and Pegasus for some smaller depts.
    - ethbr0 4y ago
      Microsoft product positioning on Power* seems extremely weird from the outside, which I chalk up to internal division politics. It's like they can't decide if they want to give it away to grab market share or make money off it. And pricing updates reflect whichever group wins the last debate.
zabzonk 4y ago
> It is actually the result of clients and developers not taking the time to understand the root causes of the problems they want to solve i certainly agree with this. it seems weird to me that the job title "systems analyst" has disappeared frpm the job market (speaking as someone that used to be a "programmer/analyst") and has been replaced with ... nothing?
- didgeoridoo 4y ago
  TPM (technical product manager) maybe?
- Closi 4y ago
  I agree with that statement, but disagree with the conclusion ('because of that no-code solutions are not useful'). The benefit of low-code is that you can spend more time understanding the root causes of the problems, and be able to quickly prototype solutions that match the user requirement (and that you can make changes to more quickly) than would otherwise be possible. Of course if everyone had infinite time, we would build full solutions for everything, but in a world with limited time and resources these tools can have a great place in the toolbox.
ramraj07 4y ago
Tell that to all the labs running on labView
- avsteele 4y ago
  I have pretty extensive experience in this domain. Personally, I found there is a application complexity ceiling above which LabView was not viable. It is pretty great for rapid data collection and analysis, and it is well integrated with a variety of hardware. But once there is a few things going on at once the "backplane" abstraction becomes unhelpful. So many vendors provide python libs these days, and python plotting is good enough in these that it is harder to justify LV.
- peteradio 4y ago
  Labview is awful, I joined a lab that had attempted to build instrumentation controls in labview. Replaced with pyvisa and was able to write much more complex controls and automation without crying.
- IshKebab 4y ago
  I suspect they would agree! LabVIEW is code, just in a truly awful format. Simulink is perhaps a better example because it is at least relatively good, unlike LabVIEW, which is the worst thing ever. (And if you're wondering why people use it, it's because NI makes a ton of very good (and very expensive) lab equipment and the software they provide to drive it is all LabVIEW based.)
_xivi 4y ago
Low code is useful for prototyping and validating ideas. I wouldn't count on it for anything long-term
- toyg 4y ago
  As anybody who went through the 80s/90s knows, the prototype almost invariably becomes the production artefact. "Why should you rewrite what already works?!?" Actual building engineers don't have this problem, since the prototype is so obviously not the real thing. Software engineers have to make an actual effort to keep "civilians" from mistaking a prototype for the real thing.
RyanHamilton 4y ago
To hell! I'll throw myself to the lions. I make "Low Code" software and I think it's useful. It allows anyone who knows SQL to build real-time interactive HTML tools: https://www.timestored.com/pulse/tutorial/pulse-interactive-table https://www.timestored.com/pulse/tutorial/pulse-interactive-... These people often only know SQL, so can't write javascript/html/react. The example video shows allowing them to create a live updating table that when clicked, draws a chart for that row. The best use-case is for prototyping many more apps than would be possible if they had to run every idea past a UI developer. Eventually some of those ideas get taken to full production based applications, many don't. I'm open to any and all feedback. If you think it's useless please say why and if you think there are better tools, well I would appreciate that feedback too.
- k__ 4y ago
  To me all software that requires minimal coding skills to use is low-code software. It's basically the job of a developer to move concepts that require coding through abstractions over to low code and then no code solutions. "Low code" or "no code" is just giving it another name, like when people started calling other people's servers "the cloud".
- galaxyLogic 4y ago
  Note that SQL is not no-code. You could say it is low code, but still it takes a "coder" to develop and debug it. It is a text-based format not GUI-based.
  - rwalle 4y ago
    RyanHamilton did say it's "low code".
- bob1029 4y ago
  Fellow lion pit enjoyer here. We also use SQL for our product to deal with all the client customization needs. This has been our path for about 4 years now and we still haven't found a better option for our business. If you build a SQL schema and involve the business stakeholders in that process, you end up with something everyone can understand & work with. The difficulty of writing SQL scales in direct proportion with the complexity of the schema/domain. If the schema is something that is fundamentally familiar to your team, then you already have 80% of the "language" trained into your employees. At this point, showing them a few examples is all they usually need to "get it" and start doing things on their own. Inevitably, you will run into "how do I write a query that answers 13 questions at the same time and arrive at 1 final binary choice", and need to babysit with decomposition & CTEs. But even with some examples of those the team can begin to take matters into their own hands. In my experience, the joins are the hardest part. If you can, organize your problem such that even very inefficient nested queries can complete in a few milliseconds. We do things like run SQLite in-memory to achieve this outcome. Allow the team to do lazy crap and get shit done. You can always iterate the queries for quality later on - I think an LLM does this for us in our near future.
BulgarianIdiot 4y ago
"A programmer whose salary depends on being an unsurmountable middle man between boss and machine, declares that solutions for surmounting him are a lie." - The Onion, probably
- shanebellone 4y ago
  I've upvoted this because it's funny and mostly true. However, the outputs from no-code and hand rolled are not equal. It blurs the distinction between custom and off-the-shelf. With no-code representing something closer to the latter.
  - oriolid 4y ago
    There's a lot of money to be made in first trying to customize an off the shelf solution, then trying to replace it with low code one and finally implementing a custom one.
    - shanebellone 4y ago
      Sure. Yet any no-code derivative is therefore stuck with a general-purpose implementation. Which admittedly is fine in many contexts. However, the distinction is important. You "assemble" no-code. You cannot buy a dog puzzle and reconfigure it to be a cat puzzle. IMO, this is the inherent limitation of a no-code toolset. Also, users are handicapped by the developer's capability. That is to say, the efficiency and specificity of the tool's internal codebase represents an invisible glass ceiling for its users.
- djaouen 4y ago
  You do realize that low code solutions are actually the middle man between boss and machine here, don’t you? This is like comparing Node and Drupal and announcing that Drupal is the superior technology. Ick.
  - Avshalom 4y ago
    So's a compiler, and an operating system, and microcode.
docflabby 4y ago
Find me a non code product that can do something excel can't
- shanebellone 4y ago
  A 1-page website.
  - yebyen 4y ago
    It is incredible in some teams how difficult it can seem to be to get from "we need a 1-page website" to "ok, it's online and you can update it simply without any more of my help. Here" And with the difficulty going up, the likelihood that you'll do this when it's needed and makes sense to do goes down. I can't tell you how many times I said "I need a website" and didn't end up posting one, because we didn't have a ready answer to this question, and nobody could be bothered to go out and build one. Just a simple one page website. I can think of at least three "easy" ways to do it (and that's my whole problem in a nutshell, thanks for coming to my TED talk.)
    - shanebellone 4y ago
      I think the problem is this... Those who need a simple solution require considerably more tools than a 1-page website should require. The user specification requires those tools to interact with the website, without technical help, in perpetuity. That's a MONSTER requirement.
  - is_true 4y ago
    File > Save as > index.html
    - shanebellone 4y ago
      This made me laugh. You get an upvote. :D
    - deleted 4y ago
      [deleted]
alkonaut 4y ago
“Low code” is such a blurry definition. Is excel low code? Is a shader graph in a game engine low code or no code? Regardless of which, they’re useful.
ryaniscool 4y ago
What I’ve found is people who use low code tools are more willing to lower their expectations to the capabilities of the tool. This is in comparison to your typical customer of bespoke software development who has a long laundry list of requirements that they’ve imagined up based on their perfect vision. If “good enough” was good enough for these people they would be using low code tools
- papito 4y ago
  To make it worse, the customer's "vision" is almost always wrong. It takes great skill to extract from them what they really want - otherwise you allow the customer to be a tech product manager, which is a no-no.
deleted 4y ago
[deleted]
galaxyLogic 4y ago
Low-code tools make you really lock-in with the provider of such a tool .
krishvs 4y ago
I'm quite bullish about low-code tools now. Especially for building back office systems like ERPs or operational tools. From my experience most failures in such project implementations have been due to mismanagement in the requirement gathering phase and also development happening in silos where the team building has no real understanding of the business process workflows. But with gpt-3.5 - these tools can really inlock the ability of non technical people to build products. Maybe outsystems should have a gpt chat interface that builds software on its platform directly from the requirements of the end user instead of any intermediate human development team.
Closi 4y ago
> Designing a solution worth a damn is actually the most difficult part of the software development process. Low Code tools lie to customers by implying that the writing of code is the hardest part. I don't think there is a lie here. Writing 'production-grade' deployed code is the hardest part for people who can't code, but that do understand processes and how to design them. There are plenty of people I have come across who cannot write code, but who are still intelligent and could design a robust process. This is the benefit of low-code and AI tools: liberate the ability to develop software tools to people who are capable but don't want to spend years learning to program.
rwalle 4y ago
Nonprogrammers used to use FrontPage or Dreamweaver to develop websites. Now they use things like Google Sites or Wix for that matter, which works well enough for a lot of individuals and businesses. This is a real thing that has been happening for decades and is not a lie. This article is a lie.
TheLoafOfBread 4y ago
Low code is still a code. It is just matter of time before some office worker will create large and humungous low code project which then will be used by half of the office. Because worker never coded before, whole project will slowly (or quickly) become unmaintainable mess where one change will brake 3 features. Then they will call a developer to sort this mess out and it needs to be done yesterday.
- jrochkind1 4y ago
  People who have spent years coding are also perfectly capable of creating unmaintainable messes where one change will break 3 features, thank you very much.
  - TheLoafOfBread 4y ago
    When you will be now "maintaining" 1000+ row VBA macro script in Excel linking dozens of files to generate a report and office folks will ask you to fix it because it does not work properly and author was laid off month ago, you will have different opinion.
    - jrochkind1 4y ago
      Perhaps same opinion as if you're maintaining a, I dunno, 50K+ line software package as a development-team of one, which was developed by a single developer (who learned to code on the job) over a 10-year period and he left a few months ago. (Yes, this happens). Many "low-code" solutions definitely give you enough rope to hang yourself. In this regard, ironically, they are more similar to than different from other kinds of coding. I'm not even sure Excel should count as "low-code". A multi-thousand line VBA macro script doesn't sound "low code" at all, right?
      - TheLoafOfBread 4y ago
        As I wrote in first post, low code is still a code. And there will be some office worker who will have enough time to pile up a massive project which is not documented, nobody knows how it works, the worker is gone, but half of office is dependent on it.
gregjotau 4y ago
You can often mix low-code into a solution that requires some code, I did that recently creating a custom review app for a Shopify store: https://respiroc.com/blogs/software/how-to-make-your-own-custom-review-app-in-shopify-using-airtable https://respiroc.com/blogs/software/how-to-make-your-own-cus... Basically: 1. Airtable (low-code) to be a database + submitting new data 2. python code to sync to shopify 3. frontend liquid code to display reviews. I have built a lot of low-code with Airtable for a 5-6 million dollar business (revenue per year). Product development system, warehouse management++. And just to be clear: The good no-code systems are still built by coders.
rwalle 4y ago
> Low Code tools lie to customers by implying that the writing of code is the hardest part. Not true. Low code tools often excel at fast prototyping at decent quality -- if you feel comfortable enough you can ship them as is and you have a functional product. That might be all what customers want or care about. They don't produce the best code, but nobody really cares in the real world.
cushychicken 4y ago
A few effective counter examples I can think of, off the top of my head: - the Apple Shortcuts scripting framework built into iOS 16 and above, - gnuradio - a block based signal processing environment for software defined radio - Scratch - the learn-to-code block language that’s evolved into its own programming environment I suppose you could call these programs’ no-code premise “a lie” based on the premise that all of them have text based code under the hood. But I also realize you can rebut that pretty easily by saying that the graphical flows can address a lot of custom functionality required by their user bases. Speaks to me of those programs solving problems with a relatively well defined set of constraints. I wouldn’t describe current web apps, and the rich frontend functionality required, as meeting the criterion of having a “well defined set of constraints”.
- flir 4y ago
  I think you can add IFTTT to your list (https://ifttt.com/ https://ifttt.com/). Maybe Yahoo Pipes too.
  - cushychicken 4y ago
    Never used either of them myself, but a cursory inspection suggests they fit the paradigm I’m talking about.
- wizzwizz4 4y ago
  Apple Shortcuts is just rubbish shell scripts with an excellent GUI. Scratch is certainly a programming language: it even has a textual representation. https://en.scratch-wiki.info/wiki/Block_Plugin/Syntax https://en.scratch-wiki.info/wiki/Block_Plugin/Syntax. I haven't used GNU Radio. Some of these "no-code" systems aren't programming languages, but the examples you've given are definitely programming languages. They've even got their own Wikipedia article (https://en.wikipedia.org/wiki/Visual_programming_language https://en.wikipedia.org/wiki/Visual_programming_language) which lists GNU Radio (though it also says behaviour trees are programming languages, so I'd take it with a pinch of salt).
  - 4y ago
JimDabell 4y ago
The heart of this complaint is essentially that some people think that the difficulty in implementing something is because it requires code, and they can’t write code. “If only I could code, this would be easy”, they think. Code, as they view it, is incidental complexity, not essential complexity. For a lot of tasks, this is actually true. Take away the requirement to write code by supplying them with a low code tool, and suddenly people can do lots of useful things that they couldn’t before. So in that respect, it’s no lie. But of course, there are a tonne of other situations, where code is not the only complexity present. Sometimes you’re just trying to solve a big, complex problem. Take away the coding requirement, and you’re still left with a tonne of complexity to manage. And low-code tools aren’t the best for handling that. In those cases, you’re better off hiring developers. I’ve seen a few people build very complex things using low code tools. Modern ones, but also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools. But that doesn’t mean low code tools are useless – they are great for the first set of problems, where the code required is just incidental complexity. You shouldn’t write off this substantially useful product category just because people get into trouble using them for problems they aren’t suitable for.
- Closi 4y ago
  Totally agree - right tool right job. Sometimes writing a full web application is the right solution, other times you just need a database with a front end and a low-code solution is best, other times an excel spreadsheet will be the right solution, and other times just physical process change is best. Why take something out of your toolbox?
  - pydry 4y ago
    >other times you just need a database with a front end and a low-code solution is best Until you need it to do something slightly beyond its capabilities and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one small feature.
propter_hoc 4y ago
Programming tools have a continuum between power and simplicity (or, lines of code, or developer efficiency). You wouldn't (couldn't) write a device driver in Python, but you also wouldn't want to develop a dynamic website in assembler. Low-code tools are a level beyond high-level languages. They are particularly useful where they are domain-specific, and offer focused functionality that makes them more effective for certain applications. Additionally, commercial low-code software can offer batteries-included solutions that you would have to pay for anyway. As an example, my company's product is a low-code platform for pdf workflows in finance. The language allows for rapid implementation of form workflows, including validation, pdf manipulation and e-signatures. It also includes features like sso, api integrations into obscure financial databases, whitelabeling and various tailored user and admin interfaces. Could you build arbitrary form workflows with a web service like RoR? Sure, but it would be a much more complex and expensive project, and you'd have to pay for a docusign API license anyway. I checked out Outsystems that the OP mentioned, and it seems like one of these more generic all-purpose services. I don't really think you can square low-code with all-purpose. The lift in efficiency you would get is stunted by the requirement to maintain the power to handle too many use cases. If you need to support every single industry under the sun, you can't focus on really good deep native API integrations, or you'd have to charge so much money you lose your value proposition.
- deleted 4y ago
  [deleted]
- lifeisstillgood 4y ago
  Interesting - in my head then for each industry there is a space for reusable code components that tackle certain industry needs - either OSS or prop - and that are so standardised that it takes one dev one day to put them into useful action. I think what I am saying is that good low code solutions are pre-packaged fixes to well defined common problems - and it's not that important if they are glued together with Rust or a drag and drop UI
  - deleted 4y ago
    [deleted]
ethbr0 4y ago
Low code software development is not a lie -- it's a trade-off. You gain (a) canned components / patterns for rapidly performing common tasks, (b) opinionated design that encourages one particular solution, (c) support for any issues from the underlying stack. You lose (x) open development ecosystems, (y) general purpose flexibility, (z) ability to evolve a tool however you want and fix your own issues. Given the above, when does low-code make sense? When you have a common business use case, that happens frequently, and you'd prefer not to train/retain developers to deal with it. Generally, the dominating value of low code is directly proportional to how much of your use case the canned functionality solves. Some examples of where it's a good fit: application-application automation (provides interface glue and exposes higher-level actions), CRUD app generation (uses common design patterns to build everything the user doesn't need to change), data flow (allows the user to declare what should happen, then generates the how). If you find yourself hacking functionality into a low-code tool often or substantially, it's inappropriate for your task. If you're trying to use low-code to deliver a core business competency, it's inappropriate for your business. Use it for the boring and less important stuff, that's not worth developer time. In the same way that businesses rent instead of buy carpet (because it's not a core competency), most businesses shouldn't have full in-house development teams to do ancillary development tasks. Source: worked in UI automation for a decade+ and watched customers and the industry
- Closi 4y ago
  Agree entirely. As an additional point - If I have an entry-level clerk who does 2 hours of work per day that could be automated by putting a dev to work on building a solution for a month or two, it won't financially stack up. I also don't really want to pull that dev off to work on that, because I could probably have them working on better stuff. If we could build something a bit more scrappy in a low code tool in a few days and pay $40-$80 a month in licencing, that will stack up fast. Will it be as good as the full-code solution? Probably not - but we weren't ever going to build that solution anyway and it's better than nothing. It's a simplistic example, but there are categories of problems that low-code can solve which full-code can but won't.
- tootie 4y ago
  Low code is actually pretty dominant in the data integration space. Tools like Fivetran or Zapier that provide point-to-point integration of structured data from a source to a target with some rules for scheduling, filter and transform. If enough people need to move customer data from Salesforce into Snowflake it eventually just becomes a platform.
Narciss 4y ago
Back at the start of my career I didn’t know how to code, but I got offered a role at a startup after I came up with a solution of integrating google cals in a way that was crucial to the business - using Zapier. (The requirements were complex, but Zapier could handle it) This was after the outsourced dev team that built the company website said that it wasn’t possible without significant cost. Here comes me, not knowing how to code, pointing out a solution that cost a few pounds a month. During the next few years I built a ton of other solutions for the company using Zapier, to the point where we were running over 50000 tasks a month, easy. I learned how to code in the process (I now work as a software engineer), but I always consider low-code or no-code solutions when problems arise, because I’ve seen them save massive time and expense in a real world scenario, and working really well. It’s like the OP said in the end - we are problem solvers, and I would add that low-code/no-code tools should be part of your tool chest. Your decision as a problem solver regarding when and how to use them are crucial to whether they work or not - but I wouldn’t dismiss them outright.
- ElFitz 4y ago
  I often try to do the same thing. But usually end up regretting it. From these experiences, both the successful and the failed ones, come a few gripes against most low-code / no-code tools. To name a few: - Often poor, or completely absent, testability - Often poor, or completely absent, versioning - Conflating “saving” and “deploying to production” - Lack of environments - Often sorely lacking, sometimes poor, debugging tools and visibility - Ridiculous choices (looking at you, Zapier and your absurd handling of JSONs and arrays of objects) - Poor reusability - Poor collaborative features It is my understanding that for some products some improvements have been made on some the aspects I’ve mentioned. But it also feels as if those behind these tools have completely ignored the progress we’ve made in software engineering best practices over the past 20 years.
  - roflyear 4y ago
    Often just getting it kind of working is good enough. I don't like these solutions as they don't really give me full ownership of the problem space but I understand why people use them
raincole 4y ago
Anyone works in games/films will know how useful low-code tools are. And they're ubiquitous. I can list more than 10 of them out of my heart: - Unity and Unreal's material/shader graph. - Unity's VFX graph/Unreal's Niagara - Unreal's blueprint - Blender's composition node and shader node - The whole Houdini - Substance Designer - PureData - Bitwig's grid - Nuke - Fusion At this point I think it's a bit ridiculous that people still are arguing whether low code tools are helpful or not.
- acutesoftware 4y ago
  In terms of Unreal blueprints they may be low syntax but they are not low code - you still need to know software development techniques or you will end up in a pile of garbage very quickly (which you can also do with any other language).
  - capableweb 4y ago
    What is required when using Unreal Blueprints is game development domain knowledge, which makes sense for all those tools, doesn't make them less no-code. To use Houdini effectively, you need to know vfx and a bunch of other domains, just like you need to understand shaders if you're gonna use the shader nodes in Blender. All of those things can be achieved with coding as well, and that's the difference. One you write code, the other you don't. Both are backed by code, obviously, but it's hidden from the user but usually extensible by code.
- tjpnz 4y ago
  Can't speak for game development but in film (specifically VFX) the coding side can get rather involved. In a large studio your pipeline will hinge on dozens of in-house Python scripts or even tools in their own right. Often they'll have their own data access logic for working with databases, asset management tooling or production data APIs. That they're loaded as Maya/Houdini/Nuke plugins is incidental at that point. It's no coincidence that your most effective TDs will also be strong coders, and that some may even come from a more traditional software background.
hankchinaski 4y ago
There are countless valuable businesses built on no code. It’s good for prototyping and early stage
riogordo2go 4y ago
It depends on the capabilities of the low code tool and the problem domain. Just today I created a "flow" in the Android app Automate to add "auto-sleep after 30 minutes" functionality to YouTube every time I toggle pause/play after 11pm. Dead simple with a very easy to understand ui control flow. I could have written an Android app/service to tap into the various APIs and accomplish the same, but for this use case this low code solution was clearly superior. I could see a lot of software development being replaced with low code tools.
vaughan 4y ago
Custom software development could learn a lot from the "visual programming" part of low-code development. I find it odd that we design and understand our software as diagrams on whiteboards, and then we just maintain this big ball of text. Everyone thinks they are writing clean code, but most projects require huge amounts of time spent poking at it to figure out what the actual core business logic is. I think the future of programming is two-way sync between visual and code, where every piece of code is visualized in a graph. I want to open a project and see the function call graph, live annotated values from different code paths, and a data dependency graph of how every value in the system responds to events and user interactions.
- runlaszlorun 4y ago
  Agreed. If we take a step back from the day-to-day and our own well-worn opinions, the fact that we debate issues like whether a language uses curl braces or indentation or semi-colons or not is somewhat comical.
- peterosi 4y ago
  A few weeks ago I just started building a product that accounts for that new paradigm. So far its just a bunch of R&D, miro diagrams and blurry thoughts. But on a high level thats my goal: bring more visual to coding together with some of the best software engineering practices like interfaces, cqrs, event sourcing, microservices. I want to enable users to switch the level on which they are operating: no-code, low-code, pro-code, at any point in time. This will allow bringing together all of the stakeholders into the same tool. This should allow them to move quicker, reduce need for alignment and give everybody a way to particupate at the development stage. Would be great to get in contact with you and poke your brain a bit about this problem and see what you think about it!
  - vaughan 4y ago
    Sure - email in profile.
ChrisMarshallNY 4y ago
> I've been writing custom software for a long time and one of the things that annoys me most is when a client adopts the position that there is a silver bullet which will reduce or remove the inherent complexity of this task. This happens more often than you'd think and guess what? They are almost always wrong. I concur. It's not new, either. I have been writing software professionally, since 1984-5 (depending how you define "professionally"), and have heard this claptrap since Day One. I'm sure it was around before I was in a position to hear it (tree, forest, sound, etc.). AI will generate the same BS, until people figure out that those skilled in writing really good prompts, get much better results than your average C-Suite dork.
patatero 4y ago
> This low-code tool is called OutSystems and my review of it is that its a steaming pile of shit. I've used this app for a few months last year and the UI is simply awful.
odyssey7 4y ago
The opening sentence is a reference to the influential software engineering paper No Silver Bullet, and the overall post is aligned with it. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet
greggyb 4y ago
I've been on this kick for a while now and the pithy version I've come up with is this: The central conceit of low- and no-code tools is that the hard part of programming is typing code. I have never liked the term "coder", but it has taken a while for me to be able to articulate it. What it comes down to is this: all coding is programming, but not all programming is coding. Programming is, in very broad strokes, making the computer repeatably do something for you. Coding is typing code. Some examples: spreadsheets are programming. Yahoo Pipes back in the day, ITTT, Zapier, Microsoft Power Automate and all the rest are programming. Shell scripting is programming. Also, using any of the typical programming languages is programming. With this understanding, low- and no-code tools are obviously programming. They just involve writing less code (if they are doing their jobs correctly). This helps to understand them. If the solution domain's implementation is riddled with boilerplate, then this sort of tool can be a boon. There are plenty of instances where this is true. As the solution domain's non-boilerplate portion grows, the value of low- and no-code tools rapidly drops off. This is because -- pretty much universally in my experience -- these tools, ironically, make the act of writing code very nearly as hard as it can be. These tools, designed from the ground up with the goal of minimizing the (perceived) pain of writing code, make writing code so very difficult. So, as others have said, it is important to get tool-problem fit. And understand what it is you need to program. And if that programming challenge fits into the box that a low- or no-code tool constrains you to. Because it might not be coding, but it is definitely programming.
lordnacho 4y ago
The problem with Low Code is that it isn't No-Code. If I have some problem that I can just jam into IFTTT and leave it forever, I will do that and be very happy. If I then need to do something that requires changing the setup, I am coding. Suddenly I have to think about the requirements developing in the future, where to keep the repo, how to deploy it, how to change dependencies, having someone look after it. The lie in low-code is that the first thing is like the second thing. If you aren't a dev, I can sell you a thing pretending it's the first thing, and then you are stuck with all the issues when it morphs into the second. Excel is perhaps the best example of this. You think you don't need to understand coding, because how hard is it to wire up some cells? Time passes and you have a bunch of VBA scripts and DLLs hooked up to buttons on your spreadsheet, and it turns out things were a lot more complicated than you thought.
WillAdams 4y ago
I've been hoeing this row for a while now, and have a preference for these tools. My current favourite is BlockSCAD: https://www.blockscad3d.com/editor/ https://www.blockscad3d.com/editor/ which I've been using to explore 3D design and joinery: https://willadams.gitbook.io/design-into-3d/3d-project https://willadams.gitbook.io/design-into-3d/3d-project The problem always becomes one of extensibility --- if you use a lot of modules, while functionality goes up, the expressiveness/communicativeness of the code goes down because you're back at a wall of text --- it's just one in pretty blocks. What does an algorithm look like? The Drakon folks sidestep this by claiming that there should be one desired path and just connecting blocks in a straight line. I'm currently working in OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor https://github.com/derkork/openscad-graph-editor which exposes _all_ of the OpenSCAD language, and allows me to loop in RapCAD and am trying to balance visual display and complexity. I really wish there was a block programming or node graph interface for making a graphical application for Windows or Mac OS.
antipurist 4y ago
Sure thing, if you're building something complex, you have to deal with complexity, there is no way around it, low-code doesn't change it. But I've seen lots of non-coding professionals who spend hours every week just looking up some info on various websites just to copy some text/number/address from a well-structured page and paste it into a spreadsheet. Could this be automated? Absolutely! Do they want to learn how to write a program, handle errors, manage the deployment of their scripts? Absolutely not. Low Code has its place, and there are no conceptual downsides to starting with a low-code solution and then hiring software engineers to flesh it out and handle all the special cases. All we need is a low-code platform built around some real programming language that you can put into git, review, debug locally etc — with a no-coder-friendly interface built on top of it. This part is missing, and that's what causes people to dislike the low-coding in general.
prng2021 4y ago
This is a really poor generalization. Does anyone really think every company is a snowflake with a truly unique set of business processes? Of course not. Anyone who has worked at more than 1 company in their career can see lots of similarities for themselves starting from the onboarding process. Dig into that and you’ll find some low hanging fruit for automation with no code/low code platforms. If you’ve completed the discovery and requirements gathering phase and try to implement a complex application with a no code/low code platform, you’re probably early in your career or this is the first time actually using no code/low code platforms for something besides a pet project. So you made a mistake and should just be more cautious in the future, not write off these platforms entirely.
robjan 4y ago
I once worked at a company with very complex business processes but no ERP to solve them. Everything was Excel documents in shared drives and emails. We provisioned a low code "quick wins" team to start automating these manual processes while we were implementing the ERP. There's a space for both low code and high code solutions.
ascotan 4y ago
This is what I call "Bayesian software" - it will get you quickly to 70% of what you want but getting 100% of what you want is a game of diminishing returns. For some companies 70% solutions are ok and it's a tradeoff in terms of functionality vs cost which everyone has to make. The reality is that a lot of software engineering is moving into the 'low code' space even if they don't call it that. This is part of a general strategy to sell B2B services (like cloud platforms or cloud tools) where engineers aren't really developing solutions from scratch as much as they are configuring tools provided to them via a B2B sale. Is this software engineering? I guess it's debatable but it's clearly not 'applied science'. I see this as a general trend in any craft - craftsmen get displaced by cheap industrial alternatives (like plastic chairs vs actual decent chairs made by a craftsmen). There is no argument that a handmade wood chair made by a craftsman is better, but for many consumers at the bargain store, they want cheap plastic foam-injected chairs even if they are poorly made and break. Does the argument hold that these cheap alternatives are "more expensive" in the long run? maybe. It depends on what you're doing with the chairs. I think one serious downside to 'low code' solutions is the brain-drain on new devs. I see so many engineers that don't understand basic software architecture because they've spend their career configuring B2B tools. Overtime this model of software will cause us to loose core CS skills.
- datastoat 4y ago
  I’m curious! Why “Bayesian”?
roflyear 4y ago
Just have every function be a logic app that no one understands and costs $25 a month to run. What could go wrong?
thadt 4y ago
Yeah? I'm working with a class using a lot of visual/block coding in Microsoft MakeCode. But then, I've also spent time writing code at various places in the (abstract) chain: hardware <- uCode <- asm <- C/C++ <- TypeScript <- MakeCode/Scracth In terms of size, C is lower code than asm. TypeScript probably less, depending on what's being done. MakeCode uses blocks instead of text, but the logic concepts are the same. At each step up that stack it gets easier to do some things and harder to do others. Where along that stack does it become 'low code'?
sullivanmatt 4y ago
My day job is security engineering, and I just keep encountering the same problem over and over again: the code is the easy part, it's all the other shit that sucks. I don't want to write a bunch of terraform, set up a CI pipeline, and have to justify why I haven't updated a docker container's dependencies in like 6 months. I just want to write a little Python and make it available on the internet somewhere. Why is that hard? I'm working on a side project to basically make the tool I wish existed: https://integralcloud.io https://integralcloud.io If you have a use case that you are willing to talk to me about, please reach out (contact info on my profile). I won't try to sell you anything, ever. I just want to hear about business use cases and try and make something people want to use.
- yibers 4y ago
  Can't you jusy use a servetless function such as Aws Lambda for this?
0x445442 4y ago
Ah, management’s never ending dream to commoditize software development; gotta love it. I’ve spent the last several years being paid good money working on various failed “digital transformation”projects and am currently working on another one I predict will fail. One of the root causes of these failures is viewing the actual software development as a mere afterthought once all the high level boxes are drawn and power point slides created. Tremendous resources are spent on everything ancillary to the software and insuring proper adherence to process is kept no matter how orthogonal that process may be to maximizing the delivery of quality software in a timely manner. It’s really quite amazing.
- JackMorgan 4y ago
  I make a great living cleaning up the unholy messes made by low code projects! I'm doing one right now that took me a month to convert a project that had been grinding to a halt for several years on one of these low code platforms. My customers are thrilled I can knock out a couple "impossible features" in a day because the data is now stored in SQL and not some UI driven monster web based "database" with no formal query language. Another commentator likens these tools to mass produced plastic chairs, but for me, it's more like a plastic car engine that just melts if you go more than 15mph or you try to carry more than one passenger. And these engines are being sold to trucking companies, taxi companies, and food delivery companies. Sure those plastic engines are really cheap. But good luck when you suddenly are carrying more than a few sandwiches a few blocks away.
ncphil 4y ago
No kidding.
roncesvalles 4y ago
Having worked professionally with low-code tools, low-code is just coding but with less expressivity and worse ergonomics. In layperson terms, you're still implementing the same logic - just that now you have less flexibility and precision to implement exactly what you want (expressivity), and the UI/UX is "clunkier" than if you just wrote some code in an IDE or text editor. There are also a few other problems that are prevalent in the low-code ecosystem but not fundamental to it: - not having good version control - not being able to port what you built (vendor lock-in) - not having a good way to collaborate These are very powerful things that we take for granted when writing code in a version-controlled repo.
hermitcrab 4y ago
As a developer writing a low-code data transformation tool, I have some skin in the game here. I believe that low-code tools are only good for creating a small subset of software systems. This is because software systems are incredibly varied and they often don't fit into the restrictive framework set by low-code development tools. On the other I believe hand low-code tools can be very useful for more restricted domains, such as data transformation, 3d animation or audio design (although they aren't always a better alternative to code based tools).
siliconc0w 4y ago
The problem with no-code or even LLM-driven app development (so far) is that the tool, or the language, isn't precise enough to tell it exactly how to behave so you can only really implement stuff that is extremely basic and pre-canned. Even then, just building a thing isn't really the goal. You want something sustainable. Sustainable means the ability to build and reuse internal and external libraries, security best practices, version control, unit and integration testing w/ continuous deployment, monitoring, etc. You need to be able to reliably change/extend it over time as business requirements change. You could build a 'low-code' solution that tries to address all of these but it just starts to become another programming language. And because it was never designed with that intention, it's usually a pretty poor programming language.
usrbinbash 4y ago
There are exactly 2 types of lowcode environments: One is so complex, and allows the user so much freedom, that it is a fully fledged programming language. The fact that it requires me to shove little boxes around in an interface may make it better for some domain specific task, idk. What it certainly does, it makes it next to impossible to integrate in any standard IDE, usually doesn't play nice (if at all) with version control, and searching through code becomes a game of "Where's Walter?". The other is so simple and obviously shoehorned to perform a narrow set of tasks, that it is almost, or completely, impossible to do anything else with it. Which is perfectly fine right up to the moment where the user needs to do something the framework didn't foresee, and suddenly engineers are asked "can we integrate that? we only need one small thing...". Which the framework, being ~narrow and prohibitive~, excuse me, focused and streamlined, usually fights tooth and claw, but engineers somehow get it to work anyway. Until the "one small thing" becomes many small things. And some slightly larger things. And the occasional big thing. And then those same engineers need to rewrite the whole thing, which would be fine, had it not been first "implemented" in the glorious "lowcode/nocode" environment, which suffers all the problems outlined in the first type, so we spend countless hours unpicking a pile of spaghetti made from colored boxes and lines, and the complexity the framework shoved under the rug, to figure out what that thing was supposed to do in the first place. This is the reality of low/nocode environments. And it baffles me to this day, that this idea, which isn't new btw. (it existed under different names since at least the mid 80s), keeps popping up and dominating headlines every few years.
- ethbr0 4y ago
  That's one reason I refuse to consider low-code environments that don't have a well-modularized and standard-following escape hatch to an actual program language. As soon as you start writing custom modules, it should always be in a general-purpose programming language.
werber 4y ago
I started using chatgpt last week for coding problems, and while it's not perfect, with very specific questions and code examples fed in, the results coming out saved me a lot of time, even if i'm rephrasing a question 5 times
mbbui 4y ago
With the dawn of LLM, I think low-code will be mainstream again. Of course it all depends on the applications. For applications where scripting is all you need, you can pretty reliably generate code with prompts.
majkinetor 4y ago
Amazing article that correctly frames the most troubling aspect of complex software. No code tool is just irrelevant detail. Good job Jay little!
GalahiSimtam 4y ago
Every low code sounds like a plan, until you have to make something like "computer AI for Heroes Of Might & Magic 3 battles".
ab_testing 4y ago
I don't know why people like to blast low code developement on HN in general. The US and worldwide software development market is big enough to support both full software engineers and low code developers. Each has its own place in the enterprise. As somebody who has worked a lot in the low code development area for almost a decade, these tools give a lot of capabilities to non-engineers. I usually see low code software development being used in the government sector where it is used by epidimiologists to track disease spread during covid, policy analysts and even environmental engineers to track pollution and build dashboards based on that data. If not for these low code tools, that money would have been spent by the goverment on expensive consulting engagements to IBM, Deloitte and other government software vendors who charge $400/hr just to gather business requirements.
gloosx 4y ago
Very nice article, as an experienced software developer I feel this to the bone. I also feel the same applies to all-in-one cloud platforms aka fire/supa/megabase, which are promoted to an extreme these days. It enables fast-forwarding system design decisions and getting something running quickly. It lowers the barrier substantially, but configuring and using it in the right way – from the good data model to safe and secure so-called cloud functions – takes the same skill and time as setting up your own custom solution for your problem using a handful of open-source Docker containers, the compose file and a VPS. Of course, it requires you to be more mindful and aware of what you're building, as well as to subscribe to the requirements of your problem more deeply.
cudgy 4y ago
“It therefore falls upon our shoulders to validate the approach suggested by the client before we possibly waste both their time and money developing it.” I agree with this statement, but who pays for this analysis of the customer’s analysis? Customers expect to pay a developer for their time actually writing the code for the solution. Within most companies, developers are expected to build according to the specs from the domain experts and not argue about the specs or rehash the approach requested.
motbus3 4y ago
For me, people get mislead that 80% of the work only leaves 20% to go. You can use any platform, language, tools, paradigm and it will not be enough because software development/engineering is solving problems

282 points by jandeboevrie 4y ago

I'm of the believe that low code is for small and low complexity software. Often I find myself wanting to do something that is relatively simple but it needs to be done many times. I often have to weigh the complexity of writing a script vs doing it by hand. Let's say it takes 2 hours to write code vs 1.5 hours to do it by hand in some situation. Low code could make my decision much easier if, as it promises,writing the code took less effort. But I don't think anyone would pick it to write complicated and long code. I think it has its place as a code writing tool. The big issue to me, and the article's author, is that you are locked into whatever tool you use. That and the never ending subscription makes it a very unattractive choice for any project no matter how simple it is.

kfk 4y ago

I have an Enterprise story on this. The low code tool I was using increased the price x10 on me after the first 3 years. The price increase was poorly managed, they looped me out and tried to talk directly to the IT leadership which was a disaster for them because they had 0 experience handling Enterprise contracts. I don’t think these low code tools are worth the trouble of dealing with their inexperienced sales people. Maybe some low code tool companies are better, but I am done with them anyways. Most of these tools promote bad coding practices like no clear split of dev and prod, no version control, no testing. I am not sure if these low code companies know what they are doing and how complex it is to maintain an enterprise app over 5/10/15 years.

ethbr0 4y ago
Name and shame!
- cowanon222 4y ago
  Not the poster, but Microsoft Powerapps had a massive price jump a few years ago, followed by a pretty large decrease last year. Through the grapevine I have heard the same about Mendix and Outsystems - in my company we found that hiring internal developers is cheaper than paying the licenses at scale. (About a 10k employee company) It may work for smaller depts and apps, but Retool or Airtable is often sufficient for these teams, and much easier for non-developers to learn. We do use Appian and Pegasus for some smaller depts.
  - ethbr0 4y ago
    Microsoft product positioning on Power* seems extremely weird from the outside, which I chalk up to internal division politics. It's like they can't decide if they want to give it away to grab market share or make money off it. And pricing updates reflect whichever group wins the last debate.

zabzonk 4y ago

> It is actually the result of clients and developers not taking the time to understand the root causes of the problems they want to solve i certainly agree with this. it seems weird to me that the job title "systems analyst" has disappeared frpm the job market (speaking as someone that used to be a "programmer/analyst") and has been replaced with ... nothing?

didgeoridoo 4y ago
TPM (technical product manager) maybe?
Closi 4y ago
I agree with that statement, but disagree with the conclusion ('because of that no-code solutions are not useful'). The benefit of low-code is that you can spend more time understanding the root causes of the problems, and be able to quickly prototype solutions that match the user requirement (and that you can make changes to more quickly) than would otherwise be possible. Of course if everyone had infinite time, we would build full solutions for everything, but in a world with limited time and resources these tools can have a great place in the toolbox.

ramraj07 4y ago

Tell that to all the labs running on labView

avsteele 4y ago
I have pretty extensive experience in this domain. Personally, I found there is a application complexity ceiling above which LabView was not viable. It is pretty great for rapid data collection and analysis, and it is well integrated with a variety of hardware. But once there is a few things going on at once the "backplane" abstraction becomes unhelpful. So many vendors provide python libs these days, and python plotting is good enough in these that it is harder to justify LV.
peteradio 4y ago
Labview is awful, I joined a lab that had attempted to build instrumentation controls in labview. Replaced with pyvisa and was able to write much more complex controls and automation without crying.
IshKebab 4y ago
I suspect they would agree! LabVIEW is code, just in a truly awful format. Simulink is perhaps a better example because it is at least relatively good, unlike LabVIEW, which is the worst thing ever. (And if you're wondering why people use it, it's because NI makes a ton of very good (and very expensive) lab equipment and the software they provide to drive it is all LabVIEW based.)

_xivi 4y ago

Low code is useful for prototyping and validating ideas. I wouldn't count on it for anything long-term

toyg 4y ago
As anybody who went through the 80s/90s knows, the prototype almost invariably becomes the production artefact. "Why should you rewrite what already works?!?" Actual building engineers don't have this problem, since the prototype is so obviously not the real thing. Software engineers have to make an actual effort to keep "civilians" from mistaking a prototype for the real thing.

RyanHamilton 4y ago

To hell! I'll throw myself to the lions. I make "Low Code" software and I think it's useful. It allows anyone who knows SQL to build real-time interactive HTML tools: https://www.timestored.com/pulse/tutorial/pulse-interactive-table https://www.timestored.com/pulse/tutorial/pulse-interactive-... These people often only know SQL, so can't write javascript/html/react. The example video shows allowing them to create a live updating table that when clicked, draws a chart for that row. The best use-case is for prototyping many more apps than would be possible if they had to run every idea past a UI developer. Eventually some of those ideas get taken to full production based applications, many don't. I'm open to any and all feedback. If you think it's useless please say why and if you think there are better tools, well I would appreciate that feedback too.

k__ 4y ago
To me all software that requires minimal coding skills to use is low-code software. It's basically the job of a developer to move concepts that require coding through abstractions over to low code and then no code solutions. "Low code" or "no code" is just giving it another name, like when people started calling other people's servers "the cloud".
galaxyLogic 4y ago
Note that SQL is not no-code. You could say it is low code, but still it takes a "coder" to develop and debug it. It is a text-based format not GUI-based.
- rwalle 4y ago
  RyanHamilton did say it's "low code".
bob1029 4y ago
Fellow lion pit enjoyer here. We also use SQL for our product to deal with all the client customization needs. This has been our path for about 4 years now and we still haven't found a better option for our business. If you build a SQL schema and involve the business stakeholders in that process, you end up with something everyone can understand & work with. The difficulty of writing SQL scales in direct proportion with the complexity of the schema/domain. If the schema is something that is fundamentally familiar to your team, then you already have 80% of the "language" trained into your employees. At this point, showing them a few examples is all they usually need to "get it" and start doing things on their own. Inevitably, you will run into "how do I write a query that answers 13 questions at the same time and arrive at 1 final binary choice", and need to babysit with decomposition & CTEs. But even with some examples of those the team can begin to take matters into their own hands. In my experience, the joins are the hardest part. If you can, organize your problem such that even very inefficient nested queries can complete in a few milliseconds. We do things like run SQLite in-memory to achieve this outcome. Allow the team to do lazy crap and get shit done. You can always iterate the queries for quality later on - I think an LLM does this for us in our near future.

BulgarianIdiot 4y ago

"A programmer whose salary depends on being an unsurmountable middle man between boss and machine, declares that solutions for surmounting him are a lie." - The Onion, probably

shanebellone 4y ago
I've upvoted this because it's funny and mostly true. However, the outputs from no-code and hand rolled are not equal. It blurs the distinction between custom and off-the-shelf. With no-code representing something closer to the latter.
- oriolid 4y ago
  There's a lot of money to be made in first trying to customize an off the shelf solution, then trying to replace it with low code one and finally implementing a custom one.
  - shanebellone 4y ago
    Sure. Yet any no-code derivative is therefore stuck with a general-purpose implementation. Which admittedly is fine in many contexts. However, the distinction is important. You "assemble" no-code. You cannot buy a dog puzzle and reconfigure it to be a cat puzzle. IMO, this is the inherent limitation of a no-code toolset. Also, users are handicapped by the developer's capability. That is to say, the efficiency and specificity of the tool's internal codebase represents an invisible glass ceiling for its users.
djaouen 4y ago
You do realize that low code solutions are actually the middle man between boss and machine here, don’t you? This is like comparing Node and Drupal and announcing that Drupal is the superior technology. Ick.
- Avshalom 4y ago
  So's a compiler, and an operating system, and microcode.

docflabby 4y ago

Find me a non code product that can do something excel can't

shanebellone 4y ago
A 1-page website.
- yebyen 4y ago
  It is incredible in some teams how difficult it can seem to be to get from "we need a 1-page website" to "ok, it's online and you can update it simply without any more of my help. Here" And with the difficulty going up, the likelihood that you'll do this when it's needed and makes sense to do goes down. I can't tell you how many times I said "I need a website" and didn't end up posting one, because we didn't have a ready answer to this question, and nobody could be bothered to go out and build one. Just a simple one page website. I can think of at least three "easy" ways to do it (and that's my whole problem in a nutshell, thanks for coming to my TED talk.)
  - shanebellone 4y ago
    I think the problem is this... Those who need a simple solution require considerably more tools than a 1-page website should require. The user specification requires those tools to interact with the website, without technical help, in perpetuity. That's a MONSTER requirement.
- is_true 4y ago
  File > Save as > index.html
  - shanebellone 4y ago
    This made me laugh. You get an upvote. :D
  - deleted 4y ago
    [deleted]

alkonaut 4y ago

“Low code” is such a blurry definition. Is excel low code? Is a shader graph in a game engine low code or no code? Regardless of which, they’re useful.

ryaniscool 4y ago

What I’ve found is people who use low code tools are more willing to lower their expectations to the capabilities of the tool. This is in comparison to your typical customer of bespoke software development who has a long laundry list of requirements that they’ve imagined up based on their perfect vision. If “good enough” was good enough for these people they would be using low code tools

papito 4y ago
To make it worse, the customer's "vision" is almost always wrong. It takes great skill to extract from them what they really want - otherwise you allow the customer to be a tech product manager, which is a no-no.

deleted 4y ago

[deleted]

galaxyLogic 4y ago

Low-code tools make you really lock-in with the provider of such a tool .

krishvs 4y ago

I'm quite bullish about low-code tools now. Especially for building back office systems like ERPs or operational tools. From my experience most failures in such project implementations have been due to mismanagement in the requirement gathering phase and also development happening in silos where the team building has no real understanding of the business process workflows. But with gpt-3.5 - these tools can really inlock the ability of non technical people to build products. Maybe outsystems should have a gpt chat interface that builds software on its platform directly from the requirements of the end user instead of any intermediate human development team.

Closi 4y ago

> Designing a solution worth a damn is actually the most difficult part of the software development process. Low Code tools lie to customers by implying that the writing of code is the hardest part. I don't think there is a lie here. Writing 'production-grade' deployed code is the hardest part for people who can't code, but that do understand processes and how to design them. There are plenty of people I have come across who cannot write code, but who are still intelligent and could design a robust process. This is the benefit of low-code and AI tools: liberate the ability to develop software tools to people who are capable but don't want to spend years learning to program.

rwalle 4y ago

Nonprogrammers used to use FrontPage or Dreamweaver to develop websites. Now they use things like Google Sites or Wix for that matter, which works well enough for a lot of individuals and businesses. This is a real thing that has been happening for decades and is not a lie. This article is a lie.

TheLoafOfBread 4y ago

Low code is still a code. It is just matter of time before some office worker will create large and humungous low code project which then will be used by half of the office. Because worker never coded before, whole project will slowly (or quickly) become unmaintainable mess where one change will brake 3 features. Then they will call a developer to sort this mess out and it needs to be done yesterday.

jrochkind1 4y ago
People who have spent years coding are also perfectly capable of creating unmaintainable messes where one change will break 3 features, thank you very much.
- TheLoafOfBread 4y ago
  When you will be now "maintaining" 1000+ row VBA macro script in Excel linking dozens of files to generate a report and office folks will ask you to fix it because it does not work properly and author was laid off month ago, you will have different opinion.
  - jrochkind1 4y ago
    Perhaps same opinion as if you're maintaining a, I dunno, 50K+ line software package as a development-team of one, which was developed by a single developer (who learned to code on the job) over a 10-year period and he left a few months ago. (Yes, this happens). Many "low-code" solutions definitely give you enough rope to hang yourself. In this regard, ironically, they are more similar to than different from other kinds of coding. I'm not even sure Excel should count as "low-code". A multi-thousand line VBA macro script doesn't sound "low code" at all, right?
    - TheLoafOfBread 4y ago
      As I wrote in first post, low code is still a code. And there will be some office worker who will have enough time to pile up a massive project which is not documented, nobody knows how it works, the worker is gone, but half of office is dependent on it.

gregjotau 4y ago

You can often mix low-code into a solution that requires some code, I did that recently creating a custom review app for a Shopify store: https://respiroc.com/blogs/software/how-to-make-your-own-custom-review-app-in-shopify-using-airtable https://respiroc.com/blogs/software/how-to-make-your-own-cus... Basically: 1. Airtable (low-code) to be a database + submitting new data 2. python code to sync to shopify 3. frontend liquid code to display reviews. I have built a lot of low-code with Airtable for a 5-6 million dollar business (revenue per year). Product development system, warehouse management++. And just to be clear: The good no-code systems are still built by coders.

rwalle 4y ago

> Low Code tools lie to customers by implying that the writing of code is the hardest part. Not true. Low code tools often excel at fast prototyping at decent quality -- if you feel comfortable enough you can ship them as is and you have a functional product. That might be all what customers want or care about. They don't produce the best code, but nobody really cares in the real world.

cushychicken 4y ago

A few effective counter examples I can think of, off the top of my head: - the Apple Shortcuts scripting framework built into iOS 16 and above, - gnuradio - a block based signal processing environment for software defined radio - Scratch - the learn-to-code block language that’s evolved into its own programming environment I suppose you could call these programs’ no-code premise “a lie” based on the premise that all of them have text based code under the hood. But I also realize you can rebut that pretty easily by saying that the graphical flows can address a lot of custom functionality required by their user bases. Speaks to me of those programs solving problems with a relatively well defined set of constraints. I wouldn’t describe current web apps, and the rich frontend functionality required, as meeting the criterion of having a “well defined set of constraints”.

flir 4y ago
I think you can add IFTTT to your list (https://ifttt.com/ https://ifttt.com/). Maybe Yahoo Pipes too.
- cushychicken 4y ago
  Never used either of them myself, but a cursory inspection suggests they fit the paradigm I’m talking about.
wizzwizz4 4y ago
Apple Shortcuts is just rubbish shell scripts with an excellent GUI. Scratch is certainly a programming language: it even has a textual representation. https://en.scratch-wiki.info/wiki/Block_Plugin/Syntax https://en.scratch-wiki.info/wiki/Block_Plugin/Syntax. I haven't used GNU Radio. Some of these "no-code" systems aren't programming languages, but the examples you've given are definitely programming languages. They've even got their own Wikipedia article (https://en.wikipedia.org/wiki/Visual_programming_language https://en.wikipedia.org/wiki/Visual_programming_language) which lists GNU Radio (though it also says behaviour trees are programming languages, so I'd take it with a pinch of salt).
- 4y ago

JimDabell 4y ago

The heart of this complaint is essentially that some people think that the difficulty in implementing something is because it requires code, and they can’t write code. “If only I could code, this would be easy”, they think. Code, as they view it, is incidental complexity, not essential complexity. For a lot of tasks, this is actually true. Take away the requirement to write code by supplying them with a low code tool, and suddenly people can do lots of useful things that they couldn’t before. So in that respect, it’s no lie. But of course, there are a tonne of other situations, where code is not the only complexity present. Sometimes you’re just trying to solve a big, complex problem. Take away the coding requirement, and you’re still left with a tonne of complexity to manage. And low-code tools aren’t the best for handling that. In those cases, you’re better off hiring developers. I’ve seen a few people build very complex things using low code tools. Modern ones, but also going all the way back to the original low code tool itself, spreadsheets. People really can build huge things with them. But after a certain degree of size and complexity, it’s more trouble than it’s worth to go with low code tools. But that doesn’t mean low code tools are useless – they are great for the first set of problems, where the code required is just incidental complexity. You shouldn’t write off this substantially useful product category just because people get into trouble using them for problems they aren’t suitable for.

Closi 4y ago
Totally agree - right tool right job. Sometimes writing a full web application is the right solution, other times you just need a database with a front end and a low-code solution is best, other times an excel spreadsheet will be the right solution, and other times just physical process change is best. Why take something out of your toolbox?
- pydry 4y ago
  >other times you just need a database with a front end and a low-code solution is best Until you need it to do something slightly beyond its capabilities and then you are trapped with an app that needs to be rewritten with data that needs to be migrated in order to implement one small feature.

propter_hoc 4y ago

Programming tools have a continuum between power and simplicity (or, lines of code, or developer efficiency). You wouldn't (couldn't) write a device driver in Python, but you also wouldn't want to develop a dynamic website in assembler. Low-code tools are a level beyond high-level languages. They are particularly useful where they are domain-specific, and offer focused functionality that makes them more effective for certain applications. Additionally, commercial low-code software can offer batteries-included solutions that you would have to pay for anyway. As an example, my company's product is a low-code platform for pdf workflows in finance. The language allows for rapid implementation of form workflows, including validation, pdf manipulation and e-signatures. It also includes features like sso, api integrations into obscure financial databases, whitelabeling and various tailored user and admin interfaces. Could you build arbitrary form workflows with a web service like RoR? Sure, but it would be a much more complex and expensive project, and you'd have to pay for a docusign API license anyway. I checked out Outsystems that the OP mentioned, and it seems like one of these more generic all-purpose services. I don't really think you can square low-code with all-purpose. The lift in efficiency you would get is stunted by the requirement to maintain the power to handle too many use cases. If you need to support every single industry under the sun, you can't focus on really good deep native API integrations, or you'd have to charge so much money you lose your value proposition.

deleted 4y ago
[deleted]
lifeisstillgood 4y ago
Interesting - in my head then for each industry there is a space for reusable code components that tackle certain industry needs - either OSS or prop - and that are so standardised that it takes one dev one day to put them into useful action. I think what I am saying is that good low code solutions are pre-packaged fixes to well defined common problems - and it's not that important if they are glued together with Rust or a drag and drop UI
- deleted 4y ago
  [deleted]

ethbr0 4y ago

Low code software development is not a lie -- it's a trade-off. You gain (a) canned components / patterns for rapidly performing common tasks, (b) opinionated design that encourages one particular solution, (c) support for any issues from the underlying stack. You lose (x) open development ecosystems, (y) general purpose flexibility, (z) ability to evolve a tool however you want and fix your own issues. Given the above, when does low-code make sense? When you have a common business use case, that happens frequently, and you'd prefer not to train/retain developers to deal with it. Generally, the dominating value of low code is directly proportional to how much of your use case the canned functionality solves. Some examples of where it's a good fit: application-application automation (provides interface glue and exposes higher-level actions), CRUD app generation (uses common design patterns to build everything the user doesn't need to change), data flow (allows the user to declare what should happen, then generates the how). If you find yourself hacking functionality into a low-code tool often or substantially, it's inappropriate for your task. If you're trying to use low-code to deliver a core business competency, it's inappropriate for your business. Use it for the boring and less important stuff, that's not worth developer time. In the same way that businesses rent instead of buy carpet (because it's not a core competency), most businesses shouldn't have full in-house development teams to do ancillary development tasks. Source: worked in UI automation for a decade+ and watched customers and the industry

Closi 4y ago
Agree entirely. As an additional point - If I have an entry-level clerk who does 2 hours of work per day that could be automated by putting a dev to work on building a solution for a month or two, it won't financially stack up. I also don't really want to pull that dev off to work on that, because I could probably have them working on better stuff. If we could build something a bit more scrappy in a low code tool in a few days and pay $40-$80 a month in licencing, that will stack up fast. Will it be as good as the full-code solution? Probably not - but we weren't ever going to build that solution anyway and it's better than nothing. It's a simplistic example, but there are categories of problems that low-code can solve which full-code can but won't.
tootie 4y ago
Low code is actually pretty dominant in the data integration space. Tools like Fivetran or Zapier that provide point-to-point integration of structured data from a source to a target with some rules for scheduling, filter and transform. If enough people need to move customer data from Salesforce into Snowflake it eventually just becomes a platform.

Narciss 4y ago

Back at the start of my career I didn’t know how to code, but I got offered a role at a startup after I came up with a solution of integrating google cals in a way that was crucial to the business - using Zapier. (The requirements were complex, but Zapier could handle it) This was after the outsourced dev team that built the company website said that it wasn’t possible without significant cost. Here comes me, not knowing how to code, pointing out a solution that cost a few pounds a month. During the next few years I built a ton of other solutions for the company using Zapier, to the point where we were running over 50000 tasks a month, easy. I learned how to code in the process (I now work as a software engineer), but I always consider low-code or no-code solutions when problems arise, because I’ve seen them save massive time and expense in a real world scenario, and working really well. It’s like the OP said in the end - we are problem solvers, and I would add that low-code/no-code tools should be part of your tool chest. Your decision as a problem solver regarding when and how to use them are crucial to whether they work or not - but I wouldn’t dismiss them outright.

ElFitz 4y ago
I often try to do the same thing. But usually end up regretting it. From these experiences, both the successful and the failed ones, come a few gripes against most low-code / no-code tools. To name a few: - Often poor, or completely absent, testability - Often poor, or completely absent, versioning - Conflating “saving” and “deploying to production” - Lack of environments - Often sorely lacking, sometimes poor, debugging tools and visibility - Ridiculous choices (looking at you, Zapier and your absurd handling of JSONs and arrays of objects) - Poor reusability - Poor collaborative features It is my understanding that for some products some improvements have been made on some the aspects I’ve mentioned. But it also feels as if those behind these tools have completely ignored the progress we’ve made in software engineering best practices over the past 20 years.
- roflyear 4y ago
  Often just getting it kind of working is good enough. I don't like these solutions as they don't really give me full ownership of the problem space but I understand why people use them

raincole 4y ago

Anyone works in games/films will know how useful low-code tools are. And they're ubiquitous. I can list more than 10 of them out of my heart: - Unity and Unreal's material/shader graph. - Unity's VFX graph/Unreal's Niagara - Unreal's blueprint - Blender's composition node and shader node - The whole Houdini - Substance Designer - PureData - Bitwig's grid - Nuke - Fusion At this point I think it's a bit ridiculous that people still are arguing whether low code tools are helpful or not.

acutesoftware 4y ago
In terms of Unreal blueprints they may be low syntax but they are not low code - you still need to know software development techniques or you will end up in a pile of garbage very quickly (which you can also do with any other language).
- capableweb 4y ago
  What is required when using Unreal Blueprints is game development domain knowledge, which makes sense for all those tools, doesn't make them less no-code. To use Houdini effectively, you need to know vfx and a bunch of other domains, just like you need to understand shaders if you're gonna use the shader nodes in Blender. All of those things can be achieved with coding as well, and that's the difference. One you write code, the other you don't. Both are backed by code, obviously, but it's hidden from the user but usually extensible by code.
tjpnz 4y ago
Can't speak for game development but in film (specifically VFX) the coding side can get rather involved. In a large studio your pipeline will hinge on dozens of in-house Python scripts or even tools in their own right. Often they'll have their own data access logic for working with databases, asset management tooling or production data APIs. That they're loaded as Maya/Houdini/Nuke plugins is incidental at that point. It's no coincidence that your most effective TDs will also be strong coders, and that some may even come from a more traditional software background.

hankchinaski 4y ago

There are countless valuable businesses built on no code. It’s good for prototyping and early stage

riogordo2go 4y ago

It depends on the capabilities of the low code tool and the problem domain. Just today I created a "flow" in the Android app Automate to add "auto-sleep after 30 minutes" functionality to YouTube every time I toggle pause/play after 11pm. Dead simple with a very easy to understand ui control flow. I could have written an Android app/service to tap into the various APIs and accomplish the same, but for this use case this low code solution was clearly superior. I could see a lot of software development being replaced with low code tools.

vaughan 4y ago

Custom software development could learn a lot from the "visual programming" part of low-code development. I find it odd that we design and understand our software as diagrams on whiteboards, and then we just maintain this big ball of text. Everyone thinks they are writing clean code, but most projects require huge amounts of time spent poking at it to figure out what the actual core business logic is. I think the future of programming is two-way sync between visual and code, where every piece of code is visualized in a graph. I want to open a project and see the function call graph, live annotated values from different code paths, and a data dependency graph of how every value in the system responds to events and user interactions.

runlaszlorun 4y ago
Agreed. If we take a step back from the day-to-day and our own well-worn opinions, the fact that we debate issues like whether a language uses curl braces or indentation or semi-colons or not is somewhat comical.
peterosi 4y ago
A few weeks ago I just started building a product that accounts for that new paradigm. So far its just a bunch of R&D, miro diagrams and blurry thoughts. But on a high level thats my goal: bring more visual to coding together with some of the best software engineering practices like interfaces, cqrs, event sourcing, microservices. I want to enable users to switch the level on which they are operating: no-code, low-code, pro-code, at any point in time. This will allow bringing together all of the stakeholders into the same tool. This should allow them to move quicker, reduce need for alignment and give everybody a way to particupate at the development stage. Would be great to get in contact with you and poke your brain a bit about this problem and see what you think about it!
- vaughan 4y ago
  Sure - email in profile.

ChrisMarshallNY 4y ago

> I've been writing custom software for a long time and one of the things that annoys me most is when a client adopts the position that there is a silver bullet which will reduce or remove the inherent complexity of this task. This happens more often than you'd think and guess what? They are almost always wrong. I concur. It's not new, either. I have been writing software professionally, since 1984-5 (depending how you define "professionally"), and have heard this claptrap since Day One. I'm sure it was around before I was in a position to hear it (tree, forest, sound, etc.). AI will generate the same BS, until people figure out that those skilled in writing really good prompts, get much better results than your average C-Suite dork.

patatero 4y ago

> This low-code tool is called OutSystems and my review of it is that its a steaming pile of shit. I've used this app for a few months last year and the UI is simply awful.

odyssey7 4y ago

The opening sentence is a reference to the influential software engineering paper No Silver Bullet, and the overall post is aligned with it. https://en.wikipedia.org/wiki/No_Silver_Bullet https://en.wikipedia.org/wiki/No_Silver_Bullet

greggyb 4y ago

I've been on this kick for a while now and the pithy version I've come up with is this: The central conceit of low- and no-code tools is that the hard part of programming is typing code. I have never liked the term "coder", but it has taken a while for me to be able to articulate it. What it comes down to is this: all coding is programming, but not all programming is coding. Programming is, in very broad strokes, making the computer repeatably do something for you. Coding is typing code. Some examples: spreadsheets are programming. Yahoo Pipes back in the day, ITTT, Zapier, Microsoft Power Automate and all the rest are programming. Shell scripting is programming. Also, using any of the typical programming languages is programming. With this understanding, low- and no-code tools are obviously programming. They just involve writing less code (if they are doing their jobs correctly). This helps to understand them. If the solution domain's implementation is riddled with boilerplate, then this sort of tool can be a boon. There are plenty of instances where this is true. As the solution domain's non-boilerplate portion grows, the value of low- and no-code tools rapidly drops off. This is because -- pretty much universally in my experience -- these tools, ironically, make the act of writing code very nearly as hard as it can be. These tools, designed from the ground up with the goal of minimizing the (perceived) pain of writing code, make writing code so very difficult. So, as others have said, it is important to get tool-problem fit. And understand what it is you need to program. And if that programming challenge fits into the box that a low- or no-code tool constrains you to. Because it might not be coding, but it is definitely programming.

lordnacho 4y ago

The problem with Low Code is that it isn't No-Code. If I have some problem that I can just jam into IFTTT and leave it forever, I will do that and be very happy. If I then need to do something that requires changing the setup, I am coding. Suddenly I have to think about the requirements developing in the future, where to keep the repo, how to deploy it, how to change dependencies, having someone look after it. The lie in low-code is that the first thing is like the second thing. If you aren't a dev, I can sell you a thing pretending it's the first thing, and then you are stuck with all the issues when it morphs into the second. Excel is perhaps the best example of this. You think you don't need to understand coding, because how hard is it to wire up some cells? Time passes and you have a bunch of VBA scripts and DLLs hooked up to buttons on your spreadsheet, and it turns out things were a lot more complicated than you thought.

WillAdams 4y ago

I've been hoeing this row for a while now, and have a preference for these tools. My current favourite is BlockSCAD: https://www.blockscad3d.com/editor/ https://www.blockscad3d.com/editor/ which I've been using to explore 3D design and joinery: https://willadams.gitbook.io/design-into-3d/3d-project https://willadams.gitbook.io/design-into-3d/3d-project The problem always becomes one of extensibility --- if you use a lot of modules, while functionality goes up, the expressiveness/communicativeness of the code goes down because you're back at a wall of text --- it's just one in pretty blocks. What does an algorithm look like? The Drakon folks sidestep this by claiming that there should be one desired path and just connecting blocks in a straight line. I'm currently working in OpenSCAD Graph Editor: https://github.com/derkork/openscad-graph-editor https://github.com/derkork/openscad-graph-editor which exposes _all_ of the OpenSCAD language, and allows me to loop in RapCAD and am trying to balance visual display and complexity. I really wish there was a block programming or node graph interface for making a graphical application for Windows or Mac OS.

antipurist 4y ago

Sure thing, if you're building something complex, you have to deal with complexity, there is no way around it, low-code doesn't change it. But I've seen lots of non-coding professionals who spend hours every week just looking up some info on various websites just to copy some text/number/address from a well-structured page and paste it into a spreadsheet. Could this be automated? Absolutely! Do they want to learn how to write a program, handle errors, manage the deployment of their scripts? Absolutely not. Low Code has its place, and there are no conceptual downsides to starting with a low-code solution and then hiring software engineers to flesh it out and handle all the special cases. All we need is a low-code platform built around some real programming language that you can put into git, review, debug locally etc — with a no-coder-friendly interface built on top of it. This part is missing, and that's what causes people to dislike the low-coding in general.

prng2021 4y ago

This is a really poor generalization. Does anyone really think every company is a snowflake with a truly unique set of business processes? Of course not. Anyone who has worked at more than 1 company in their career can see lots of similarities for themselves starting from the onboarding process. Dig into that and you’ll find some low hanging fruit for automation with no code/low code platforms. If you’ve completed the discovery and requirements gathering phase and try to implement a complex application with a no code/low code platform, you’re probably early in your career or this is the first time actually using no code/low code platforms for something besides a pet project. So you made a mistake and should just be more cautious in the future, not write off these platforms entirely.

robjan 4y ago

I once worked at a company with very complex business processes but no ERP to solve them. Everything was Excel documents in shared drives and emails. We provisioned a low code "quick wins" team to start automating these manual processes while we were implementing the ERP. There's a space for both low code and high code solutions.

ascotan 4y ago

This is what I call "Bayesian software" - it will get you quickly to 70% of what you want but getting 100% of what you want is a game of diminishing returns. For some companies 70% solutions are ok and it's a tradeoff in terms of functionality vs cost which everyone has to make. The reality is that a lot of software engineering is moving into the 'low code' space even if they don't call it that. This is part of a general strategy to sell B2B services (like cloud platforms or cloud tools) where engineers aren't really developing solutions from scratch as much as they are configuring tools provided to them via a B2B sale. Is this software engineering? I guess it's debatable but it's clearly not 'applied science'. I see this as a general trend in any craft - craftsmen get displaced by cheap industrial alternatives (like plastic chairs vs actual decent chairs made by a craftsmen). There is no argument that a handmade wood chair made by a craftsman is better, but for many consumers at the bargain store, they want cheap plastic foam-injected chairs even if they are poorly made and break. Does the argument hold that these cheap alternatives are "more expensive" in the long run? maybe. It depends on what you're doing with the chairs. I think one serious downside to 'low code' solutions is the brain-drain on new devs. I see so many engineers that don't understand basic software architecture because they've spend their career configuring B2B tools. Overtime this model of software will cause us to loose core CS skills.

datastoat 4y ago
I’m curious! Why “Bayesian”?

roflyear 4y ago

Just have every function be a logic app that no one understands and costs $25 a month to run. What could go wrong?

thadt 4y ago

Yeah? I'm working with a class using a lot of visual/block coding in Microsoft MakeCode. But then, I've also spent time writing code at various places in the (abstract) chain: hardware <- uCode <- asm <- C/C++ <- TypeScript <- MakeCode/Scracth In terms of size, C is lower code than asm. TypeScript probably less, depending on what's being done. MakeCode uses blocks instead of text, but the logic concepts are the same. At each step up that stack it gets easier to do some things and harder to do others. Where along that stack does it become 'low code'?

sullivanmatt 4y ago

My day job is security engineering, and I just keep encountering the same problem over and over again: the code is the easy part, it's all the other shit that sucks. I don't want to write a bunch of terraform, set up a CI pipeline, and have to justify why I haven't updated a docker container's dependencies in like 6 months. I just want to write a little Python and make it available on the internet somewhere. Why is that hard? I'm working on a side project to basically make the tool I wish existed: https://integralcloud.io https://integralcloud.io If you have a use case that you are willing to talk to me about, please reach out (contact info on my profile). I won't try to sell you anything, ever. I just want to hear about business use cases and try and make something people want to use.

yibers 4y ago
Can't you jusy use a servetless function such as Aws Lambda for this?

0x445442 4y ago

Ah, management’s never ending dream to commoditize software development; gotta love it. I’ve spent the last several years being paid good money working on various failed “digital transformation”projects and am currently working on another one I predict will fail. One of the root causes of these failures is viewing the actual software development as a mere afterthought once all the high level boxes are drawn and power point slides created. Tremendous resources are spent on everything ancillary to the software and insuring proper adherence to process is kept no matter how orthogonal that process may be to maximizing the delivery of quality software in a timely manner. It’s really quite amazing.

JackMorgan 4y ago
I make a great living cleaning up the unholy messes made by low code projects! I'm doing one right now that took me a month to convert a project that had been grinding to a halt for several years on one of these low code platforms. My customers are thrilled I can knock out a couple "impossible features" in a day because the data is now stored in SQL and not some UI driven monster web based "database" with no formal query language. Another commentator likens these tools to mass produced plastic chairs, but for me, it's more like a plastic car engine that just melts if you go more than 15mph or you try to carry more than one passenger. And these engines are being sold to trucking companies, taxi companies, and food delivery companies. Sure those plastic engines are really cheap. But good luck when you suddenly are carrying more than a few sandwiches a few blocks away.

ncphil 4y ago

No kidding.

roncesvalles 4y ago

Having worked professionally with low-code tools, low-code is just coding but with less expressivity and worse ergonomics. In layperson terms, you're still implementing the same logic - just that now you have less flexibility and precision to implement exactly what you want (expressivity), and the UI/UX is "clunkier" than if you just wrote some code in an IDE or text editor. There are also a few other problems that are prevalent in the low-code ecosystem but not fundamental to it: - not having good version control - not being able to port what you built (vendor lock-in) - not having a good way to collaborate These are very powerful things that we take for granted when writing code in a version-controlled repo.

hermitcrab 4y ago

As a developer writing a low-code data transformation tool, I have some skin in the game here. I believe that low-code tools are only good for creating a small subset of software systems. This is because software systems are incredibly varied and they often don't fit into the restrictive framework set by low-code development tools. On the other I believe hand low-code tools can be very useful for more restricted domains, such as data transformation, 3d animation or audio design (although they aren't always a better alternative to code based tools).

siliconc0w 4y ago

The problem with no-code or even LLM-driven app development (so far) is that the tool, or the language, isn't precise enough to tell it exactly how to behave so you can only really implement stuff that is extremely basic and pre-canned. Even then, just building a thing isn't really the goal. You want something sustainable. Sustainable means the ability to build and reuse internal and external libraries, security best practices, version control, unit and integration testing w/ continuous deployment, monitoring, etc. You need to be able to reliably change/extend it over time as business requirements change. You could build a 'low-code' solution that tries to address all of these but it just starts to become another programming language. And because it was never designed with that intention, it's usually a pretty poor programming language.

usrbinbash 4y ago

There are exactly 2 types of lowcode environments: One is so complex, and allows the user so much freedom, that it is a fully fledged programming language. The fact that it requires me to shove little boxes around in an interface may make it better for some domain specific task, idk. What it certainly does, it makes it next to impossible to integrate in any standard IDE, usually doesn't play nice (if at all) with version control, and searching through code becomes a game of "Where's Walter?". The other is so simple and obviously shoehorned to perform a narrow set of tasks, that it is almost, or completely, impossible to do anything else with it. Which is perfectly fine right up to the moment where the user needs to do something the framework didn't foresee, and suddenly engineers are asked "can we integrate that? we only need one small thing...". Which the framework, being ~narrow and prohibitive~, excuse me, focused and streamlined, usually fights tooth and claw, but engineers somehow get it to work anyway. Until the "one small thing" becomes many small things. And some slightly larger things. And the occasional big thing. And then those same engineers need to rewrite the whole thing, which would be fine, had it not been first "implemented" in the glorious "lowcode/nocode" environment, which suffers all the problems outlined in the first type, so we spend countless hours unpicking a pile of spaghetti made from colored boxes and lines, and the complexity the framework shoved under the rug, to figure out what that thing was supposed to do in the first place. This is the reality of low/nocode environments. And it baffles me to this day, that this idea, which isn't new btw. (it existed under different names since at least the mid 80s), keeps popping up and dominating headlines every few years.

ethbr0 4y ago
That's one reason I refuse to consider low-code environments that don't have a well-modularized and standard-following escape hatch to an actual program language. As soon as you start writing custom modules, it should always be in a general-purpose programming language.

werber 4y ago

I started using chatgpt last week for coding problems, and while it's not perfect, with very specific questions and code examples fed in, the results coming out saved me a lot of time, even if i'm rephrasing a question 5 times

mbbui 4y ago

With the dawn of LLM, I think low-code will be mainstream again. Of course it all depends on the applications. For applications where scripting is all you need, you can pretty reliably generate code with prompts.

majkinetor 4y ago

Amazing article that correctly frames the most troubling aspect of complex software. No code tool is just irrelevant detail. Good job Jay little!

GalahiSimtam 4y ago

Every low code sounds like a plan, until you have to make something like "computer AI for Heroes Of Might & Magic 3 battles".

ab_testing 4y ago

I don't know why people like to blast low code developement on HN in general. The US and worldwide software development market is big enough to support both full software engineers and low code developers. Each has its own place in the enterprise. As somebody who has worked a lot in the low code development area for almost a decade, these tools give a lot of capabilities to non-engineers. I usually see low code software development being used in the government sector where it is used by epidimiologists to track disease spread during covid, policy analysts and even environmental engineers to track pollution and build dashboards based on that data. If not for these low code tools, that money would have been spent by the goverment on expensive consulting engagements to IBM, Deloitte and other government software vendors who charge $400/hr just to gather business requirements.

gloosx 4y ago

Very nice article, as an experienced software developer I feel this to the bone. I also feel the same applies to all-in-one cloud platforms aka fire/supa/megabase, which are promoted to an extreme these days. It enables fast-forwarding system design decisions and getting something running quickly. It lowers the barrier substantially, but configuring and using it in the right way – from the good data model to safe and secure so-called cloud functions – takes the same skill and time as setting up your own custom solution for your problem using a handful of open-source Docker containers, the compose file and a VPS. Of course, it requires you to be more mindful and aware of what you're building, as well as to subscribe to the requirements of your problem more deeply.

cudgy 4y ago

“It therefore falls upon our shoulders to validate the approach suggested by the client before we possibly waste both their time and money developing it.” I agree with this statement, but who pays for this analysis of the customer’s analysis? Customers expect to pay a developer for their time actually writing the code for the solution. Within most companies, developers are expected to build according to the specs from the domain experts and not argue about the specs or rehash the approach requested.

motbus3 4y ago

For me, people get mislead that 80% of the work only leaves 20% to go. You can use any platform, language, tools, paradigm and it will not be enough because software development/engineering is solving problems