38 ms·

Tell HN: Enterprises spend 10x more to build no-code solutions than coded ones

326 points by nancyp 3y ago

Code less sounds great for toy projects. People who aren't in tech aren't building no colde solutions beyond basic excel ones. So they end up hiring consultants to build them for them which costs at least 3-10x more if the solution were to be made with code. Ms powerapps for an example needs connector license for many basic things that costs a lot as well. This is from my experience as a consultant in many enterprises over last 3yrs watching code less explode in front my eyes.

wruza 3y ago
Key questions here are: - would they even dare to start these projects with code - does that additional cost really bump expenses despite being 3-10x more, given that a project may have already brought money or investor attention Due to selection bias, you may have seen poor whelps who otherwise might have remain unborn at all.
potta_coffee 3y ago
Enterprise leadership seems to constantly be chasing buzzwords and silver bullet solutions that don't pan out. I've seen it time and again.
- nine_zeros 3y ago
  > Enterprise leadership seems to constantly be chasing buzzwords and silver bullet solutions that don't pan out. I've seen it time and again. This is what gets them stocks and promotions. Doing the "right thing" is much harder and requires them to understand internals of systems before making a call. They'd much rather point to the buzzword of the day as the "next big" corporate initiative.
- jimnotgym 3y ago
  Enterprise leadership has been let down so many times by IT projects that they are constantly chasing lower risk solutions. Low code means not having to deal with developers in their eyes.
codingdave 3y ago
I think your experience as a consultant is showing you what happens in enterprises that hire consultants, not the overall view. You aren't seeing the enterprises who have sufficient in-house skills to use no-code effectively on their own. They certainly exist.
- taeric 3y ago
  I'd be curious to hear what those skills are. My gut is you are correct that they exist, but I'm struggling to understand where the disconnect is on so many places I've been. I'm convinced it is "the way" for many things, all told. Mario Maker and things like that are great examples. If what you are making is a Mario like game, you will almost certainly do better playing with that than you would making your own. Same for visual things. I want to like parametric modeling in the likes of OpenSCAD. However, it is are far and away inferior to traditional CAD tools. And it isn't like those do not have parametric capabilities.
logicalmonster 3y ago
I'm not suggesting OP is wrong, but here's 2 small counterpoints. 1) Where is the data (beyond an anecdote) that shows that no-code solutions generally cost 10x more to build? 2) Putting aside these initial implementation costs, do these no-code solutions have other advantages, such as being less costly to maintain, or being far quicker to customize when needs change? There's always some tradeoffs to take into account.
- specialist 3y ago
  > do these no-code solutions have other advantages No. I have some experience with low-code work flow -esque tools. BizTalk, Talend, SeeBeyond ICAN / Sun Java CAPS, a few others. Categorically, they're an angry 800lb gorilla sitting between you and your work. Their sweet spot is demos for PHBs. Their purpose is to create a lifelong dependence on the consultants proposing these tools. All of the many legit criticisms (leaky abstractions, poor version control) boil down to this one simple truth: At some point the tool won't suffice and you'll have to drop down to code. Which is likely buried under layers of XML obfuscations. Now you have two problems. (h/t JWZ) So what started as a very simple data processing problem {1}, requiring nothing more than some scripts, has now metastasized into: schema compilers; magical error handling; wrangling XML thru ancient textarea forms; fighting yet another framework/API {2}; debugging thru trace statements and grepping logs; some almighty backing database which no one can access; endless fruitless conversations with nominal DBAs about indices and workloads (and "has anyone done a backup?"). On the bright side, some days you can actually manage to fulfill a customer's use case. -- {1} Input - Munge - Output. Cut & paste strings, some light type coercion, modest value mapping. {2} Another greenfield half-baked zero-validated notion of the world's greatest workflow engine ever, belched forward over one long kids-free weekend by an esteemed principle senior software solutions architect (they wrote a book!) who is now deep into their mid-life crisis and way past burnt out, with a code base now maintained by a fearless project manager (and aspirational future VP of product) snagged from some travel related startup, with the mandate to deliver some results, so then reluctantly brought in a team of agile mercs, just to appease the over eager execs, who are trying to fast bulk up to legitimize their efforts to secure another round of funding.
  - 3y ago
spcebar 3y ago
I've seen no-code tools that are so complex and poorly designed that they require specialized teams to operate. We've worked with a number of clients that use a certain software, all of whom, despite having been sold on the simplicity and ease of the tool, retain a company that specializes in configuring the tool. Then again, no-code is a pretty broad umbrella, and I've seen tools that enable users to help themselves help themselves in meaningful ways that save them money and us spending our time on miniscule adjustments.
- sharemywin 3y ago
  this kind of reminds me of those integration platforms. where you need specialized training and consultants to map data.
  - koromak 3y ago
    Oh god. I had to "learn" a Shopify-to-NetSuite integration tool, which effectively means learn shopify, learn Netsuite, and then learn this shitty tool which does nothing but connect inputs and outputs with zero explanation. Miserable. 2 years later I'm at a different company and I still get emergency phone calls because no one understands this thing. Code would have taken longer to build, but at least new developers would be willing to maintain it.
    - jimnotgym 3y ago
      I had a team that coded integrations into Netsuite and used an integration platform for Shopify and others You always need to learn Shopify and learn Netsuite. More so if you are coding it. We often had to pull developers back from other projects because one counter party or another changed something and nobody could work out how to change it. We always ended up with scripting in Netsuite even with the integration platforms. There was no winning either way, but we went with integration platforms by choice because of maintainability and expertise from the platform engineers.
    - spcebar 3y ago
      I suspect we're all talking about the same tool.
atonse 3y ago
To me (even though I am a developer and have done little no-code, but have integrated with many Salesforce and Power Apps apps) the real promise of the bigger platforms like Salesforce or Power Apps is the baseline quality is higher than what those same developers would've built from scratch. Even just stuff around security, user management, login best practices, etc. What you get out of the box is better than 75% of teams would build custom. Sure they can be misconfigured after that. But you do get a bunch of (infrastructure-related) stuff out of the box before you get to how a dev can mess up the object design or make the UI insanely cumbersome.
yobbo 3y ago
The benefit, in the eyes of leadership, might be that the consultants/devs are easier to replace which reduces risk.
- lupire 3y ago
  Why is a no code dev easier to replace than a code dev?
  - rapfaria 3y ago
    No code devs surely won't take that much time to deliver something as code devs. No code devs surely don't need that much expertise (it's no code), so surely they are not as expensive as code devs. Earlier this week Jack from backoffice asked me if there are any positions in my eng team. I wonder if he can learn no code in a week, since it surely won't be that complex...
ebiester 3y ago
Does this include every excel spreadsheet application we have today? That is what low code should be replacing.
- darkhorse13 3y ago
  Why? Excel is incredibly powerful. Most no-code platforms can't do much compared to Excel.
  - fragmede 3y ago
    Because it doesn't version control well, it's hard to introspect, the data and code are all jumbled together. Emailing xls files around is functional, sure, but the software developer in me dies a little bit every time I do_final(1).xls I don't know that a hypothetical no-code tool does any better at any of those, but Excel, powerful as it is, has some real issues.
    - lupire 3y ago
      Excel has had version control for years, via 365. https://support.microsoft.com/en-us/office/view-previous-versions-of-office-files-5c1e076f-a9c9-41b8-8ace-f77b9642e2c2 https://support.microsoft.com/en-us/office/view-previous-ver...
      - isbvhodnvemrwvn 3y ago
        That's backup with point in time restore rather than version control. It can't track semantic meaning of changes.
      - fragmede 3y ago
        That version control isn't very good. It dumps me into a snapshot of that time, of both the data and the formulae together. Useful to see how things were 2 years ago, using 2 year old data, but in order to take that data, but use the modern formulae against it is a chore of hoping I get the copy and paste right. There is also no documentation on why those formulae were chosen. Compared to git log -p, to see the changes in all the places there are instead of hoping I click on the right cell and catch all the changes.
hooverd 3y ago
Numbers? Gives my experience with no-code solutions that aren't spreadsheets, I wouldn't be surprised.
LorenPechtel 3y ago
It still takes the same skills whether you have "code" or not.
- jenkstom 3y ago
  This is exactly right. And codeless tends to not have the capability of dealing with complexity very well, meaning architecture is brittle.
hcks 3y ago
Ok but this very strong statement has literally nothing backing it
- malfist 3y ago
  Source: Trust me bro.
  - fkyoureadthedoc 3y ago
    Nobody can talk about their life and experience without a supporting meta-analysis of a hundred studies
chaos_emergent 3y ago
enterprises who build no-code solutions tend to spend 10x more than coded ones, but in aggregate, all enterprises do not spend 10x more on no-code solutions than they do on coded ones.
lupire 3y ago
Numerical claim with no evidence. Thanks, OP.
didip 3y ago
I think the perfect no-code tools has yet to appear. Ideally, no-code tools should generate a good code (using LLM) into a git repo complete with the following: - good code structure. - test code. - database migration code. - CI/CD code. - Docker packaging code. - Basic Kubernetes/Helm code. This way, an actual engineer can take it and roll with it if you stopped using the code generator platform.
- WorldMaker 3y ago
  PowerApps will "eject" that way, but "good code structure" and "test code" don't guarantee in turn "good code", just as any other "auto-scaffolder" ever isn't a guarantee of quality and may just be generating tons of boilerplate that look productive more than actually are productive.
rchaud 3y ago
At enterprise level, it can be easier to get budget approval for consultants than hire a full-time employee to do the same thing. It's usually also easier to terminate a consulting agreement than an employment contract. Finally, consultants sometimes have better contacts for getting priority support for platforms like MS Dynamics and Salesforce that have large numbers of programmers building apps on top of them. 'No-code' is a blanket term that includes an enormous breadth of software. Zapier does some pretty impressive no-code automations across apps and it's pricing is usage-based. MS Power Apps is just one player in that market. A lot of no-code is also just adding view layers to databases so people can build business dashboards without needing direct access to a SQL environment. It may be easier to have consultants build out such workflows than attempt to hire the right people internally.
RankingMember 3y ago
Where is this 10x number in the headline coming from? Can you link some data?
- no_wizard 3y ago
  I think we may be in anecdotal territory. Though my own observation is that enterprises will spend alot of money on low / no code solutions that are a pain to maintain at scale (the worst of it is when they churn APIs and/or integrations). There's room for solutions like that, but expectations need to be managed better.
- officialchicken 3y ago
  Let me try to supply some hype ... my current no-code solution saved my team negative 0x; it was started and completed in 1 day, followed by 777 days of edits, debugging, and improvements (so far) reducing our OpEx 1568% since "code complete". To get around the 27.9% uptime, we removed that metric. The supplier (us) spent exactly $162 on the entire design and development (thanks to Fiverr). Our estimated ARR should be approaching 167 trillion dollars in 2040. The TCO is only $59,883 (ongoing AWS fees) and growing at an astounding 182% CAGR. And our ROI has already paid us back - just don't look behind the curtains or expect it to pass audit.
hospitalJail 3y ago
PowerAutomate is M$ sales people taking our purchasing teams out. I now have enough experience that I will outspoken warn people at my company, even if it means calling out tech debt that is uncomfortable.
frugalmail 3y ago
This was my experience with Alteryx and Informatica vs. Scala/Python/Shell + Airflow as well.
- threeseed 3y ago
  My experience is that Alteryx and Informatica serve useful purposes. And in fact they often don't even overlap with Spark/Airflow e.g. Alteryx is great for running on a local laptop processing Excel files.
cm2012 3y ago
As a marketer, let me tell you how things go: 1) You have a marketing project that is speculative (as all marketing is). Say it's an API hookup and some automation between some tools. 2) You submit your project for prioritization by the dev department. 3) It gets done 9 months later. The specs are wrong because there were so many layers between the marketer and developer and the developer has no context for the project. You submit edits which get prioritized and takes another few months. OR You get Zapier approved by security once. Then for every project like this you fiddle with it until it does what you want. Total time: A couple of weeks. No code removes friction from the org. Developer time is always the biggest bottleneck at any org I've worked with. Anything that let's you get around it is worth its weight in gold.
- dgellow 3y ago
  > No code removes friction from the org. That’s so true. It’s not to build quickly, it’s to keep the agency within the non-engineering department.
  - WWLink 3y ago
    To me that sounds like the argument from a business department in an engineering org. The solution is for your department to hire its own software developer(s). I'd say the same thing for an organization that is heavily business-oriented and has an engineering department that gets kneecapped by the business-team-focused IT department that can't appropriately support the engineering department.
    - bell-cot 3y ago
      > The solution is for your department to hire its own software developer(s). Vs. the reality, in most large org's - that plan gets shot down faster than non-union electrical contractors in New York City.
    - sfink 3y ago
      And people wonder why organizations have such high headcounts...
timcavel 3y ago
[dead]
bilekas 3y ago
> This is from my experience as a consultant in many enterprises over last 3yrs I get the feeling there might be some survivor bias here. You as a consultant will always be placed in front of projects that require a consultant. So those project types with wild budgets and nonsense structures and implementations are most of what you will see.
- tstrimple 3y ago
  There is definitely a bias here, but it's a bias towards very large companies. They almost all have this exact same problem. The company I work for consults with something like 2/3rds of the Fortune 500 companies and almost every one of them suffer from these challenges. Of the companies I've worked with who seem to have their shit together and are on top of everything, almost every one of them had fewer than 100 employees. That type of company, by necessity, is run very differently than a company with 100k+ employees. It may be helpful to not think of a company with 100k employees as one company. It's really multiple large companies with competing priorities who still want to be able to realize efficiencies of scale across the board. You've got different cultures and different processes across all of them. Yet you don't want each of them to be adopting "the cloud" in wildly different ways. You need consistence in governance and guard rails which cut across all of the orgs or your costs and complexity are going to be all over the place. You'll have orgs spinning up their resources in different cloud vendors which will greatly hurt your opportunities for the cost savings which come from real volume.
th3h4mm3r 3y ago
Hi, I'm implementing a new lowcode solution based on ionic and nodered and a "custom" part really big to implement ui and interaction with the backend. Imo this solutions could works if the framework (intended as I described in the first part) is focused on a little problem context (for example: developing application for warehouse terminal or a system to register datas by customizable forms and so on). Without a focus on a single problem is really difficult to create a versatile framework that mantains simplicity as main charateristic.
lifeisstillgood 3y ago
The "business/tech" divide is a terrible divide, but we seem stuck with it. So maybe make the most of it - hire and train software developers on "the way the org develops and runs software". Then embed them in business areas - literally sitting next to people building what is needed right now.
wmidwestranger 3y ago
Sounds very similar to the complexity increase described in The Mythical Man Month. The author describes how the complexity increases as a system expands in a greater than linear, and expected, fashion. So, a simple script might cost one. Adding configuration costs 3. A framework for solving similar problems might cost 9, and a platform for frameworks probably costs an unexpected large amount, like 27. I've mostly seen this pop-up along with Xeno's paradox. A rewrite of a legacy system is undertaken and the planners completely discount all the blood, sweat, and tears that went into the original. Every problem is considered "solved" and using newer tech is seen as a silver bullet. The cost is severely underestimated and the effort is way beyond initial estimates.
simonbarker87 3y ago
No code is great for an experiment - I’ll throw together a zap or two to test something and if it sticks I’ll then port it to code and properly integrate it into the system. It’s not a case of “redoing all the work” it’s about helping to know we are doing the right work.
mvdl 3y ago
No code is simply somebody else's code.
- sexy_seedbox 3y ago
  Serverless is simply somebody else's server.
BLanen 3y ago
Any truly capable no code development environment will (d)evolve into a shitty visual programming language without the tooling you expect from a modern language.
- Buttons840 3y ago
  I wonder if it being "visual" makes business owners more likely to look at the logic and realize "wow, this is a mess, let's simplify this". Whereas, complicated logic in code is seen as "just a bunch of code" and non-coders will never look at it or attempt to understand it. I store my candy in the basement, it's a life-hack to help me control myself. Maybe businesses would also benefit from the "hack" of requiring business logic to be visually represented, and thus force themselves to keep things simple. I have this fantasy where the project owner runs the code though a tool which faithfully translates it to a visual language, and then promptly gives me a large severance. On my way out he asks me what the incomprehensible tangle on his screen is, and I laugh on my way out the door.
ltbarcly3 3y ago
No code: hire people with no practice reasoning about how to create software to use clumsy tools because you can pay them 1/2 as a programmer per hour. Code: hire a professional to use the best tools that exist to do the thing they are highly practiced at. What could go wrong? I was thinking of hiring an electrician the other day, but for half as much in labor costs (per hour) I was able to find someone with no clue what they were doing to just run a bunch of extension cords.
jrockway 3y ago
I think the solution that you're paying for here is the burstable capacity. Dev teams often end up with a backlog of 100 internal requests, and all of them are "the highest priority", well, if you have 1 thing doer and 100 things to do, they can't all be processed at once. But if you get 100 consultants, then they can do all 100 high priority items in parallel. The other edge of this sword, though, is that they want real money. Your manager is going to have to approve an expense report. Suddenly, it's actually possible to break the list down into actually high enough priority to pay 10x for, and just "nice to have". That said, I'm not sure it really helps. The infrastructure to allow these consultants to be productive is going to be expensive; the dev team has to provide a safe API for these integrations, and an API "that could be used for anything" is harder to design than writing code for a particular use case. (Then again, I bet a lot of these teams get a request like "can you just give us a read only replica of your database" and get "sure" back. It will be 1 year before they realize they just lost their SOC2 compliance and their website has been lying this whole time.)
deleted 3y ago
[deleted]
cstrahan 3y ago
Anecdote: early in my career, I worked on a dev team that feared software development. They tried to push as much logic as possible into Microsoft SQL Server stored procedures (the average length was around 10 pages). Look at all the code that wasn’t written (because SQL doesn’t count), and less code means less bugs! Where stored procedures wouldn’t do, they put these of the logic into SQL Server Integration Services, which provided a visual programming environment — think Scratch but for visually connecting ETL pipelines. But, invariably, the existing components wouldn’t suffice, so they’d stuff 100s of pages of C# into these components, which would be hidden away behind a little “code block” rectangle in the SSIS flow-diagram-esque interface. Zero code reuse, no way to run unit tests, no strong typing (beyond primitive types mapped 1-to-1 with the underlying SQL queries), no codification of invariants/preconditions/etc. But hey, that C# code hidden away doesn’t count as code, so look at all the code we avoided! And SSIS is from Microsoft, so by using something they bless then we must be on the right track! What’s that you said? Should we consider if this particular tool is appropriate for our particular needs? No way! If SSIS wasn’t the optimal tool for all problems, why would Microsoft develop and market this product?! Anyway. I think the trap people fall into is this: Critical thinking is tiring, and many people are lazy. Putting such people in a position that they must actually weigh the merits of multiple options is a sure fire way to become deeply resented. Also, critical thinking makes you responsible for the consequences of your choices, whereas appealing to authority absolves you of any and all responsibility (the old saying “no one was ever fired for buying IBM”). So many attempt to reduce the amount code as much as possible. But the problem is that many worthwhile endeavors are inherently difficult, and require real, hard, critical thought to arrive at a solution, and for such things code often happens to be the best medium for reifying those thoughts into software solutions. Consequently, countless companies will choose to jump through no-code hoops, and unsurprisingly suffer the consequences. They won’t learn from it though: instead, those responsible will deflect with excuses like “well Zapier is the issue, you see”, or “imagine how much longer it would have taken if we actually coded the solution!”, or “that’s just the nature of software/tech”, etc.
threeseed 3y ago
This is the worst type of post. No data. No facts. Clickbait topic that reinforces HN preconceived biases. The fact that no-code tools are recommended so heavily should indicate that it is useful for at least some use cases.
- letsdothisagain 3y ago
  How dare you deny their lived experience? The OP clearly stated that it's BAD. As someone who runs a low code dev shop (I have a low/high mix of frameworks), I've already started reflecting on my BAD behaviour. I will repent and jettison all of my cruds, and web forms, and other dumb little things that provide so much value to my clients.
  - civilitty 3y ago
    The smiting will continue until the code quality improves.
  - fkyoureadthedoc 3y ago
    Assuming "As someone who runs a low code dev shop" is true, why the tone when you're clearly more biased than OP just on the other side of the fence? If anything you've reinforced their point, the fact that a whole ass "dev shop" exists to support low-code just supports their argument.
- sundarurfriend 3y ago
  > Clickbait topic that reinforces HN preconceived biases. Oh, I read the post completely as "no-code is what's actually in demand, stop bashing it and start building". I had to go back and re-read it after your comment to see what you mean.
- OkayPhysicist 3y ago
  "Recommended so heavily" by the suits making commission selling the things, maybe.
neeleshs 3y ago
One unsaid thing - developer salaries.Far too often (myself included) we ignore that our own salaries are a cost
trunnell 3y ago
IME a huge part of the cost of development (regardless of code/no-code tool choice) is the time spent gathering requirements and continuously validating them. When the user and developer are the same people, the cost of finding the requirements can sometimes be nearly zero. In this case, that person will themselves choose the best tool for them. And the development cost will be very cheap -- for example, think of a short script you wrote to do something just for you. But when the user and developer are different people, much care should be taken to avoid cost explosion. To the outside this can look like "coding is expensive!" which is kinda true, but really it's the requirements discovery that dominates the cost. People don't understand each other perfectly, can sometimes talk past each other, etc. Iterative development's purpose is to mitigate the problem of building for the wrong requirements. No-code tools can unblock "developers" who own the requirements but don't have programming skills. That might make those projects very cheap. Or it could do the opposite: if the non-programmers don't know think carefully about what they're building, then they might end up spending just as much time as programmers would have as they iterate towards a complete solution.
- quickthrower2 3y ago
  The issue is “requirements”. With a nocode system a person can create something that solves their immediate problem. Which is usually to get something done quickly that their boss wants so they don’t get fired (sorry too honest?). But things built that way usually wont end up being efficient ir maintainable. Everyone self servicing bespoke “code like” setups leads to a mess. There is a level of polish before self service makes sense to me. For example using dropbox is OK. Making a dropbox like thing in Bubble is probably bad!
reilly3000 3y ago
No-code systems can rapidly become indecipherable by the time they are deployed to do serious work. You would think it’s a matter of wiring up some event source block to some action block. Reality looks more like 15 steps to transform a string properly, held together by bubblegum and nigh impossible to test end to end. Data pollution happens all the time. Hold my beer, I’m going to no-code live!
great_psy 3y ago
I only have one experience with no-code and that is trying to make something in the Shortcuts app for iPhone. I tried to make a password generator. Pretty simple I thought, just have a list of words, and pick 5 words out of the list, concatenate them and spit them out. I’m python you can probably do it in one line. I spent about 30 minutes trying to get this to work. The interface as well as the drag/drop way of doing it was a huge barrier. I’m sure this can be improved, or maybe it’s not aimed at this type of project but so far not impressed by no code solutions.
outside1234 3y ago
I am shocked SHOCKED to hear this!
themerone 3y ago
I'm forced to use an issue tracker built on a low code platform. The nicest thing I can say about it is that it is the worst software I've ever used.
oooyay 3y ago
I use a low code solution on my home network to prototype applications that I don't know if I'm ready to commit to yet (Shout out to Budibase). After a certain point the application becomes too cumbersome and complex to maintain (or slow), which is when it needs real code put to it. I've had pretty good success with that pattern thus far. I think enterprises could probably do the same thing. There were people who said low-code would replace the need for developers and people believed them. That will never be the case. There are people who said it's worthless junk, and the live usecases available today show that's not the case either. As in most things, the truth is somewhere in the middle of those two ideas. That's to say, few things in the world are as binary as bits.
wonderwonder 3y ago
OP is right and wrong. I am currently a technical lead on a highly complex build that has been in development for a couple years now. A good chunk is in production, tens of millions of complicated 'product' is moved through the system every year. This will eventually scale to billions. Not making that number up, its the existing volume that will be moved over from the myriad of legacy systems we currently use as we build additional functionality. We are using lots of consultants and they are very expensive. They also don't build with the same quality as our in house teams. I can build any app I could during my full stack days quicker with no code. Obviously there are some limits but I have not had to deal with them and they are edge cases in the day to day of a web developer. It definitely helps to know how to build software and there is a world of difference between the work produced with the tool by a developer and someone that has not coded before. I went into it expecting to very much dislike it and that it would only allow for toy development. It blew me away. A team of devs that know how to architect software and this is the key; plan well, can crush projects with this. With that said, if you don't plan and just go in and start building its incredibly easy to build a mess of non maintainable spaghetti no code.
dgudkov 3y ago
Psst, don't tell the author that enterprises spend 10x for high-code solutions too by hiring external consultants.
zubairq 3y ago
Reminds me of the 1990s. The amount of work for consultants to build business solutions with no code or low code tools was staggering, including Borland Delphi, Visual Basic, Excel, MS Access, SqlWindows, Powerbuilder, and many others. I don't know if I agree with that they cost "3-10x more" than building the solution with code, as often these projects would never have been started if they were built with normal code, as the decision process is totally different in most organisations (eg: related to skills and maintaining the software)
- nvm0n2 3y ago
  Delphi/VB weren't low code! They were full blown languages with IDEs.
exabrial 3y ago
The answer is pretty obvious why though... CEOs look at devs making 6-digit salaries, screwing around with Node.js modules all day long on an endless trendmill/treadmill of "upgrades", new frameworks, UI rewrites while absolutely adding 0 new value. At the end of the day, all the website needed to do was take orders... which it did back in 1998, but now it's a million times more expensive. As much as a turd nugget as Larry Ellison of Oracle is, he absolutely nailed it when he said "The computer industry is the only industry that is more fashion-driven than women’s fashion." If a technology comes along that promises to offboard an enterprise from the endless hype train, it's a pretty easy to see why many would jump for it. That being said, I agree with the premise: no code solutions just shift the complexity elsewhere; code solutions are the right answer, but an entire generation of programmers was never taught to build things that last.
parentheses 3y ago
As a person who uses low/no code platforms to ship real products I fully disagree with this. Low code and no code platforms can do a lot to make implementing back office functions easier. It enables things that you'd deprioritize without these tools. That said, they also need to be managed like software: versioning, beta releases, risk mitigation, tech debt trade offs. While there are things that can go wrong with these tools, they do strictly make things easier rather than harder.
clncy 3y ago
MS PowerApps, PowerAutomate and related offerings are truly awful products. I’ve given them the benefit of the doubt and been burned repeatedly. Don’t tar all no/low code tools with the same brush though. I’ve had good success with Retool, for example.
rangledangle 3y ago
[IT Perspective] In my personal experience, these tools also overreach. Most people I've met in IT (15 years) want to go into Engineering, or at the very least, something MORE technical and code-related. They are hungry and willing, but often overlooked. I have seen many climb out and teach themselves code, build tools for IT and revolutionize the way teams and orgs work. It's a marvel to see someone with drive do what they desire. Fast forward to today. I see IT forcing all members to use a low-code tool. The passion drains from their eyes. I can see the fear of the mounting weight of becoming unemployable. They've shared with me their experiences. The directions they want to go have nothing to do with Low-Code, and the roles and orgs their interviewing with aren't interested in people who build with them. The question "what have you been working on?" is like a death knell. I'm pretty sure a lot of them don't see a future beyond helpdesk because of these tools. My point is, think carefully about who is using this product. You can kill careers with this stuff. I think it's great for business teams who want to "do x in x app when y happens in y app."
diegoop 3y ago
Apart from marketing, I used to work as a MS consultant for many years (10+), focused mainly on creating custom no-code and almost-no-code tools for business, and the investment was usually lower in the short term, with shorter dev times, but in the long run when the company started to use the solution in the day to day, and started needing more specific tools, no-code solutions tend to be way less flexible and end up with dodgy patches to implement functionality that could have been done in a more maintainable if was a more coded solution from the start. To sum up, and on the field I was working on, it's hard for the client to have a clear understanding of the lack of flexibility that will may face in the near future, and usually ends up on hands of the sales people and what the company providing the solution is focused on.

326 points by nancyp 3y ago

wruza 3y ago

Key questions here are: - would they even dare to start these projects with code - does that additional cost really bump expenses despite being 3-10x more, given that a project may have already brought money or investor attention Due to selection bias, you may have seen poor whelps who otherwise might have remain unborn at all.

potta_coffee 3y ago

Enterprise leadership seems to constantly be chasing buzzwords and silver bullet solutions that don't pan out. I've seen it time and again.

nine_zeros 3y ago
> Enterprise leadership seems to constantly be chasing buzzwords and silver bullet solutions that don't pan out. I've seen it time and again. This is what gets them stocks and promotions. Doing the "right thing" is much harder and requires them to understand internals of systems before making a call. They'd much rather point to the buzzword of the day as the "next big" corporate initiative.
jimnotgym 3y ago
Enterprise leadership has been let down so many times by IT projects that they are constantly chasing lower risk solutions. Low code means not having to deal with developers in their eyes.

codingdave 3y ago

I think your experience as a consultant is showing you what happens in enterprises that hire consultants, not the overall view. You aren't seeing the enterprises who have sufficient in-house skills to use no-code effectively on their own. They certainly exist.

taeric 3y ago
I'd be curious to hear what those skills are. My gut is you are correct that they exist, but I'm struggling to understand where the disconnect is on so many places I've been. I'm convinced it is "the way" for many things, all told. Mario Maker and things like that are great examples. If what you are making is a Mario like game, you will almost certainly do better playing with that than you would making your own. Same for visual things. I want to like parametric modeling in the likes of OpenSCAD. However, it is are far and away inferior to traditional CAD tools. And it isn't like those do not have parametric capabilities.

logicalmonster 3y ago

I'm not suggesting OP is wrong, but here's 2 small counterpoints. 1) Where is the data (beyond an anecdote) that shows that no-code solutions generally cost 10x more to build? 2) Putting aside these initial implementation costs, do these no-code solutions have other advantages, such as being less costly to maintain, or being far quicker to customize when needs change? There's always some tradeoffs to take into account.

specialist 3y ago
> do these no-code solutions have other advantages No. I have some experience with low-code work flow -esque tools. BizTalk, Talend, SeeBeyond ICAN / Sun Java CAPS, a few others. Categorically, they're an angry 800lb gorilla sitting between you and your work. Their sweet spot is demos for PHBs. Their purpose is to create a lifelong dependence on the consultants proposing these tools. All of the many legit criticisms (leaky abstractions, poor version control) boil down to this one simple truth: At some point the tool won't suffice and you'll have to drop down to code. Which is likely buried under layers of XML obfuscations. Now you have two problems. (h/t JWZ) So what started as a very simple data processing problem {1}, requiring nothing more than some scripts, has now metastasized into: schema compilers; magical error handling; wrangling XML thru ancient textarea forms; fighting yet another framework/API {2}; debugging thru trace statements and grepping logs; some almighty backing database which no one can access; endless fruitless conversations with nominal DBAs about indices and workloads (and "has anyone done a backup?"). On the bright side, some days you can actually manage to fulfill a customer's use case. -- {1} Input - Munge - Output. Cut & paste strings, some light type coercion, modest value mapping. {2} Another greenfield half-baked zero-validated notion of the world's greatest workflow engine ever, belched forward over one long kids-free weekend by an esteemed principle senior software solutions architect (they wrote a book!) who is now deep into their mid-life crisis and way past burnt out, with a code base now maintained by a fearless project manager (and aspirational future VP of product) snagged from some travel related startup, with the mandate to deliver some results, so then reluctantly brought in a team of agile mercs, just to appease the over eager execs, who are trying to fast bulk up to legitimize their efforts to secure another round of funding.
- 3y ago

spcebar 3y ago

I've seen no-code tools that are so complex and poorly designed that they require specialized teams to operate. We've worked with a number of clients that use a certain software, all of whom, despite having been sold on the simplicity and ease of the tool, retain a company that specializes in configuring the tool. Then again, no-code is a pretty broad umbrella, and I've seen tools that enable users to help themselves help themselves in meaningful ways that save them money and us spending our time on miniscule adjustments.

sharemywin 3y ago
this kind of reminds me of those integration platforms. where you need specialized training and consultants to map data.
- koromak 3y ago
  Oh god. I had to "learn" a Shopify-to-NetSuite integration tool, which effectively means learn shopify, learn Netsuite, and then learn this shitty tool which does nothing but connect inputs and outputs with zero explanation. Miserable. 2 years later I'm at a different company and I still get emergency phone calls because no one understands this thing. Code would have taken longer to build, but at least new developers would be willing to maintain it.
  - jimnotgym 3y ago
    I had a team that coded integrations into Netsuite and used an integration platform for Shopify and others You always need to learn Shopify and learn Netsuite. More so if you are coding it. We often had to pull developers back from other projects because one counter party or another changed something and nobody could work out how to change it. We always ended up with scripting in Netsuite even with the integration platforms. There was no winning either way, but we went with integration platforms by choice because of maintainability and expertise from the platform engineers.
  - spcebar 3y ago
    I suspect we're all talking about the same tool.

atonse 3y ago

To me (even though I am a developer and have done little no-code, but have integrated with many Salesforce and Power Apps apps) the real promise of the bigger platforms like Salesforce or Power Apps is the baseline quality is higher than what those same developers would've built from scratch. Even just stuff around security, user management, login best practices, etc. What you get out of the box is better than 75% of teams would build custom. Sure they can be misconfigured after that. But you do get a bunch of (infrastructure-related) stuff out of the box before you get to how a dev can mess up the object design or make the UI insanely cumbersome.

yobbo 3y ago

The benefit, in the eyes of leadership, might be that the consultants/devs are easier to replace which reduces risk.

lupire 3y ago
Why is a no code dev easier to replace than a code dev?
- rapfaria 3y ago
  No code devs surely won't take that much time to deliver something as code devs. No code devs surely don't need that much expertise (it's no code), so surely they are not as expensive as code devs. Earlier this week Jack from backoffice asked me if there are any positions in my eng team. I wonder if he can learn no code in a week, since it surely won't be that complex...

ebiester 3y ago

Does this include every excel spreadsheet application we have today? That is what low code should be replacing.

darkhorse13 3y ago
Why? Excel is incredibly powerful. Most no-code platforms can't do much compared to Excel.
- fragmede 3y ago
  Because it doesn't version control well, it's hard to introspect, the data and code are all jumbled together. Emailing xls files around is functional, sure, but the software developer in me dies a little bit every time I do_final(1).xls I don't know that a hypothetical no-code tool does any better at any of those, but Excel, powerful as it is, has some real issues.
  - lupire 3y ago
    Excel has had version control for years, via 365. https://support.microsoft.com/en-us/office/view-previous-versions-of-office-files-5c1e076f-a9c9-41b8-8ace-f77b9642e2c2 https://support.microsoft.com/en-us/office/view-previous-ver...
    - isbvhodnvemrwvn 3y ago
      That's backup with point in time restore rather than version control. It can't track semantic meaning of changes.
    - fragmede 3y ago
      That version control isn't very good. It dumps me into a snapshot of that time, of both the data and the formulae together. Useful to see how things were 2 years ago, using 2 year old data, but in order to take that data, but use the modern formulae against it is a chore of hoping I get the copy and paste right. There is also no documentation on why those formulae were chosen. Compared to git log -p, to see the changes in all the places there are instead of hoping I click on the right cell and catch all the changes.

hooverd 3y ago

Numbers? Gives my experience with no-code solutions that aren't spreadsheets, I wouldn't be surprised.

LorenPechtel 3y ago

It still takes the same skills whether you have "code" or not.

jenkstom 3y ago
This is exactly right. And codeless tends to not have the capability of dealing with complexity very well, meaning architecture is brittle.

hcks 3y ago

Ok but this very strong statement has literally nothing backing it

malfist 3y ago
Source: Trust me bro.
- fkyoureadthedoc 3y ago
  Nobody can talk about their life and experience without a supporting meta-analysis of a hundred studies

chaos_emergent 3y ago

enterprises who build no-code solutions tend to spend 10x more than coded ones, but in aggregate, all enterprises do not spend 10x more on no-code solutions than they do on coded ones.

lupire 3y ago

Numerical claim with no evidence. Thanks, OP.

didip 3y ago

I think the perfect no-code tools has yet to appear. Ideally, no-code tools should generate a good code (using LLM) into a git repo complete with the following: - good code structure. - test code. - database migration code. - CI/CD code. - Docker packaging code. - Basic Kubernetes/Helm code. This way, an actual engineer can take it and roll with it if you stopped using the code generator platform.

WorldMaker 3y ago
PowerApps will "eject" that way, but "good code structure" and "test code" don't guarantee in turn "good code", just as any other "auto-scaffolder" ever isn't a guarantee of quality and may just be generating tons of boilerplate that look productive more than actually are productive.

rchaud 3y ago

At enterprise level, it can be easier to get budget approval for consultants than hire a full-time employee to do the same thing. It's usually also easier to terminate a consulting agreement than an employment contract. Finally, consultants sometimes have better contacts for getting priority support for platforms like MS Dynamics and Salesforce that have large numbers of programmers building apps on top of them. 'No-code' is a blanket term that includes an enormous breadth of software. Zapier does some pretty impressive no-code automations across apps and it's pricing is usage-based. MS Power Apps is just one player in that market. A lot of no-code is also just adding view layers to databases so people can build business dashboards without needing direct access to a SQL environment. It may be easier to have consultants build out such workflows than attempt to hire the right people internally.

RankingMember 3y ago

Where is this 10x number in the headline coming from? Can you link some data?

no_wizard 3y ago
I think we may be in anecdotal territory. Though my own observation is that enterprises will spend alot of money on low / no code solutions that are a pain to maintain at scale (the worst of it is when they churn APIs and/or integrations). There's room for solutions like that, but expectations need to be managed better.
officialchicken 3y ago
Let me try to supply some hype ... my current no-code solution saved my team negative 0x; it was started and completed in 1 day, followed by 777 days of edits, debugging, and improvements (so far) reducing our OpEx 1568% since "code complete". To get around the 27.9% uptime, we removed that metric. The supplier (us) spent exactly $162 on the entire design and development (thanks to Fiverr). Our estimated ARR should be approaching 167 trillion dollars in 2040. The TCO is only $59,883 (ongoing AWS fees) and growing at an astounding 182% CAGR. And our ROI has already paid us back - just don't look behind the curtains or expect it to pass audit.

hospitalJail 3y ago

PowerAutomate is M$ sales people taking our purchasing teams out. I now have enough experience that I will outspoken warn people at my company, even if it means calling out tech debt that is uncomfortable.

frugalmail 3y ago

This was my experience with Alteryx and Informatica vs. Scala/Python/Shell + Airflow as well.

threeseed 3y ago
My experience is that Alteryx and Informatica serve useful purposes. And in fact they often don't even overlap with Spark/Airflow e.g. Alteryx is great for running on a local laptop processing Excel files.

cm2012 3y ago

As a marketer, let me tell you how things go: 1) You have a marketing project that is speculative (as all marketing is). Say it's an API hookup and some automation between some tools. 2) You submit your project for prioritization by the dev department. 3) It gets done 9 months later. The specs are wrong because there were so many layers between the marketer and developer and the developer has no context for the project. You submit edits which get prioritized and takes another few months. OR You get Zapier approved by security once. Then for every project like this you fiddle with it until it does what you want. Total time: A couple of weeks. No code removes friction from the org. Developer time is always the biggest bottleneck at any org I've worked with. Anything that let's you get around it is worth its weight in gold.

dgellow 3y ago
> No code removes friction from the org. That’s so true. It’s not to build quickly, it’s to keep the agency within the non-engineering department.
- WWLink 3y ago
  To me that sounds like the argument from a business department in an engineering org. The solution is for your department to hire its own software developer(s). I'd say the same thing for an organization that is heavily business-oriented and has an engineering department that gets kneecapped by the business-team-focused IT department that can't appropriately support the engineering department.
  - bell-cot 3y ago
    > The solution is for your department to hire its own software developer(s). Vs. the reality, in most large org's - that plan gets shot down faster than non-union electrical contractors in New York City.
  - sfink 3y ago
    And people wonder why organizations have such high headcounts...

timcavel 3y ago

[dead]

bilekas 3y ago

> This is from my experience as a consultant in many enterprises over last 3yrs I get the feeling there might be some survivor bias here. You as a consultant will always be placed in front of projects that require a consultant. So those project types with wild budgets and nonsense structures and implementations are most of what you will see.

tstrimple 3y ago
There is definitely a bias here, but it's a bias towards very large companies. They almost all have this exact same problem. The company I work for consults with something like 2/3rds of the Fortune 500 companies and almost every one of them suffer from these challenges. Of the companies I've worked with who seem to have their shit together and are on top of everything, almost every one of them had fewer than 100 employees. That type of company, by necessity, is run very differently than a company with 100k+ employees. It may be helpful to not think of a company with 100k employees as one company. It's really multiple large companies with competing priorities who still want to be able to realize efficiencies of scale across the board. You've got different cultures and different processes across all of them. Yet you don't want each of them to be adopting "the cloud" in wildly different ways. You need consistence in governance and guard rails which cut across all of the orgs or your costs and complexity are going to be all over the place. You'll have orgs spinning up their resources in different cloud vendors which will greatly hurt your opportunities for the cost savings which come from real volume.

th3h4mm3r 3y ago

Hi, I'm implementing a new lowcode solution based on ionic and nodered and a "custom" part really big to implement ui and interaction with the backend. Imo this solutions could works if the framework (intended as I described in the first part) is focused on a little problem context (for example: developing application for warehouse terminal or a system to register datas by customizable forms and so on). Without a focus on a single problem is really difficult to create a versatile framework that mantains simplicity as main charateristic.

lifeisstillgood 3y ago

The "business/tech" divide is a terrible divide, but we seem stuck with it. So maybe make the most of it - hire and train software developers on "the way the org develops and runs software". Then embed them in business areas - literally sitting next to people building what is needed right now.

wmidwestranger 3y ago

Sounds very similar to the complexity increase described in The Mythical Man Month. The author describes how the complexity increases as a system expands in a greater than linear, and expected, fashion. So, a simple script might cost one. Adding configuration costs 3. A framework for solving similar problems might cost 9, and a platform for frameworks probably costs an unexpected large amount, like 27. I've mostly seen this pop-up along with Xeno's paradox. A rewrite of a legacy system is undertaken and the planners completely discount all the blood, sweat, and tears that went into the original. Every problem is considered "solved" and using newer tech is seen as a silver bullet. The cost is severely underestimated and the effort is way beyond initial estimates.

simonbarker87 3y ago

No code is great for an experiment - I’ll throw together a zap or two to test something and if it sticks I’ll then port it to code and properly integrate it into the system. It’s not a case of “redoing all the work” it’s about helping to know we are doing the right work.

mvdl 3y ago

No code is simply somebody else's code.

sexy_seedbox 3y ago
Serverless is simply somebody else's server.

BLanen 3y ago

Any truly capable no code development environment will (d)evolve into a shitty visual programming language without the tooling you expect from a modern language.

Buttons840 3y ago
I wonder if it being "visual" makes business owners more likely to look at the logic and realize "wow, this is a mess, let's simplify this". Whereas, complicated logic in code is seen as "just a bunch of code" and non-coders will never look at it or attempt to understand it. I store my candy in the basement, it's a life-hack to help me control myself. Maybe businesses would also benefit from the "hack" of requiring business logic to be visually represented, and thus force themselves to keep things simple. I have this fantasy where the project owner runs the code though a tool which faithfully translates it to a visual language, and then promptly gives me a large severance. On my way out he asks me what the incomprehensible tangle on his screen is, and I laugh on my way out the door.

ltbarcly3 3y ago

No code: hire people with no practice reasoning about how to create software to use clumsy tools because you can pay them 1/2 as a programmer per hour. Code: hire a professional to use the best tools that exist to do the thing they are highly practiced at. What could go wrong? I was thinking of hiring an electrician the other day, but for half as much in labor costs (per hour) I was able to find someone with no clue what they were doing to just run a bunch of extension cords.

jrockway 3y ago

I think the solution that you're paying for here is the burstable capacity. Dev teams often end up with a backlog of 100 internal requests, and all of them are "the highest priority", well, if you have 1 thing doer and 100 things to do, they can't all be processed at once. But if you get 100 consultants, then they can do all 100 high priority items in parallel. The other edge of this sword, though, is that they want real money. Your manager is going to have to approve an expense report. Suddenly, it's actually possible to break the list down into actually high enough priority to pay 10x for, and just "nice to have". That said, I'm not sure it really helps. The infrastructure to allow these consultants to be productive is going to be expensive; the dev team has to provide a safe API for these integrations, and an API "that could be used for anything" is harder to design than writing code for a particular use case. (Then again, I bet a lot of these teams get a request like "can you just give us a read only replica of your database" and get "sure" back. It will be 1 year before they realize they just lost their SOC2 compliance and their website has been lying this whole time.)

deleted 3y ago

[deleted]

cstrahan 3y ago

Anecdote: early in my career, I worked on a dev team that feared software development. They tried to push as much logic as possible into Microsoft SQL Server stored procedures (the average length was around 10 pages). Look at all the code that wasn’t written (because SQL doesn’t count), and less code means less bugs! Where stored procedures wouldn’t do, they put these of the logic into SQL Server Integration Services, which provided a visual programming environment — think Scratch but for visually connecting ETL pipelines. But, invariably, the existing components wouldn’t suffice, so they’d stuff 100s of pages of C# into these components, which would be hidden away behind a little “code block” rectangle in the SSIS flow-diagram-esque interface. Zero code reuse, no way to run unit tests, no strong typing (beyond primitive types mapped 1-to-1 with the underlying SQL queries), no codification of invariants/preconditions/etc. But hey, that C# code hidden away doesn’t count as code, so look at all the code we avoided! And SSIS is from Microsoft, so by using something they bless then we must be on the right track! What’s that you said? Should we consider if this particular tool is appropriate for our particular needs? No way! If SSIS wasn’t the optimal tool for all problems, why would Microsoft develop and market this product?! Anyway. I think the trap people fall into is this: Critical thinking is tiring, and many people are lazy. Putting such people in a position that they must actually weigh the merits of multiple options is a sure fire way to become deeply resented. Also, critical thinking makes you responsible for the consequences of your choices, whereas appealing to authority absolves you of any and all responsibility (the old saying “no one was ever fired for buying IBM”). So many attempt to reduce the amount code as much as possible. But the problem is that many worthwhile endeavors are inherently difficult, and require real, hard, critical thought to arrive at a solution, and for such things code often happens to be the best medium for reifying those thoughts into software solutions. Consequently, countless companies will choose to jump through no-code hoops, and unsurprisingly suffer the consequences. They won’t learn from it though: instead, those responsible will deflect with excuses like “well Zapier is the issue, you see”, or “imagine how much longer it would have taken if we actually coded the solution!”, or “that’s just the nature of software/tech”, etc.

threeseed 3y ago

This is the worst type of post. No data. No facts. Clickbait topic that reinforces HN preconceived biases. The fact that no-code tools are recommended so heavily should indicate that it is useful for at least some use cases.

letsdothisagain 3y ago
How dare you deny their lived experience? The OP clearly stated that it's BAD. As someone who runs a low code dev shop (I have a low/high mix of frameworks), I've already started reflecting on my BAD behaviour. I will repent and jettison all of my cruds, and web forms, and other dumb little things that provide so much value to my clients.
- civilitty 3y ago
  The smiting will continue until the code quality improves.
- fkyoureadthedoc 3y ago
  Assuming "As someone who runs a low code dev shop" is true, why the tone when you're clearly more biased than OP just on the other side of the fence? If anything you've reinforced their point, the fact that a whole ass "dev shop" exists to support low-code just supports their argument.
sundarurfriend 3y ago
> Clickbait topic that reinforces HN preconceived biases. Oh, I read the post completely as "no-code is what's actually in demand, stop bashing it and start building". I had to go back and re-read it after your comment to see what you mean.
OkayPhysicist 3y ago
"Recommended so heavily" by the suits making commission selling the things, maybe.

neeleshs 3y ago

One unsaid thing - developer salaries.Far too often (myself included) we ignore that our own salaries are a cost

trunnell 3y ago

IME a huge part of the cost of development (regardless of code/no-code tool choice) is the time spent gathering requirements and continuously validating them. When the user and developer are the same people, the cost of finding the requirements can sometimes be nearly zero. In this case, that person will themselves choose the best tool for them. And the development cost will be very cheap -- for example, think of a short script you wrote to do something just for you. But when the user and developer are different people, much care should be taken to avoid cost explosion. To the outside this can look like "coding is expensive!" which is kinda true, but really it's the requirements discovery that dominates the cost. People don't understand each other perfectly, can sometimes talk past each other, etc. Iterative development's purpose is to mitigate the problem of building for the wrong requirements. No-code tools can unblock "developers" who own the requirements but don't have programming skills. That might make those projects very cheap. Or it could do the opposite: if the non-programmers don't know think carefully about what they're building, then they might end up spending just as much time as programmers would have as they iterate towards a complete solution.

quickthrower2 3y ago
The issue is “requirements”. With a nocode system a person can create something that solves their immediate problem. Which is usually to get something done quickly that their boss wants so they don’t get fired (sorry too honest?). But things built that way usually wont end up being efficient ir maintainable. Everyone self servicing bespoke “code like” setups leads to a mess. There is a level of polish before self service makes sense to me. For example using dropbox is OK. Making a dropbox like thing in Bubble is probably bad!

reilly3000 3y ago

No-code systems can rapidly become indecipherable by the time they are deployed to do serious work. You would think it’s a matter of wiring up some event source block to some action block. Reality looks more like 15 steps to transform a string properly, held together by bubblegum and nigh impossible to test end to end. Data pollution happens all the time. Hold my beer, I’m going to no-code live!

great_psy 3y ago

I only have one experience with no-code and that is trying to make something in the Shortcuts app for iPhone. I tried to make a password generator. Pretty simple I thought, just have a list of words, and pick 5 words out of the list, concatenate them and spit them out. I’m python you can probably do it in one line. I spent about 30 minutes trying to get this to work. The interface as well as the drag/drop way of doing it was a huge barrier. I’m sure this can be improved, or maybe it’s not aimed at this type of project but so far not impressed by no code solutions.

outside1234 3y ago

I am shocked SHOCKED to hear this!

themerone 3y ago

I'm forced to use an issue tracker built on a low code platform. The nicest thing I can say about it is that it is the worst software I've ever used.

oooyay 3y ago

I use a low code solution on my home network to prototype applications that I don't know if I'm ready to commit to yet (Shout out to Budibase). After a certain point the application becomes too cumbersome and complex to maintain (or slow), which is when it needs real code put to it. I've had pretty good success with that pattern thus far. I think enterprises could probably do the same thing. There were people who said low-code would replace the need for developers and people believed them. That will never be the case. There are people who said it's worthless junk, and the live usecases available today show that's not the case either. As in most things, the truth is somewhere in the middle of those two ideas. That's to say, few things in the world are as binary as bits.

wonderwonder 3y ago

OP is right and wrong. I am currently a technical lead on a highly complex build that has been in development for a couple years now. A good chunk is in production, tens of millions of complicated 'product' is moved through the system every year. This will eventually scale to billions. Not making that number up, its the existing volume that will be moved over from the myriad of legacy systems we currently use as we build additional functionality. We are using lots of consultants and they are very expensive. They also don't build with the same quality as our in house teams. I can build any app I could during my full stack days quicker with no code. Obviously there are some limits but I have not had to deal with them and they are edge cases in the day to day of a web developer. It definitely helps to know how to build software and there is a world of difference between the work produced with the tool by a developer and someone that has not coded before. I went into it expecting to very much dislike it and that it would only allow for toy development. It blew me away. A team of devs that know how to architect software and this is the key; plan well, can crush projects with this. With that said, if you don't plan and just go in and start building its incredibly easy to build a mess of non maintainable spaghetti no code.

dgudkov 3y ago

Psst, don't tell the author that enterprises spend 10x for high-code solutions too by hiring external consultants.

zubairq 3y ago

Reminds me of the 1990s. The amount of work for consultants to build business solutions with no code or low code tools was staggering, including Borland Delphi, Visual Basic, Excel, MS Access, SqlWindows, Powerbuilder, and many others. I don't know if I agree with that they cost "3-10x more" than building the solution with code, as often these projects would never have been started if they were built with normal code, as the decision process is totally different in most organisations (eg: related to skills and maintaining the software)

nvm0n2 3y ago
Delphi/VB weren't low code! They were full blown languages with IDEs.

exabrial 3y ago

The answer is pretty obvious why though... CEOs look at devs making 6-digit salaries, screwing around with Node.js modules all day long on an endless trendmill/treadmill of "upgrades", new frameworks, UI rewrites while absolutely adding 0 new value. At the end of the day, all the website needed to do was take orders... which it did back in 1998, but now it's a million times more expensive. As much as a turd nugget as Larry Ellison of Oracle is, he absolutely nailed it when he said "The computer industry is the only industry that is more fashion-driven than women’s fashion." If a technology comes along that promises to offboard an enterprise from the endless hype train, it's a pretty easy to see why many would jump for it. That being said, I agree with the premise: no code solutions just shift the complexity elsewhere; code solutions are the right answer, but an entire generation of programmers was never taught to build things that last.

parentheses 3y ago

As a person who uses low/no code platforms to ship real products I fully disagree with this. Low code and no code platforms can do a lot to make implementing back office functions easier. It enables things that you'd deprioritize without these tools. That said, they also need to be managed like software: versioning, beta releases, risk mitigation, tech debt trade offs. While there are things that can go wrong with these tools, they do strictly make things easier rather than harder.

clncy 3y ago

MS PowerApps, PowerAutomate and related offerings are truly awful products. I’ve given them the benefit of the doubt and been burned repeatedly. Don’t tar all no/low code tools with the same brush though. I’ve had good success with Retool, for example.

rangledangle 3y ago

[IT Perspective] In my personal experience, these tools also overreach. Most people I've met in IT (15 years) want to go into Engineering, or at the very least, something MORE technical and code-related. They are hungry and willing, but often overlooked. I have seen many climb out and teach themselves code, build tools for IT and revolutionize the way teams and orgs work. It's a marvel to see someone with drive do what they desire. Fast forward to today. I see IT forcing all members to use a low-code tool. The passion drains from their eyes. I can see the fear of the mounting weight of becoming unemployable. They've shared with me their experiences. The directions they want to go have nothing to do with Low-Code, and the roles and orgs their interviewing with aren't interested in people who build with them. The question "what have you been working on?" is like a death knell. I'm pretty sure a lot of them don't see a future beyond helpdesk because of these tools. My point is, think carefully about who is using this product. You can kill careers with this stuff. I think it's great for business teams who want to "do x in x app when y happens in y app."

diegoop 3y ago

Apart from marketing, I used to work as a MS consultant for many years (10+), focused mainly on creating custom no-code and almost-no-code tools for business, and the investment was usually lower in the short term, with shorter dev times, but in the long run when the company started to use the solution in the day to day, and started needing more specific tools, no-code solutions tend to be way less flexible and end up with dodgy patches to implement functionality that could have been done in a more maintainable if was a more coded solution from the start. To sum up, and on the field I was working on, it's hard for the client to have a clear understanding of the lack of flexibility that will may face in the near future, and usually ends up on hands of the sales people and what the company providing the solution is focused on.