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.

No sympathy as this is entirely a self-inflicted wound.

The problem is that very few people, at each stage, are qualified to be there. Let’s not kid ourselves with pride and self-congratulatory bullshit about how awesome we are. Most people require several layers of abstractions to do their jobs to cover competencies they should know but don’t both in technology and marketing.

The reason this occurs is because there is no baseline of competence in software, so everything becomes wildly subjective and therefore biased. To solve for that business imposes tools to make things easier, but really it’s to commoditize candidate selection. That eliminates some amount of training costs up front but instead requires a larger labor pool with lower product flexibility. More people of lower competence with far less ability to pivot as requirements change and everything takes longer.

No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.

> No code is just an extension of this problem because it still requires developers, internal to your company, to maintain and extend the no code solution under the same limitations as before.

I don't want to dismiss this point, because it's real. But there is an alternative.

I've been brought into these talks with other departments before, and I evaluate the tool from an engineering perspective. If they want to use a true no-code solution, we don't block it but raise to the director level that we will under no circumstances support the use of the tool - we are developers by trade and that's what we're paid for, so they are responsible for everything to do with it and bear all responsibility if it fails to adapt.

If it's low code and has an API, we generally much prefer that because it means we can actually deploy and properly maintain the code that might be needed to support integration with it.

We don't copy and paste fucking code and we don't drag around UI elements with if-else statements - it's simply not our profession. You wouldn't ask a carpenter to assemble IKEA furniture. It's a waste of money and time.

So yes, the solutions might "need" a developer, but no sane director would allocate one. It makes no sense.

I work for a low code vendor, and use that ikea example quite a lot. Fact is, most people can’t or won’t afford a carpenter but would rather save time and money by using ikea furniture. I believe there’s a market for ikea software and I believe that there are many organizations that would rather spend money on ikea software than on expensive, slow and scarce software carpenters. And we’re software engineers building the low code platform, so we understand the value of version control, testing, automated deployments and apis…

It's easy to describe this as self-inflicted when you don't understand how large orgs work and have never had to consider how a security team deals with a large org, each piece wanting their own version (or multiple versions) of this solution.

Qualification isn't the issue because we (the US, US tech, SF/NY, etc.) have a lot of qualified talent, both in eng and elsewhere. The issue you describe with competence IS an issue but not for this. Your final sentence is correct but not right.

Basically, you're right and you're wrong and I should probably write something longer form but won't get to it for months. I'll give you an upvote in lieu of that for making me think deeper about the topic.

And after re-reading my first sentence, I apologize for suggesting you don't understand how large orgs work. That wasn't fair and I don't know your background. I'm gonna leave the post unedited for honesty's sake.

> The reason this occurs is because there is no baseline of competence in software

Funny, I actually feel like it’s the opposite - most orgs I’ve worked in have an ultra high bar in specific areas to pass an interview, leaving otherwise proven capable devs who can perform all sorts of projects like this from being hired. It’s like we demand all engineers be doctors to insert an IV.

What gets things done is smaller teams with fewer dependencies. Large teams of highly competent engineers tend to produce massive project scales.

That sounds like something subjective and not a baseline. A baseline is a uniform standard minimal acceptance criteria. Imagine the employer is irrelevant because the technical qualifications are always the same uniform thing, which would be a baseline. It could be specific to technology platform, such as OS specific, Java, web, and so forth so long as it is focused on the technology and not created by a single specific employer.

I never really got this until I was talking to a scientist in our organization and she was bemoaning the fact that it was taking her team hours to do some basic analysis of files that our instrument exported.

"So why don't you make a request for Software to add that data to the file? We could do it easily enough."

"I did! but they keep telling me it's not high enough priority so it gets pushed out to 'the next release' every time"

"OK, I'll write you an offline tool to process the data."

Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature. And this was taking a biochemist on average 3 hours every day to do by hand!

> Took me an afternoon to write a simple C# tool to ingest a number of files and spit out the data that she needed. She had been waiting over a year for my software team to get the go-ahead to do it as a built-in feature.

The counter to this is that this tool now has no support (which may be fine depending on the tool).

I remember my first job which was 30% SW and 70% other engineering. We wrote a few tools to automate stuff that our customers used.

One of our customers came to my manager and told us he had a tool we wrote over 5 years prior. It was a small Perl script. Their data source had changed formatting a bit and now the script no longer worked. They wanted us to update the script. Several hours were spent between the two teams arguing. My manager did not want to own it. He said he had no record of it, and none of the people on his team had any memory of it. We did not own it. They kept insisting "One of the engineers in your team (who had since left the company) wrote it, so you own it!"

I pointed out to the coworker that the request was so trivial we could have solved it in under an hour, and the company had lost more money by arguing. The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost."

Over the years, I've realized how right he is.

I do occasionally write simple scripts to help our customers, but management always makes it clear to them that this is an unsupported prototype, and the customer needs to maintain it.

And that's a perfectly valid rebuttal. Over time, she occasionally asked for more features, and I obliged as time permitted. The requests were always reasonable, and I checked the source into our generic "Tools" repository in case someone else ever took it over.

The bigger problem I saw was the shortsightedness of the organization. The software group had a history of writing small test tools for other groups, but no one ever considered listening to what she was asking for and checking if there was another way of getting the data besides changing the Product itself. It's always easier to just say No, even when there's a clear benefit to someone else.

Just bill for it, support and all. Make the customer say no. Or if they're willing to pay then great.

It's terrible customer support for the company to give them something one day and then deny all responsibility another day.

Even if the original team shouldn't have done it, they already did and it was never the customers fault.

The manager was not right at all, and this comes from no newbie who just hasn't been around that block yet.

> Just bill for it, support and all. Make the customer say no. Or if they're willing to pay then great.

This is probably the best solution. The organization still has to be prepared that business users will make their own tools, though. And they will frequently get things wrong, because they’re not developers.

They came back to you once after 5 years, what makes you think it would get worse over time?

And if by worse, it’s one hour every year, the argument is still a worse trade off for both time and customer & employee morale.

"Past outcomes are not indicative of future results" Just because they came back after 5 years doesn't mean it will be 5 years before they come back again. It was, in fact, quite unpredictable. We didn't want to be on the hook every time their data source changed the format of the data. If this work is so important, they need to work with the team pumping out the data to have it standardized and stable.

This was in an org that was sorely lacking programming talent, and management clearly did not want to hire SW engineers. There was always a lot more work than there were engineers for, so it was a continuous battle of demarcating boundaries. If you start doing SW favors, everyone will want it from you, and will push the upper managers to force you (or your team) to do it. None of this will matter for promotions, because SW was secondary to our jobs. Without a hard stance, you'll drown.

As another commenter said, it was an incentives problem. Right or wrong, good or bad, helping people with small scripts was not something that would ever be rewarded.

It was also a matter of principle: If you do someone a favor, and they come back to you with an attitude and insist you owe them because you did them a favor, you stop doing those favors for them. That was something I would see often in that org (even outside of SW work): If you do work for someone, they expect you to own it.

Overall, the culture was poor. But I've found elements of it in most jobs.

Judging from the comments, it's evident I wasn't clear enough: When I said "our customer", I did not mean an external customer, but an internal team. We were a service/expertise department that helped various teams in the company with our expertise (and the expertise was not software). This was all informal - there was no monetary accounting/SLAs for our services.

> As another commenter said, it was an incentives problem. Right or wrong, good or bad, helping people with small scripts was not something that would ever be rewarded.

I agree with you here. The long queues for internal dev support is indicative of high demand for that support. If the organization can’t or won’t staff properly to provide that support, both the users AND the devs are forced to make tough choices.

So the devs say “No” to requests (or it takes an inordinately long time to get done), and so the business users make their own tools.

And the cycle continues…

The https://en.wikipedia.org/wiki/Jevons_paradox

As soon as you make something easier to optimize, you'll end up spending more than before.

Sometimes you create a lot of value in the process, so it can be a good thing. But its costs has to be taken into account.

I think some teams could do really well to have an embedded developer- someone who can understand both fields decently enough.

I've been in that role. It's utterly thankless. You will experience every way that the devs and non-devs can't work together. The devs will treat you like a scab. You'll discover all of the non-technical reasons why it's hard to be a dev, without being paid like one.

Today, my rule is that I only code for myself, and share my code with others who are also good coders. I'll use code to produce a result and share the result. This also lets me off the hook from all sorts of things like UI's, installers, etc.

Anybody who's a good enough dev to do it for money, and can stand doing it, should be.

Edit: Thinking about it more, it's not that we can't work together as people but that the organizational culture makes it hard.

While I agree in principal, speaking as someone who's been that person it creates a lot of stress when it's just one person. You never get a break from enhancing or fixing and maintaining the tools that the rest of the team is using, and probably lose opportunities in your "other" skills. You'll probably get no support from the actual dev groups in the company, never get funding to hire a contractor (which almost never works out anyway), potentially end up stuck career wise because if the tools are really useful your manager isn't gonna want to lose you to a promotion.

A small "tools" team shared across some related disciplines under common leadership would be more ideal in my experience, but normally it's either beg for the real dev teams scraps or go rogue.

I like using code to solve problems and automate things, but I have no desire to be a full time coder just like I don't have a strong desire to be a people manager.

I’ve been in that role and it’s incredibly rewarding. The satisfaction from delivering something valuable to the sales leaders I partner with when they get something they genuinely appreciate trumps any commit dashboard.

It’s all a power dynamic.

Saying no is a power move that gives you street cred in the organization. Helping people is for the meek.

Maybe, more likely an issue of incentives.

Manager is not incentivized to do X? Then forget it. Not my job, not my problem.

What's the counter? You could have effectively no support either way, only this way you at least have a working (perl) script

The long argument is also pretty flawed without any cost estimates, like, maybe they'd come to your every 5 years for a hour worth of work, but then looking up history and arguing about it takes longer

Not to mention this discounts the human cost. Marketers who have to wait 9 months to get anything done, and are forbidden from doing work themselves, realize the company doesn't actually care about accomplishing things and the passion dies. Why bother trying to come up with new and innovative things to test that could move the needle if its a kafkaesque nightmare every time?

I guess there's a different though - if its for a customer then its potentially something that you should be charging for. If the "customer" is actually another department in your company and the automation helps then the company should have software devs allocated to internal tools - they'll probably find a lot more places to smooth things out if they're allowed to look.

> The counter was "If we fix it, they'll keep coming back to us and in the long run more money would be lost."

And this is why people develop their own tools.

Then the same people that wouldn’t help say, “Why did you build this monstrosity it Excel/Access/$OtherNoCodeTool ?!”

> Then the same people that wouldn’t help say, “Why did you build this monstrosity it Excel/Access/$OtherNoCodeTool ?!”

Not me :-) If Excel solves your problem, go for it. If it becomes a monstrosity and a bottleneck, then their management needs to allocate proper resources (i.e. hire their own devs). And they often do. The ones we see are the leftovers, where the ROI for a highly paid dev doesn't exist, so it's more economical to stick with the monstrosity.

Another example of: you can’t manage what you can’t measure, but be careful what you measure because that’s what you get. Alternately: measuring cost is easy, measuring value is hard. So we don’t hire another dev because that’s expensive, whereas I don’t see all the time wasted by the people I already employ. Having said all that, it’s a hard problem, and I’m not sure what general advice can be applied.

Fantastic insights here.

I’d add that another invisible cost(?) is that business users are going to develop their own tools no matter what. Why? Because they need them to do their jobs! So development is happening, whether it’s done by people with the title “developer” or not.

This is a great example, thanks for sharing.

Too many folks on HN claim that normal companies are close to as efficient as they can be. It's nowhere near close, more like hundred dollar bills lying on the floor everywhere in nearly every office.

I had the opposite experience.

At a previous company, one dev spent about 2-3 hours every single day to download PDFs with bank reports and then manually doing the conciliation.

I thought this was ridiculous. One afternoon I made a quick desktop app where he could drop the PDFs and get some JSONs back with all the data. The idea was that he then could semi automate the concilition with those JSONs.

Years later I left that company and he still was wasting all that time doing manual conciliation.

That sounds like a major skill or motivation issue.

I wouldn't want a "dev" who spent 2-3 hours a day doing something like this manually working with me.

Yep, adoption is another major issue. I'm shocked at the number of people who continue wasting hours because they don't don't want to learn the newer faster way.

It’s learned helplessness. They learned that doing the job faster is not only reward-less but only gets them more work.

Having been on the "actually has to deal with the aftermath of investing in no-code" that is when the cost comes in. Out of the literally dozen or so places I've worked and the half of those that went heavy on low code, it has never worked. The complexity becomes too great after a few months of "wins" and the system falls over on itself because the people using low code need increasingly complex things. But I assume as a marketer once you've finished your sale you move on to the next one. Because that what they all did.

The trick is to use the no code implementation to learn what you need to build from scratch. Don't think of it as expensive time to redo - think of it as valuable work finding out what your org actually needed. I'm sure you know that people don't even know what they need when they send developers their brief half the time.

It's like excel. Yes excel is used for all sorts of messy things its not ideal for, and would be better built by a programmer. But the excel file teaches the developer what their co workers actually need the product to do. It's not wasted time, it's invaluable.

That's a good observation but falls apart if actual developers have to maintain the Rube-Goldberg app created by well-meaning "Citizen Developers" (© Acme No-Code Corp) using a framework which is only intended for prototypes but not fit for purpose beyond that.

Of course, that's a management issue - but managers who are easily taken in by consultancy sweet talk about the power of these frameworks are not always the most likely to understand the problems they cause or have the wisdom or resources to clean up afterwards by doing what you suggest.

We can't design tools which are incompetent-manager-proof. There are companies with incompetent management having no clue about software development, but business selection should eventually sort them out.

The most successful projects I have been on started with a smart manager, admin, engineer or other non-programmer who used Excel, FileMaker, FrontPage or the like. Using the tools they know defined their real scope of work.

Projects that start at an empty white board are much harder, which scope creep and higher failure rates

I don't see how it's a valuable work finding out what your org actually needed if the cost compared to a proper programmer [team] is 3x - 10x more.

I mean I get what you're saying but finding one senior dev and onboarding him into the business and using him as a litmus test for most of your ideas as your concept evolves seems like the more sensible and cheaper option.

> I don't see how it's a valuable work finding out what your org actually needed if the cost compared to a proper programmer [team] is 3x - 10x more.

They seem to be talking about building real production systems using no-code.

Building a prototype using no-code can be faster (at least in some cases) than coding them. Esp. if you consider the cross-org coordination needed to get an allocation for dev team.

The most valuable code is the 2 or 3 prototypes you intentionally wrote in python and throw entirely away.

The no-code could easily fall into the same category, as valuable hashing-out process.

Any "proper programmer" should know this.

I as "a proper programmer" also include cost analysis, which was the main argument given by my parent poster.

A rogue marketer at a former company spent weeks with Zapier "trying to improve analytics". They went way too far to the point of saying, "I almost re-built Segment with Zapier".

Needless to say the Rube Goldberg machine of Zaps was impossible to debug and all the data and metrics ended up being wrong for the whole quarter.

We ripped it all out and had to start fresh.

It did a good job, then. How long would it have taken for the marketer to get their project prioritized if it hadn’t already demonstrated value?

Low-code-no-code: it’s all fun and games until it isn’t; and when it isn’t it’s an tire-fire.

>The complexity becomes too great after a few months of "wins" and the system falls over on itself because the people using low code need increasingly complex things. But I assume as a marketer once you've finished your sale you move on to the next one.

And those "few months of wins" can mean millions of dollars in revenue for the business that would have been lost with a longer time to market. If it works, it works. And if it breaks, it can be plugged up until something can replace it. But nothing can replace lost time in a competitive industry.

It also means tens of millions of losses when the data pipeline falls over silently.

My first job out of university was to work on a compliance tool after someone used yahoo finance for exchange rates in a business critical spreadsheet. The losses were large enough to threaten the viability of the company.

Picking pennies in front of steamrolles is a pretty good description of putting no code in production.

This is the reason we have desktop computers. Lotus 123 (and then Excel) enabled ordinary folks automate bits of their jobs.

But it went through a pattern:

- Spreadsheet was created to help do task X

- Spreadsheet grew until task X was entirely contained in the spreadsheet

- New hires were trained to just use the spreadsheet instead of understanding the task

- The person who built the spreadsheet left the department

- The business needed a change in the task, and that meant changing the spreadsheet. But no-one in the department knew how the spreadsheet worked any more.

- The IT department gets a new urgent task to change the spreadsheet to allow for the change in the task. The spreadsheet is a complete mess of spaghetti, evolved over years with no documentation. It will take months of work to untangle it and make the necessary changes (and document it for next time). The developers pitch that they could build a VB app for the task in less time than solving the spreadsheet and that would improve the situation going forward.

- The IT department kicks off a project to build the VB app. Immediately the business department adds a ton of loosely-related requirements because they've always wanted them in the spreadsheet but no-one knew how to add them.

- The project founders under its own bloated weight, scope creep moving it from a couple months out to a year's project.

- Meanwhile the business department works out another way of doing the task

- 18 months later the IT department delivers the app as promised. But it's wildly out of date with what the business department is doing now, so no longer fits the use case it was designed for.

I've seen this happen a few times. It'll be the same with Zapier-derived solutions - in two years you'll have left the organisation and then an API changes and the thing you built falls apart, no-one knows how to fix it, and devs don't want to look at it. Everything is more painful this way. It's worth its weight in gold until suddenly it turns to shit.

This is a great example. Low-code is not the solution to everything, like spreadsheets were not the solution to everything.

With low-code, it really does help if the platform is easily extendible and open source. Also, it's important the IT team owns the low-code platform.

Describes a scenario I was in almost perfectly! :)

There's a reason so many internal corporate applications are built as Excel spreadsheets: there's a lot less friction than having to get a development team involved.

This is so true. Oil & Gas loves data and excel. Everything starts with Excel, and when it outgrows Excel the next step is getting developers to build a better solution. I absolutely think this is the right thing to do.

If ChatGPT can make basic programming eaiser, and Excel ships with easy and excellent Python integration, we will see more Excel.

This had been my experience as well. You can replace the low-code solution with a junior coder in a non-coding role. Creating a shadow-IT solution will be a fraction of the cost and time. The risks are the lack of governance and amateurishness, though. Solution: have vertically integrated agile teams so that developers are in the problem space with experienced peers and governance. Why don't more orgs do this?

We managed to move almost the entire shadow-development from our organization into a low code platform.

It works great. The systems already starts in a usable format, and when they need intervention, they are in a very standard format that is easy to start working with. Besides, today we also send applications back to shadow-development, and they are able to maintain them until something big changes.

Shadow-development isn't very shady around here anymore.

This here. Fully centralized IT is stifling, shadow/decentralized is chaotic. Good structures come from hybrid, matrix-like approaches.

What's the platform? Something you'd recommend?

We use Oracle Apex.

The platform itself is quite good. But it only runs on Oracle, so I'm not sure I recommend it.

We used Oracle Apex for years with loads of complex business applications. If you already have Oracle licenses it's a must-use. It's definitely lo-code rather than no code as you really need a bit of db modelling, sql, and development skill to get it working well. It can also be hard to work out how to customise things but you can get it to do almost anything CRUDy.

Please, yes, this. Both for marketing, and products, and data.

The reason they don't do this is because of politics. People want power, and they do that by gathering larger numbers of reports. The method you're proposing means distributing power among small groups and teams, which can only work when it's done from the very beginning of the company's lifecycle (i.e. people will not have to give up reports/power to make it happen).

As a developer, let me tell you how things go:

1) Marketer puts together something in their no-code tool of choice. For a while it does what is needed and becomes a critical part of the marketing workflow.

2) New requirements come in, maybe it needs to integrate with a new API or database. Marketer is too busy marketing to waste time with all that plumbing. Thankfully there's a department full of people whose literal job is dealing with all this crap: the developers! The no-code project is thrown over the wall and some coders are assigned the task of rat-wrestling with the no-code tool, as well as writing code against their crufty, idiosyncratic API -- code that cannot be tested using their usual testing tools because it must all live within the no-code runtime -- to fill in the gaps in the tool's functionality. Their productivity grinds to a near halt. This becomes their job for months to years because the no-code workflow is Mission Critical, Essential to the Business, and if it breaks or cannot be made to do what is needed billions are at stake.

3) That thing you wanted takes 9 months to complete because now the dev team has all the no-code cruft on top of their work building actual software for the business.

Please, for the love of God, just do us all a favor and learn some Python. When you throw that over the wall for us to maintain, at least we can version-control it, test it, and integrate it with our CI/CD.

Big assumption that! Code written by non-developers, or even by the type of developer who is a tradesman rather than an engineer is usually untestable.

The biggest and only advantage is that you can read it and debug it in order to understand it, which you can’t do if it’s embedded in a mess of lines and boxes with logic hidden several clicks down in a low code platform.

- 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.

To each their own I guess, but it's hard to imagine NASA going to the moon being led by a marketer or business analyst.

Hard things are hard. And hard things done right take time and precision.

Nasa's biggest challenge is marketing. Their funding is dependant on public perception. Nasa does not get more money by having better engineering. Nasa gets more money when congress thinks it will get them more votes with their constituents.

> Nasa does not get more money by having better engineering.

But several catastrophic failures in a short timeframe can ensure it gets no money at all!

My point isn't that Nasa should prioritize hiring good marketing over good engineering. Nasa has good engineers. My point is that their biggest challenge now is their public perception. The general public does not care about Nasa's mission.

SpaceX is far more popular than Nasa. If you stop to think about it, SpaceX is just making travel cheaper and it shouldn't be that interesting. If Nasa can make their mission more fun and interesting, they have a better shot at a larger budget.

there's no need to do them right. and most no-code platform already constrain the solution space brutally anyway, and that's good enough in most of the cases.

> 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.

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.

> 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.

And people wonder why organizations have such high headcounts...

Every time this happens at the companies I’ve worked at, it’s been because the business didn’t think the need was worth prioritizing over the other business needs. I’ve never been in an environment where IT got to make the decisions about what gets prioritized.

If the business doesn’t think something should be prioritized, but a marketer decides that they really want to have it, I’m not sure it’s a great idea to go around what the business has prioritized. Most of the cost in software comes from maintenance of legacy systems. I hope this new no-code solution is something a department has decided to maintain indefinitely! I my experience, after the marketing person quits, the no-code solution gets chucked across the fence to IT, the no-code provider stops supporting their tool, and IT is forced to build a new one as an emergency a few years later because “the business has been using it for years.”

In a healthy org, if something is truly good for the business and will create global gains across the company, it should hop to the top of the priority list. Admittedly, I’m still hunting for this theoretical healthy org, though.

Usually the marketer is stuck between a rock and hard place. A semi-technical marketer will report into a completely non-technical org led by a CMO who thinks pivot tables are black magic. But they same CMO has promised the CEO and the board that they can integrate their product analytics into their pipeline performance reports, and have it by next week.

Sure the marketer can say no, but the CMO doesn't understand why it is a no because their buddy CMO's marketing team does it already (not understanding the work that went into making it happen at that company). So the CMO interprets no as a performance issue not a technical or process issue.

And this happens all the time. So at some point the marketer is stuck between building a one off report in a spreadsheet or using the tools they have access to (usually something like zapier, or some marketing automation platform) to build a good enough solution that gets presented at the board meeting, and everyone is happy.

Play this on repeat with, marketing, sales, hr, finance etc every month.

The alternative to low code isn't code, it is excel spreadsheets.

No time to write a full comment now, but I would compare the fully planned org to failed communist states vs the more chaotic capitalism that does better.

You are so right. I've been CTO of several startups of different sizes , and the frustration of non-product teams to get ANY automation love was terrible on each of them.

And the funny thing is that usually, very simple things would mean a lot to said teams.

I saw it for marketing, compliance, legal, finance and even RH.

But the blame is not the tech team but business/ceo office: they set the priorities .

Otoh the comments here make me chuckle. How does the saying go? You can't make someone understand something if his life depends on not understanding it (or something like that in English o think)

> Say it's an API hookup and some automation between some tools

Why aren't companies better at putting requirements/user stories/whatever into Confluence/Jira tickets? Why do there have to be 10 layers in between, constant followups, repeating yourself? Why do there need to be meetings when you can just keep a ticket updated with all context?

Because it's hard, unpleasant, and often 'invisible' work that no one wants to do.

Often it's also frustrating, because if you write more than 3 lines, many devs don't read it.

This is why we have product teams.

Your experience is the norm, and no matter how much they may think otherwise, 90%+ of software teams are working in waterfall/delivery/feature teams.

Product teams are the solution, but very few orgs are willing to completely flip their structures to get there.

I agree. But what happens when the project finishes and now any remaining work has lower priority/roi than other projects? Is there any guidance for that?

product teams are long-lived, unlike projects

if someone (say someone from marketing) has a need for the product, and it gets de-prioritised, someone has decided the marketing person's needs are less important. That's why product teams have to be cross-functional and have ownership. You can't just have a board of execs 5 levels of hierarchy removed switching and swapping people randomly.

also why there are so few product teams. There aren't many execs willing to put the trust in their people to give them ownership of products/problems/opportunities/outcomes, without wanting a micro level of control on the solutions. Which is always hilarious because they hired these people in the first place (or the ones who hired them etc...)

> without wanting a micro level of control on the solutions.

HiPPO attacks are real. Nothing like having countless customer interviews only for a dataless HiPPO to come in and maul your product.

I feel like PMs are used as sacrificial anodes in some orgs. The HiPPO controls product via the PM. When the product inevitably flops, it’s the PM’s head on a spike.

Highest Paid Person?

Highest Paid Person’s Opinion, I believe.

You know the ones, they drop in towards the end of a complex cross functional discovery process and say something like “but it should do it like…” or “can’t you just…”

And some of the time they’re right, but the reason they’re right is because they created an organisation without delegated authority and autonomy, and tasked a team with creating change that also didn’t have authority. Which reinforces their view that micromanaging and not delegating authority is the only way to operate effectively because their team just doesn’t come up with the right answers ever.

Unfortunately very familiar with them and their disconnected demands, just have never heard them called HiPPO before and now I have a new favorite term for the over inflated egos in management that make being productive harder.

> Developer time is always the biggest bottleneck at any org I've worked with.

Also: you are an expert in something. Half the time the SME will spend a large chunk of their time being lectured by a developer with no domain knowledge, but a deep conviction that the SME is doing it wrong.

The worst thing here is when developer leads have strong personal feelings about things. I've seen a company sabotage its own growth for years because a CTO was uncomfortable with Javascript tracking tags. When they finally relented we were able to 2x our growth rate.

As another marketer, this is 100% spot on.

And it isn't a technical gap, but a process and priority gap.

I have a ticket open for our dev team that would personally take me about half a day to do. The ticket has been open for over a year. It is impossible to get into their roadmap and they are not about to share the keys to the castle to let some random marketer do it, even one with a development background.

I hate zapier, but it works and it is quick. Sure it may have to be rebuilt at some point, but having a 60% solution today is a lot better than no solution with the promise of a 100% solution (that will actually probably also only be a 60% solution) in a year.

The best escape hatch I've seen for this kind of organizational issue is UpWork. You get UpWork approved as a vendor, then you can spend your own department's budget hiring whatever random contractor you need. Yeah you might spend $1500 on a two hour dev task, but at least it's getting done immediately instead of blocking your whole project for 6 months.

Good for marketing now. Horrible for maintaining developer later. I was recently working on a marketing application and the it was the worst experience of my development career. There's was zero afterthought about what it would take to keep thing running once it had been launched. The only thing worse than the intractable bugs was the unwillingness to invest in its maintenance. I'm not usually fan of a complete rewrite, but in that case I wanted to nuke the site from orbit. It's the only way to be sure.

I spent years as a consultant following a basic pattern: a subject matter expert wrote a tool or series of tools in something like excel or access. The tool got popular but didn’t scale. My firm would get brought in to “fix that and then automate all the processes.”

When I was a junior consultant I’d get angry at how kludgy and inelegant the original solution was. After a few projects I’d realized how hard producing software that business users actually use can be.

My response now is “this is amazing, look how far you’ve come. Let me help you go further.”

Yeah it stinks and yeah I often did from scratch rewrites, but the work done proving the idea/system was valuable was why I had a job in the first place and had delivered more value then I could as a developer.

I’ve long thought of starting an agency where “we’re developers for marketing depts”, ie, we’re seasoned devs, hire us and we’ll jump into the dev side of things and the company’s codebase, make the changes needed that you want, keep us on retainer if you want updates, and that’s that.

What do you think of that?

Yes, it's called consulting and it's great work if you can get a consistent client base.

I genuinely wish you the absolute best of luck getting a consistent client base.

Some of those exist, usually billed as implementation partners that also can do whatever dev work you need.

The problem is getting marketing leadership to believe they need those services. Usually you have a handful of technical marketers shouting from the rooftops asking for dev support. The CMO goes and talks to the dev team and they are reassured that there is no need to outsource, there is a perfectly good team in house that will get around to it eventually.

I've had the best luck bringing in a firm as part of an implementation and then keeping them on for a few months to help with odd jobs in the guise of support.

Executive leadership in sales and marketing is typically clueless as to what their teams need too be successful. It isn't in their job description, it isn't what they were hired for.

Very interesting and useful insight, thanks!

Then you want to use your data in an internal system and all breaks lose.

Usually what happens the structure of your has to change because sales now wants to sale the product in a different way and your no-code tools can't support it.

No-code tools are great for solo founders but terrible for enterprise anything

Also reason why Canva is worth a lot. Similar pain point being solved.

there is reason why John Woods wrote in 1991

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.

https://stackoverflow.com/a/878436/499698

>>Anything that let's you get around it is worth its weight in gold.

I have a novel idea....

HIRE MORE DEVS!!!!!

I know, I am crazy

Not in this space .. is Zapier the same as IFTTT?

Yes, I think Zapier is a B2B version of IFTTT.

Then the dev team never gets to write anything because they're always being interrupted. On top of the fact that developers are almost never in charge of prioritising their own work - that's what project and product managers are for.

That worked extremely well at a past org, I had a partner and we worked really efficiently. Until the project manager put a stop to any shadow dev work.

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.

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.

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.

The smiting will continue until the code quality improves.

> 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.

"Recommended so heavily" by the suits making commission selling the things, maybe.

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.

> 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.

The "No code"/"Low code" industry will always be "Inner-Platform Effect as a Service". They reflect whatever programming language they themselves were built in, but dumber, worse, and harder to program in.

The sweet spot is of course demos for PHBs. The allure of inner-platform effect in almost every case has always been that drive towards "we can save money by not hiring actual programmers". It is a delicious vision for business people that remains forever ironically unaware of the "law" that is a direct corollary for the inner-platform effect: any sufficiently advanced configuration is indistinguishable from programming.

The perceived "advantage" of "No Code"/"Low Code" is increased ability by companies to "move fast and break stuff" with process testing or data visualization or "one-off" tools.

The true "advantage" of "No Code"/"Low Code" tools is how well they shift tasks from senior developers to more junior developers and/or business users that want to try amateur/semi-pro programming without the requisite bump in salary. But if you are going to need a senior developer to come in and properly productionize it anyway how much are you really saving? How much are you instead over-expending on "ejection" and rework and rewrites that might have been avoided just going to more senior development staff in the first place? (How much of the senior developer anguish could be avoided by realizing that "move fast and break things" includes accidentally breaking senior developer morale every time they are handed some strange "Low Code" thing from business people playing amateur coding adventure hour and throw it over the wall with "we need it in production stat; it's mostly done so should only take a few hours, right?")

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.

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.

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.

> 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.

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.

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.

this kind of reminds me of those integration platforms. where you need specialized training and consultants to map data.

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.

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.

I suspect we're all talking about the same tool.

Most of those tools don't need specialised training and consultants.

It's just cheaper for the company to use them rather than hiring or training new staff.

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.

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.

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.

[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."

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.

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!

Ok but this very strong statement has literally nothing backing it

Source: Trust me bro.

Nobody can talk about their life and experience without a supporting meta-analysis of a hundred studies

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

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.

> 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.

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.

Does this include every excel spreadsheet application we have today?

That is what low code should be replacing.

Why? Excel is incredibly powerful. Most no-code platforms can't do much compared to Excel.

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.

Excel has had version control for years, via 365.

https://support.microsoft.com/en-us/office/view-previous-ver...

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.

That's backup with point in time restore rather than version control. It can't track semantic meaning of changes.

XLSX are zip packages. It can be "fun" to version control the contents of the XLSX rather than that binary zip.

Most of the data inside is just XML and with a good (stable) XML autoformatter you can even see some nice diffs between versions of an XLSX file.

A long time ago for interesting reasons of my own (including the fact that I was using darcs at the time and diff/patch-size especially of binary files was directly a performance issue) I wrote a tool called musdex to automate that workflow as (in git terms) pre-commit/post-checkout/post-merge hooks. I offer no warranties for anyone wild enough to use a tool like that in production Excel workflows, but it's a "fun" thing to try.

In actual git you'd do this with a .gitattributes file, defining a specific executable to do the diff. The docs show it being done with a docx (by converting to text) and a png (using its metadata): https://git-scm.com/book/en/v2/Customizing-Git-Git-Attribute...

I've used musdex in "actual git" with the aforementioned hooks. It works pretty well. There are some advantage to the chosen hooks approach rather than a git attributes-based approach especially that it is more "portable": GitHub doesn't need to have musdex installed to view "musdexed" repositories and you get the nicer merge/diff behaviors from standard diff/merge in PRs and commit views and everywhere. Also, while it is much less of a performance boost compared to darcs, git still benefits in some cases of pack file delta compression/optimization due to smaller differences in "musdexed" text/XML files rather than binary containers.

I have one public example of this on my GitHub that comes to mind, but it's a particularly weird one because it uses a musdex plugin to extract/combine an already non-binary format. (In this case it was an Inform 7 story.ni file that I just preferred to source control as lots of smaller, column-wrapped "chapter" files rather than one long "book" file of run-on paragraphs. GitHub's cool modern code browser hasn't been taught how to do jump to section for Inform 7 story.ni files, so it is nice being able to browse it as a file tree instead. Similar it's nice to see commit diffs broken down by chapter. I can't install my own Inform 7 plugin to GitHub's website, but I can certainly reshape my repo with a tool like musdex.)

What they lose is a long history and community knowledge of hacks. What they gain is data integrity, consistency, and concurrency.

We need to think about a tool that can do those with the same ease as Excel (Or Access). If we can't do that, it's because we need to make these tools better.

Excel is low code.

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.)

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.

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.

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.

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.

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

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

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.

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.

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.

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.

Numerical claim with no evidence. Thanks, OP.

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

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.

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.

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)

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

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.

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.

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!

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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

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

Why is a no code dev easier to replace than a code dev?

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...

No code is simply somebody else's code.

Serverless is simply somebody else's server.

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

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.

I am shocked SHOCKED to hear this!