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.
191 comments
[ 2.4 ms ] story [ 493 ms ] thread- 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.
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'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.
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.
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 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?")
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.
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.
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.
It's just cheaper for the company to use them rather than hiring or training new staff.
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.
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...
That is what low code should be replacing.
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.
https://support.microsoft.com/en-us/office/view-previous-ver...
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.
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.
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.)
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.
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.
'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.
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.
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.
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.
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.
That’s so true. It’s not to build quickly, it’s to keep the agency within the non-engineering department.
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.
Vs. the reality, in most large org's - that plan gets shot down faster than non-union electrical contractors in New York City.
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.
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.
Projects that start at an empty white board are much harder, which scope creep and higher failure rates
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.
The no-code could easily fall into the same category, as valuable hashing-out process.
Any "proper programmer" should know this.
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.
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.
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.
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.
If ChatGPT can make basic programming eaiser, and Excel ships with easy and excellent Python integration, we will see more Excel.
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.
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...)
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.
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.
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.
The platform itself is quite good. But it only runs on Oracle, so I'm not sure I recommend it.
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).
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
"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!
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.
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.
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.
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.
Saying no is a power move that gives you street cred in the organization. Helping people is for the meek.
Manager is not incentivized to do X? Then forget it. Not my job, not my problem.
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.
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…
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.
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.
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.
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 ?!”
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.
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
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’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.
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.
I wouldn't want a "dev" who spent 2-3 hours a day doing something like this manually working with me.
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
What do you think of that?
I genuinely wish you the absolute best of luck getting a consistent client base.
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.
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?
Often it's also frustrating, because if you write more than 3 lines, many devs don't read it.
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.
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.
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.
But several catastrophic failures in a short timeframe can ensure it gets no money at all!
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.
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.
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.
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.
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.
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.
I have a novel idea....
HIRE MORE DEVS!!!!!
I know, I am crazy
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
It’s not a case of “redoing all the work” it’s about helping to know we are doing the right work.