I have twice now built in-house low code interfaces for companies. A recurring problem is when the same product manager who requested the low code interfaces turns around and created a bunch of stories that go beyond the limits of said interface. It's like they ask me to build a high performance racing car and then on race day they bring me to an off road dirt trail.
Will low and no code tools ever truly disrupt tech development?
191–200 of 208 posts
Re: Will low and no code tools ever truly disrupt tech development?
#192I think no code/low code solutions certainly have a place, but the way they're currently designed is not necessarily helpful (I've worked on replacing integromat and automate.io solutions in the past). Those solutions are fine, for the most part, but they're main flaw is that in order to get anything done you have to integrate them with other tools/software, which means that you're limited by what parts of the api th…
100%. Key thing is finding the right abstractions where the tool does enough to provide real value, but slots neatly into your existing workflow without requiring a bunch more work to actually integrated.
Re: Will low and no code tools ever truly disrupt tech development?
#193They are already. I consult for a lot of hyper-early-stage YC startups as they formulate their plans and I've had two separate clients in the past 6 months go the no-code route to build their MVP. At first I was against it, but having seen these clients go through it I would say it is much cheaper and less risky and gives developers an extremely good blueprint for when the founders inevitably decide to go beyond the…
It was low-code for the back-end as well or just front-end?
Back-end feels really risky to me, because visual logic builders are just so limiting compared to code.
Re: Will low and no code tools ever truly disrupt tech development?
#194For everyone saying no, this is exactly what Shopify, and arguably Wordpress are. These things have already disrupted tech development. I think the real question is how much complexity can they take on, and I think they’re largely near the end of that curve.
The difference is that Shopify and Wordpress are for well-defined solutions (shopping, blogs, landing pages), but are NOT viable for custom software applications.
Re: Will low and no code tools ever truly disrupt tech development?
#195Earlier quoted context omitted.
The problem is difficulty in developing the business requirement. I have to plead with Product owners to give me more than a few sentences about what it is they want to built. It makes no difference what the tool we use to express requirements is if we cannot have a firm grasp of the requirements themself.
This is actually the strongest case in favor of "no code" tools IMO. Get the PM to spend time actually modeling what they want, as close as they can get, in no-code tools. They get to bash their head against the wall for a while until they give up and bring in engineering. But now (a) the PM actually has some intuition around how complex things are, and (b) their no-code solution is probably a better approximation of…
Much the same experience using Excel - people describe a problem in English with a lot of glossing over of details, but asking them to mock something up in a spreadsheet brings home some of the complexities.
Re: Will low and no code tools ever truly disrupt tech development?
#196Low/no-code tools as replacements for devs is never going to happen. But as an " aid " to empower developers... absolutely. The lowest hanging fruit for a low-code solution would be in the Front-End space since you're dealing with a visual medium anyway, and because Front-End work isn't " hard " as much as it's super tedious which is generally a good target for disruptive automation. Of course one of the big challeng…
> The lowest hanging fruit for a low-code solution would be in the Front-End space since you're dealing with a visual medium anyway, and because Front-End work isn't "hard" as much as it's super tedious.
I think the take that frontend isn't hard is extremely outdated. Responsiveness and a11y are nuanced problems with huge surface areas. As designs get more complex, keeping all these things in check requires tooling that needs to be learned. People on HN constantly bemoan the complexity of frontend development and how hard it has become. There's a reason drag and drop isn't the default way of creating a web page, despite tools for this being around for 30 years.
Re: Will low and no code tools ever truly disrupt tech development?
#197Earlier quoted context omitted.
Honestly, I might be wrong, but in my experience the target consumers for no-code/low-code aren't the people completely intimidated by computers or navigating software in the first place. However, someone who wants to build a tool for themselves or someone else are not necessarily experienced enough to build it using code, and these seem to me to be the ones who are more likely to turn to a low-code solution. In the…
I'm not sure we're talking about different things. > in my experience the target consumers for no-code/low-code aren't the people completely intimidated by computers or navigating software in the first place. These tools are definitely not for them, I agree. > Low-code solutions seem to be just a lower on-ramp. Agree. > a lot more people can "code" than can write programs in the sense that they fundamentally can abst…
I think we're basically saying the same thing, but I suppose the confusion is mostly semantics.
>At that point you're training a developer.
I don't think this is necessarily the case, or even if it is, I see this as not a problem and even a perfectly acceptable situation. The goal overall is simply to take someone who wasn't originally hired to code, or someone w/ institutional knowledge but no traditional background in programming and empower/enable them to build production applications or tools. Whether in doing so they learn to write code or not is not really an issue one way or the other.
>They are perfect for lazy programmers, but less so for "Citizen Developers".
This was in your original comment and to what I was mostly responding. It seems to me that low-code solutions like Excel do indeed enable people who don't consider themselves programmers to build tools. To a certain extent no-code/low-code solutions like Squarespace do a similar thing, where someone without ever knowing what HTML or CSS is can still build a website, but obviously someone with additional experience would be able to make even better use of the tool. Basically my issue is that I think low-code solutions can actually be pretty decent and useful, but there are a lot of bad solutions out there and I obviously don't see them displacing coders. However, I wouldn't go as far to say that you need to train someone to program in order to make use of low-code solutions.
Re: Will low and no code tools ever truly disrupt tech development?
#198Yes, absolutely. I know firsthand. Instead of hiring developers to do a 2-month project to build us a suite of admin tools, I built them myself in Retool over the course of a couple of days. For a non-developer, maybe we're still far away from disruption. Excel seems to be the programming platform of choice for most people anyway. But for developers, these things turn you into RoboCop. It's amazing how much I can get…
I've used Retool as UI and Airtable as DB for so many tiny custom apps, it's great. Retool ends up being used to create "constraints" on top of Airtable in a way that enforces how people add / view records.
It's such a great combo.
Re: Will low and no code tools ever truly disrupt tech development?
#199Earlier quoted context omitted.
Java is somewhat legendary for being rather overly wordy. But, if a new language starts off its list of 'why should you use this' with comparing how to write to the console (java: `System.out.println`, other languages: a simple `puts` or `printf`) always strikes me as silly and turns me off of the language. Who cares? When I'm writing toy command line apps, complexity is never going to be the problem, certainly not i…
If I made a tool that was good for large codebases, I'd demo it by making a video ostensibly demonstrating someone unfamiliar with a large codebase reading a simple JIRA ticket for the first time and then using the IDE/language/toolset to explore the codebase and figure out what actually needs to be done, the whole time narrating and pointing out each feature of the language, tool, IDE, etc that makes this experience…
> It could even be a relatively fake example and I think it would still land if your audience has had experience exploring large codebases
The problem is this can get pervaded quickly.
In most extreme cases, the 'example' is literally only useful for hello-world style things, and anything more complex requires digging deep into docs to understand (I can think of at least one .NET library where this 'blogger-friendly' API structure exists...) And then as alluded to, every example shows this simple case that doesn't help anyone know how to configure things in ways that are testable/etc.
Re: Will low and no code tools ever truly disrupt tech development?
#200Earlier quoted context omitted.
> My main issue with low-code/no-code is that it attempts to solve the complexity problem, without understanding what "complexity" is. I get your point. But without low/no-code tools I would argue a lot of simple workflows have to be implemented using code. These usecases, where the technology-side is simple, is a good fit for low/no-code platforms IMO
The magic will always be in deciding where to stop using low/no-code and start using actual code. domain specific and opinionated low/no-code tools with clear boundaries on what the tool can and can't do would be a good thing but the markets would be small and that's a bad thing. I've seen teams spend a lot of time in low/no-code tools and either it grows more complex than actual code or they resort to the escape hat…
> I've seen teams spend a lot of time in low/no-code tools and either it grows more complex than actual code or they resort to the escape hatch (node that executes user defined code) and the visual tool basically becomes a container for actual code.
The ideal state alluded to is that Dev teams write modules that cleanly 'plug in' to the flowchart mess, but the reality is that a Dev team that can write code at that level (in a modern world, it implies at least an abstract/subconscious understanding of mid-advanced FP-ish concepts, including merging Procedural things like calling the bizarre webservice you're probably integrating with, while striving for idempotency based on the provided args/context.)
At that point, said devs likely are of a skillset they could build a framework for lower TCO, or at the very least are productive enough that they aren't the problem.