I really just want to understand what their concerns are and why the idea of a low-code solution for developers can seem so threatening, when in fact the goal is just to improve the developer experience.
Tools and services that package something like notifications up for easy integration are not really low-code/no-code. Useful tools and services save development time but that doesn’t mean they eliminate programming jobs.
I’ve been programming for over 40 years and have heard the no-code/low-code predictions since I started. The day I see a manager or end user with no programming skill and experience do my job with some connect-the-dots visual tool or AI I’ll retire. I don’t expect that will happen anytime soon because translating algorithms to a programming language is not the hard part of programming.
I agree with this bit, but often struggle to verbalize what is hard. I'm curious to hear your take.
I usually say, in a hand wavy way, that structuring large logical processes takes a lot of deep concentration, but that doesn't quite capture it.
When someone hires me to solve a business problem with software they aren't paying for my knowledge of Javascript or C++ syntax, or how to implement a linked list, or call an API. They are paying for a solution to a problem, and solving that problem means I need to understand it and draw on my experience and expertise. Sure, anyone can learn Python in a couple of weeks and get "Hello, world" to work (I've taught teenagers Python programming myself). But there's a big distance from there to solving actual problems with software, and adding value to an organization with programming skills.
Anyone can learn how to sum a column of numbers or take a blood pressure reading in a few hours. That doesn't make them accountants or doctors.
Different problems and business domains have varying degrees of difficulty. In general the hardest problems are:
- Defining requirements as completely and unambiguously as possible.
- Breaking requirements down into tasks suitable for estimation and implementation.
- Deciding on appropriate data structures, i.e. a relational database schema.
Inexperienced developers (which would include much of the target market for low-code/no-code tools) often make obvious mistakes: failure to test adequately, missing edge cases, not understanding security, implementing fragile and low-performance solutions, etc. They also usually have no idea how to approach debugging a problem, or even describe a problem -- anyone who has worked a help desk or had to respond to trouble tickets knows that.
Excel is a classic no-code/low-code tool. If you have ever had to review and debug spreadsheets put together by non-programmers you have seen what happens. The tool itself is very powerful and non-programmers can get a lot working, but on inspection you find formulas with errors, poor performance because of ad-hoc organization and data types, hard to reproduce bugs, etc.
I have worked with a lot of WordPress sites put together by small business owners and marketing agencies. WordPress is a low-code/no-code tool -- almost anyone can get a basic site up and running using a hosting provider, and install any number of themes and plugins to add functionality without any coding. But as soon as something goes wrong, like incompatible plugins, or some integration is needed like pushing sign-up forms to a CRM, the amateur developers are stuck.
No doubt there's lots of low-hanging fruit. I don't have a problem with non-programmers using tools like Excel or WordPress to solve their business problems, or even writing small Python scripts to automate something. That's not really what I do, and I know they will hit a ceiling pretty fast where they get in way over their head with how to define a problem, decompose it into tasks, algorithms, and data structures, implement in an organized way, test, debug. I can get so far with working on a car or motorcycle with my limited mechanic skills, but more often than not I need a professional with the right tools, expertise, and experience because I quickly get in over my head.
1. Used it themselves and didn't move any faster because of having to learn a new way of thinking
2. Used it themselves and tried to do something that seemed reasonable to them but the no-code couldn't handle
3. Had a no code solution built elsewhere in a company dumped onto them for maintenance, or to be implemented into an more robust product. I've seen this play out as:
- Marketing/Sales "this mostly working and critically important to our pipieline, fold it into our system and add these 3 features. ETA should be like 2 weeks right?"
- Engineering "what is this? I've never heard of it. It's going to take like 4 months to fold it into our system properly and add those features. Why didn't you ask us to build this from the start? It would have taken way less time."
- Marketing "You said it would take a month to complete, and a month before it would be prioritized. We needed it in a week so we did this. If it only took us a week why will it take you months?"
1 and 2 are mostly folks who aren't the right target market, they're right and also they don't really matter unless you're trying to target those devs specifically. 3 is a real concern, because those are the devs who will campaign furiously against a product in meetings, getting burned by that once sticks around for a long time. And both sides of the conversation in 3 are often correct from their perspective, which makes it even harder. A no code solution that actually has an off-ramp to a more robust implementation would be an amazing way to deal with that, but that might always be against incentives.
> I work for a SaaS product that enables developers to build app-to-user notification systems with minimal code, which I think it genius.
That sounds like an interesting problem, and one that is relatively well scoped. It's a good candidate for a low/no-code approach.
> I really just want to understand what their concerns are and why the idea of a low-code solution for developers can seem so threatening
Wouldn't use the word threatened.
Low/No Code always gets you 90% of the way. Then remaining 10% are a nightmare to deal with since you now need to extend a tool that really wasn't built for it. To do so it's always custom languages, proprietary extensions and plugins, obsolete or incomplete doc. And don't forget all your work can be undone in a single breaking update from the vendor "Ohh sorry we deprecated that API because there was nobody except you using it".
When used properly, no-code and low-code platforms are great. They let a much broader population of non-developers build things and automate workflows. Even for people with an engineering background, they're often just simpler and faster to use than writing code from scratch. One of the best uses I've seen for these platforms is when prototyping a new startup or product idea–you can invest a few hours of work to build something that can demonstrate a proof of concept.
However, the vast majority of the time I see low-code platforms being used at scale in an enterprise setting, they're being used in ways that create more problems than they solve. The core problem is that these platforms aren't built in a way that encourages maintainability and collaboration at scale.
Why? When using a no-code/low-code platform, you're still building software, even if you're not writing a single line of code. And if you're trying to collaborate on that software with other people, you'll want things like version control, code reviews, unit testing, dev/prod environments, etc. Most NC/LC platforms don't provide any of this.
I'm working on a startup, https://www.airplane.dev/ where we're building a platform that lets people create internal tools more easily, and it's technically a low-code approach, but it's very different than most of these "siloed" app builders out there. You can express everything as code and version control it, write unit tests against it, etc.
- Vendor lock-in: if each low-code platform offers a different set of components and workflows, then it may be difficult to move to another if, for example, product cost becomes prohibitive at a later date.
- Dishonest platform: unless the product provides an on-premises option (and many likely won't, partly because it is genuinely easier for users to get started with a cloud option), then both code and data is potentially available for the platform to inspect.
- Business continuity risk: as with the previous risk, this depends on the availability of on-premise hosting (and/or product code available as FOSS run-it-yourself): if the low-code provider ceases to exist, then your business process (or perhaps entire business) may fail.
There are some slightly more technical concerns that I have too:
- Testing and source control don't always seem apparent or well-integrated, making me think that we are going to repeat some of the software engineering mistakes of the past.
- Depending on the concepts and components exposed by low-code platforms, expressivity and capability can be (intentionally or unintentionally) limited. Integrating with an arbitrary weather forecast API that speaks an arbitrary protocol is possible using a generalized programming language - is it equally possible with each low-code platform?
Democratizing technology is important and low-code will I'm certain help discover some excellent workflow improvements.
However I think it is equally important to make it simple for someone to pick up a programming language -- that supports testing, source control, and so on (without requiring the user to know about them, initially...) -- and start on a path that will lead them towards established and recognized best-practices and an open, competitive ecosystem.
Low-code platforms tend to come with complex licensing agreements, typically with variables for the size of the functionality developed, and the number of users - this left us in a sticky place when the supplier increased the cost for the functionality delivered without significantly increasing value delivered. Like all agreements, there are things you can do to increase value without exponential increase in cost, and we've done some of these.
So the real issue is that the application architecture becomes license-driven rather than best-practice driven, and we paint ourselves into corners and reduce the overall value of the solution because of this.
So my advice is not to avoid, but when you do proceed make sure that the cost increases are limited to CPI (or similar) for the same functionality (and don't factor an expiring discount into your ROI calculation - make sure it's worthwhile at the non-discount price).
We've also had issues with branching, merging and version control, but that's secondary to the license-driven architecture problem.
The real benefit of no/low code is giving the 5% of users in my org who care enough a way to make their mental maps of business processes explicit and shareable. That way if we outgrow no/low solution we have a sketch for a tool needing custom development.
Usually, no-code solutions are a great way to get started easily and cheaply at the beginning when you don't need everything and time is precious because you are so terribly short-staffed. The risk ends up being that, down the line, you're dependent on this thing that can't be made to do the things you now care about, and you have to spend a fortune and risk breaking your core product, to excise the no-code thing and "build something real"
Nobody thinks that you can scale the next Amazon.com on no-code platforms. However, if you're just starting out and you want to demonstrate the value of an idea without hiring a developer or learning to code, these platforms are a godsend. They've enabled an entirely new segment of the population to develop tech, where previously they would not have been able to.
https://techcrunch.com/2021/03/08/zapier-buys-no-code-focuse...
At first glance it looks like they’ve reinvented HyperCard (circa 1989) or something similar, but for the web. Dreamweaver (now an Adobe product) came out in 1997, got lots of use back then, but I haven’t seen anyone using it for a long time.
This space is fairly well explored and has been for decades. That doesn’t mean the tools are useless, but I’m not seeing the big innovation that will let non-programmers write sophisticated software.
I am personally hopeful about GPT-3 The two tools I'm familiar with TabNine and CoPilot both look great and seem easy to use. Maybe they will change your mind.
You don't need to change my mind. I'm a professional programmer and none of the work I do is in the domains no-code/low-code tools (or even less, GPT-3) are aimed at. These things don't threaten my livelihood; my experience has been they create more work for skilled programmers.
Also, there is a lot of programming to be done at all levels of skill. We have barely scratched the surface of the stuff that needs to be done...even a non-techie like myself can see that. So some of it will have to be done this way or it might never get done at all. That would be a real tragedy.
In the Quality Engineering/SDET realm, I get dozens of emails a week for low/no-code solutions around test automation. I get at least one or two calls a day from someone pitching their solutions. I don't care about their no-code RPA solution because I've got fantastic engineers writing actual code.
If they knew their market, they would target the finance users, the ERP systems, the SFDC and SAP engineers, or the manufacturing bridge groups. Places where they could actually get a sale from individuals who want to bridge the technical-automation gap.
If someone's career depends on them not understanding something, they won't.
For example, Zapier is a flow automation tool in the broad RPA category - they automate triggers and steps between different existing applications. The "code" version of these things is usually data integration plumbing that be built as a FaaS in a few weeks.
This is completely different from say, Salesforce or Dynamics 365 apps, also low-code/no-code but where the platform's goal is to build applications tailored to your requirements using the platform's customizability, database included. The "code" version of these things are fully fledged web applications that take months or years to build. This is a much higher bar to meet for these platforms.
Yes coding is a different language than most people are used to speaking, but it isn't as difficult as some like to make it look. And the average person would rather do something else (rather than sit and type all day).
In the end, I'll probably use Budibase because it's FOSS and it seems more like the needed framework than the others.
But the hate shouldn't surprise you...devs have been told for years that they were the Kings of the castle....and power concedes nothing. Anything that is perceived to reduce their power will be bashed.
I'm afraid that You are mistaken - literally no one tries to make the coding (or rather software development because coding is only one step of it) more difficult than it is.
The thing that You missing is that the language of coding is like no other because the receiver of ot is different. There is no human on the other side (lets ignore collaborative nature of bigger projects for the sake of simplicity). The computer will only do EXACTLY what You ask him to do. Nothing more and nothing less. And this is key to understanding where most of the complexitu comes from - most of us do not have to ability to speak precisly and completly. We are mostly able to bubble about the things that are somehow similar to things that we think we need.
I am able to talk with all kind of people and believe that at least trying to get into shoes of other person is the key to beneficial cooperation. Without it we are risking conflict escalation. And don't get me wrong - I completely understand where Your frustration is coming from (I had my fair share of introvert programmers to deal with) but I always try to not get overly emotional, and with a little bit of self control this can be done. Just don't expect that the other side will read You mind if You are not willing to read their.
So get a thicker skin?
>> Yes, I really enjoy being insulted by perfect strangers on the interwebs.
Ok, your loss. I will give You a little secret about communication with people in IT (or rather STEM in general). The things that we are saying more often than not are not intended as an insult but only as an opinion, statement or diagnosis. Don't mistake directness for rudeness.
And truly I care more about the curation aspects of HN than I do about having conversations with tech people. I remain convinced that for the most part it is a colossal waste of time. Very little listening happens.....
Having worked at Microsoft on VBA-related things, I can attest without a doubt that no code automation (e.g. record a macro) are extremely powerful. VBA did give you the right tooling allowing someone with no coding experience to start tweaking macros generated by the recorder. The macros created by these often end-up being business critical. After having talked to so many huge customers, I'm convinced VBA powers at least a single-digit percentage of the world's economy.
That being said, the code of the macros often end up being a huge unmaintainable mess. Creating a lot of aversion from actual pro devs to it.
No-code solutions also end up being great for a few use cases, but fail at making complete products. It's the classic 80/20 problem where the last 20% still matters a lot. As soon as you want to step out the the guard rails, you often hit a wall.
I think no/low-code can be great and actually think VBA was awesome (well, not the language, but the platform). But, after having seen so many platforms that can't do anything more than a simple demo, I don't blame people for being doubtful about them in general.
- Lack of good versioning / source control
- Poor support for 'schema changes' / data migrations
- Running into limitations that prevent you doing something you really need to do and not offering a good 'escape hatch' to extend with custom code
- Poor / missing support for testing and things like staging / production environments
- Lack of support for 'metadata' - things like comments, commit messages, seeing who changed what and when, especially when multiple people get involved (this is maybe another way of saying 'version control')
- Pricing plans that make it very expensive when you cross certain usage thresholds or require certain features, or simply hard limits on usage that you run into and are hard to work around
- Vendor lock in and difficulty hiring/training people to maintain and extend the solutions.
All this is not to say that some of these tools don't have value, we still use some, but over time these limitations become greater relative to the benefits you see early on in terms of ease of use and speed getting something basic up and running.
I have deeply reviewed PowerApps, Mendix, Outsystems, Pega, and Budibase. Despite what the vendors promise, this is more evolutionally than a revolution. Most still have serious problems at scale, and model driven development proves to be quite difficult for almost everyone. It's just not clear what value this provides: a typical CRM or BPM stack is better for semi-techincal users; programming languages are better for truly custom applications.
One problem is that it's built on a few layers and those layers often have bugs and limitation. We'd be making games and realize... oh, there's an 10000 object limit. Or that the movement engine has some miscalculations under certain conditions. Or that it doesn't have syntax highlighting and becomes very tedious to build/debug things that involve over 10 variables, like a city population formula.
We'd end up building hacks, plugins, our own systems to make up for these drawbacks. One guy made a syntax highlighter to copy paste. Another plugged it into Lua, so we'd write code in Lua and some adapter to have it reflect in the game.
In my previous job, we considered hiring people to do Cordova development, or try RN/Flutter. The CTO decided to just go native because we didn't have a big budget and it would be cheaper to hire both Android and iOS instead of spending months on plugins.
If you’ve identified a legit user pain and developing something that addresses that pain you’re on the right track. Put it in front of users, get feedback and iterate.
However if your demographic is technical folk who aren’t developers, then these things can be a massive asset.
No-code products are well established as a successful model. Don't listen to the haters. But you have to market it to tech-savvy non-coders. Your product needs to empower them beyond what they can do on their own without it. Few no-code products empower people who can code - it may speed things up, but ultimately it forces them into your structure which is limiting and frustrating.
[1] No affiliation
[2] I've built complex notifications systems myself and think Courier is a beautiful solution for coders and non coders alike.
They can do mouse clicking and typing words (often very well, they are not dumb) but everything is manual, as MS has trained them do.
Same with very good Excel users, who you think would have a leg up.
(source: dos, powershell, power automate, power automate desktop, autohotkey, many chrome plugins).
I told a friend who's kid likes game design to make sure his kid is actually programing. Once you get past the first 6 months or so, things start to make sense. If you can write a C# class at 19, you'll be doing very very well on your 20s.
Low Code solutions don't teach you any real skills at the end of the day.
Hard disagree. Solving business problems is a "real skill" regardless of whether you're spending a week writing custom code which has to be maintained or gluing services together over the course of a day. Developers who don't have low code tools in their toolbox are going to be less efficient than those who do. Not every problem is a nail.
That's the promise of No Code, the business analysts are now developers.
That's the fear that you have to relieve.
But for devs it can be a restricting middle man with no benefit.
Many businesses don't need to reinvent the wheel and the more they can use off the shelf the better.
I see no code as chunks of solved problem Legos. It has it's place.
For managers its great because you can hire amebas to operate it, but the moment shit hits the fan you can do nothing beside opening a support ticket.
TL;DR good for small businesses that have very easy use-cases. Anything past that will hit a wall sooner or later.