[HN Gopher] Tell HN: Enterprises spend 10x more to build no-code...
___________________________________________________________________
Tell HN: Enterprises spend 10x more to build no-code solutions than
coded ones
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.
Author : nancyp
Score : 178 points
Date : 2023-09-28 13:25 UTC (9 hours ago)
| lupire wrote:
| Numerical claim with no evidence. Thanks, OP.
| didip wrote:
| 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 wrote:
| 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.
| yobbo wrote:
| The benefit, in the eyes of leadership, might be that the
| consultants/devs are easier to replace which reduces risk.
| lupire wrote:
| Why is a no code dev easier to replace than a code dev?
| rapfaria wrote:
| 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...
| hcks wrote:
| Ok but this very strong statement has literally nothing backing
| it
| malfist wrote:
| Source: Trust me bro.
| rchaud wrote:
| 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.
| timcavel wrote:
| [dead]
| bilekas wrote:
| > 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 wrote:
| 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.
| lifeisstillgood wrote:
| 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.
| simonbarker87 wrote:
| 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.
| logicalmonster wrote:
| 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 wrote:
| > _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.
| WorldMaker wrote:
| 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?")
| hooverd wrote:
| Numbers? Gives my experience with no-code solutions that aren't
| spreadsheets, I wouldn't be surprised.
| wruza wrote:
| 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.
| spcebar wrote:
| 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 wrote:
| this kind of reminds me of those integration platforms. where
| you need specialized training and consultants to map data.
| threeseed wrote:
| 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.
| koromak wrote:
| 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 wrote:
| 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.
| neeleshs wrote:
| One unsaid thing - developer salaries.Far too often (myself
| included) we ignore that our own salaries are a cost
| cm2012 wrote:
| 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.
| ipaddr wrote:
| 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
| granshaw wrote:
| 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?
| letsdothisagain wrote:
| 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.
| droptablemain wrote:
| - 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.
| pas wrote:
| 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.
| simonebrunozzi wrote:
| Also reason why Canva is worth a lot. Similar pain point being
| solved.
| cbm-vic-20 wrote:
| 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.
| olavgg wrote:
| 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.
| silpol wrote:
| 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
| rodgerd wrote:
| > 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.
| MuffinFlavored wrote:
| > 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?
| HeyLaughingBoy wrote:
| 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!
| projectileboy wrote:
| 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.
| BeetleB wrote:
| > 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.
| hooverd wrote:
| I think some teams could do really well to have an embedded
| developer- someone who can understand both fields decently
| enough.
| analog31 wrote:
| 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.
| HeyLaughingBoy wrote:
| 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.
| Spooky23 wrote:
| 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.
| MichaelZuo wrote:
| 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.
| bitwize wrote:
| As a developer, let me tell you how things go:
|
| 1) Marketers 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.
| afarviral wrote:
| 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?
| marcosdumay wrote:
| 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.
| cjalmeida wrote:
| This here. Fully centralized IT is stifling,
| shadow/decentralized is chaotic. Good structures come from
| hybrid, matrix-like approaches.
| dgellow wrote:
| > 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 wrote:
| 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 wrote:
| > 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 wrote:
| And people wonder why organizations have such high
| headcounts...
| willsmith72 wrote:
| 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.
| josho wrote:
| 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?
| willsmith72 wrote:
| 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...)
| c_o_n_v_e_x wrote:
| > 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.
| austin-cheney wrote:
| 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.
| drpossum wrote:
| 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.
| cm2012 wrote:
| 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.
| mellosouls wrote:
| That's a good observation but falls apart if actual
| developers have to maintain the Rube-Goldberg app created
| by well-meaning "Citizen Developers" _((c) 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.
| leejoramo wrote:
| 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
| ramesh31 wrote:
| >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.
| hftthw wrote:
| 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.
| Dwolb wrote:
| 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.
| FridgeSeal wrote:
| Low-code-no-code: it's all fun and games until it isn't;
| and when it isn't it's an tire-fire.
| potta_coffee wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| chaos_emergent wrote:
| 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.
| wmidwestranger wrote:
| 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.
| RankingMember wrote:
| Where is this 10x number in the headline coming from? Can you
| link some data?
| officialchicken wrote:
| 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.
| no_wizard wrote:
| 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.
| jrockway wrote:
| 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.)
| ltbarcly3 wrote:
| 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.
| codingdave wrote:
| 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 wrote:
| 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.
| mvdl wrote:
| No code is simply somebody else's code.
| hospitalJail wrote:
| 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.
| cstrahan wrote:
| 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.
| atonse wrote:
| 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.
| LorenPechtel wrote:
| It still takes the same skills whether you have "code" or not.
| jenkstom wrote:
| This is exactly right. And codeless tends to not have the
| capability of dealing with complexity very well, meaning
| architecture is brittle.
| th3h4mm3r wrote:
| 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.
| threeseed wrote:
| 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 wrote:
| 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.
| sundarurfriend wrote:
| > 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.
| trunnell wrote:
| 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 wrote:
| 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!
| BLanen wrote:
| 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 wrote:
| 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.
| frugalmail wrote:
| This was my experience with Alteryx and Informatica vs.
| Scala/Python/Shell + Airflow as well.
| threeseed wrote:
| 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.
| [deleted]
| ebiester wrote:
| Does this include every excel spreadsheet application we have
| today?
|
| That is what low code should be replacing.
| darkhorse13 wrote:
| Why? Excel is incredibly powerful. Most no-code platforms can't
| do much compared to Excel.
| fragmede wrote:
| 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 wrote:
| Excel has had version control for years, via 365.
|
| https://support.microsoft.com/en-us/office/view-previous-
| ver...
| fragmede wrote:
| 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.
| isbvhodnvemrwvn wrote:
| That's backup with point in time restore rather than
| version control. It can't track semantic meaning of
| changes.
| WorldMaker wrote:
| 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.
| Izkata wrote:
| 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...
| WorldMaker wrote:
| 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.)
| ebiester wrote:
| 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.
| sfink wrote:
| Excel _is_ low code.
___________________________________________________________________
(page generated 2023-09-28 23:01 UTC)