This to me is true for low code tools that are aimed at non-developers. “You can write software without software developers!” But low code tools made specifically to help developers’ workflows can be great. Maybe would be good for OP to clarify type of low code tools
I think it's fine to use low-code specifically for the lie that the only thing preventing people from writing code themselves is a slick UI.
Sure there exist applications that do equivalent things, but when people start using the word 'low-code' to describe such an application they suddenly get the weird idea that the hard part of coding is typing the damn syntax and that if only you put a GUI in front of it they can do it themselves.
Conveniently forgetting that people have made the exact same promises about the first IDEs. Pretty sure there's an ad to that effect for Turbo Pascal somewhere.
Code is a way of explaining rules. If you have a lot of complicated rules, whatever system you use to represent it is going to be complicated. Best case scenario for low code is when the rules are simple or very predictable. In my experience, this is very rarely the case, no matter how simple a problem seems from the outset
I’ve seen this exact thing, a “low code” engineer creates an app, we asked for some changes and all of a sudden “no can’t be done” - it is almost comical tbh
For compilers or anything else, if you have a bunch of spaghetti code, the first step is always to clean up the code. Refactor it to the point where you can easily swap in your low code module. Then determine whether it's still worth it to do so.
What happens all too often is a hack week project that brings in some low code functionality in some simple use case gets shown off and kicks off a bigger effort. But then the edge cases buried in the spaghetti code come up in some way tangential to the low code approach, so it gets hacked in. This happens over and over, and eventually your low code model is just as spaghettified as your code was, except now that spaghetti spans yaml, some interpretation layer, and the remaining two thirds of the original code that you haven't migrated yet.
For this I'll coin my law of declarative intentions: the resulting low code cannot be simpler than well factored code itself.
In my experience, low-code is “easy software development” but without the guard-rails of version control, debugging, open standards, local development, unit-testing etc etc…
These are the things that really matter as software complexity grows…
It's true that most low-code solutions have no version control but that's not because it's not possible, its because no one builds version control as low-code solutions aren't taken seriously. And without a VC, low-code solution won't be taken seriously.
I have been using Node-RED[1] for some time now and have began creating a visual version control concept. The difficulty is differentiating between visual changes and logical changes - visual changes aren't usually the cause of bugs.
[1]="Low-code programming for event-driven applications" - https://nodered.org
IMVHO the "low code" environment have a name: end-user programming. The thing the entire entire industry have done it's best to destroy it after Xerox, Symbolics.
The rest is the nth failed tentative to makes users jailed by ignorance selling the idea people can do thing without knowing things. It will fail like any other tentative done before.
Microsoft Excel is end-user programming. The amount of businesses that have critical processes done entirely in Excel is both impressive and terrifying.
It is basically a database, reporting tool, IDE and half a dozen other things all rolled into one giant mess.
I know an SMB that has all its operations on Google Sheets. They told me they don't have time to learn any tool (all their efforts go to keep the business running), and they don't have the money to hire a full-time dev. I offered them the opportunity to develop their platform pro bono. They're thrilled since they will be the first business with that type of platform.
This applies up, as well. I was involved in talks with a household name (in the US at least) retail store that still managed purchasing for all of their locations via spreadsheet, and had a team of 8 people who were allowed to touch it at any given point to reconcile inventory.
They had looked at getting a proper purpose-built system in place, but I don't know what happened after that.
It's a mess because it try to be "made for ignorant users" instead of choose the classic desktop way.
First: in classic systems the OS is a single application/framework where anything or nearly anything is accessible by end users, so there is no special integration limit that force devs to reinvent the wheel to have anything in a single modern app and reinvent it in bad way since they have no time nor resources even at the big tech sizes, plus the need to invent ways to circumvent system design limits.
Being a single app means if I have a CAS installed I can solve an ODE in an email just typing it and pass the math expression to a relevant CAS function, no need to reinvent a basic or less basic calculator. No need to know all the stuff about making it. I just access the relevant functions written by some expert and tuned for that purpose. The dev does not need to know, it's the user who know and use.
Secondly means an incredible simplification. Let's talk for instance about a Plan9 mail client: what kind of beast is? Well it's just a base64-to-text reader and writer. Nothing more. The connection to the webserver is just a universal system connection to a remote file server, a remote filesystem mounted somewhere under the local root. All you need to do is knowing how to access a local fs, read text files, read/encode base64. Nothing more. Sending an email is just saving a text file with a given name in the right place. Publish a website is the same BTW, so it's sharing a file. Being a single app-framework means that anything is simpler, there is not much duplication of functions, only tuning.
Now try to see an example of modern Emacs in action like https://youtu.be/B6jfrrwR10k how much complicated is creating a slide? Well just zoom some org-mode text. A table like a spreadsheet? It's just text and can be passed to any programming language supported by org-babel as data.
Doing so meaning no lock-in possible and the end-user in control, that's why all the modern IT industry starting back then with the not-so-modern IBM, have demolished this, but the result is a mess. A decade after another we tend to the old model wasting gazillions of resources to keep up an untenable business model.
We started out with webflow for our landing page. Problem with low code or any abstractions in general is that it becomes leaky the moment you want to do complex stuff. The reason webflow worked for us initially was we did not have to bother with hosting, CMS etc. It because very restrictive at one point. Only couple of people know how to make certain changes.
Eventually we moved to nextjs and vercel. We are faster with iterating on our landing page as well as any engineer can be pulled into the implementation.
All lowcode platforms are great in basic usecases but fails when the usecases because complex.
We went the other direction (to be fair, just building a simple static site). I’m a developer therefore I should make the marketing site! Problem is that with limited resources that took away time from building the product.
We’ve moved to various platforms over the years so that our designers with a touch of web knowledge can build our marketing site. They’re happy bc they don’t have to wait to make changes and devs are happy bc they don’t have to work on marketing sites.
The designers actually enjoy the constraints to a degree bc it simplifies their job as well.
But like I said, it’s just a simple static marketing site
But the big issue seems to be that they're not marketing anything to the developers. They're marketing everything at the managers -- particularly the kind of manager that doesn't really understand software.
Maybe I'm not clicking deep enough, but that marketing site looks like a super trivial Webflow CMS use-case.
Although if your team is all engineers pushing to git every day, I could totally see how they'd find Webflow frustrating (since a UI instead of a codebase would be a huge pattern-interrupt for their daily workflow).
That said, once your startup grows, what typically happens is you'll need to bring in specialized marketing/sales/design/SEO folks (vs. Swiss army knife SV startup hustlers). Their hours are far cheaper than engineer-hours and they're also much better at marketing/sales/design/SEO work, like your landing pages & blog.
They will not be able to change anything on your slick NextJS/Vercel setup , and will be filing tickets daily and overwhelming your engineers.
Then you'll probably have to resort to some nightmarishly bloated "headless CMS," and waste a huge amount of time on implementation, and then it will be impossible to change.
That's when it makes sense to switch back to something like Webflow.
We use one of those headless CMS already. You have a point. It works for us for now, we will see how it turns out. You need a bit of discipline to execute it.
Low-code is just good libraries and good frameworks. My hot take is that anything “low code” beyond that is just an aggressively user-hostile config interface.
Most(all?) self code self-hosts, which is extremely valuable. There no shortage of smart people who can creat complex tools (see Excel for examples) if hosting it wasn't currently such a ridiculous prospect.
My version of low code is writing HTML pages with a big script element full of vanilla JavaScript, and putting them in this one git repo we have which gets deployed to a web server.
Obviously it's not actually low code, it's 100% code, but it creates a space without a lot of the complexity and ceremony of 'real' software development. I don't write tests, I don't future-proof, I don't set up deployment or monitoring machinery, I don't worry about anything except solving a small, well-defined problem quickly.
It's definitely not a good approach to everything. But it's quite common for one of my users to say something like "I need a dashboard showing how the current reactor temperatures compare to the averages for yesterday, and also the available cooling water for each one", where that's all data we have existing websocket feeds for, and I can get that to them very quickly without it becoming formal feature development.
Lack of testing and monitoring means the products often break. But when they do it's typically benign - the page doesn't load, or shows no data, and if a user needs to use it, they'll complain, and I can fix it.
If a page ever got too complicated, or too critical, I might want to port it onto real software. But that hasn't happened yet.
Reactor temperature monitoring is surely the exact area of software engineering (along with medical software) where you'd want the most robust processes isn't it? If your solution says everything is fine when in fact it's not, someone will have a big problem on their hands.
I'd argue that is actually the hard part of software engineering. Sure, I can learn the basic syntax of a new coding language in a week or so, but learning all the deep frameworks to do non-trivial stuff, conventions, deployment, and how to diagnose bugs can take years to become expert at.
Much of this feels like needless complexity, but its ubiquity in almost every stack points to something fundamental, in my opinion: the classic 80/20 rule. That last, irreducible 20% complexity is where the dragons lie. Expectations for software have grown, and boundless flexibility is table stakes.
The security threat models are wildly different though. A “no-code” solution won’t be convinced to export private data with the right conversational English smooshed into the username field, for example.
I've seen the opposite. Business hires new CTO who has no knowledge of existing stack and why it is breaking but sells the top brass on a low code replacement because of how quickly he can build with it. Spends a year building the replacement, forces a hard switch and fireworks ensue.
I've never seen a local hardware store shed kit that wasn't complete garbage for the price.
Building a simple shed isn't hard, if you can handle assembling the kit you can buy and cut the basic materials yourself. The trickier parts like getting it watertight or installing doors and windows have to be done either way, all the kit gets you is a bundle of inferior materials and a bit of time savings cutting studs.
I am on the other side of low code, building the builders for the most part, here is what I see.
Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool.
Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Wiring up a form shouldn’t take html, js, and a serverside language.
On the flip side, don’t put your core business logic in low code. Low code builders assume anything complex will be offloaded to a specialized system. The best ones provide escape hatches by calling remote APIs or calling a code module.
Low code gets sold to smaller customers because it’s touted as a developer replacement. But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It’s easy to get them to configure something in a SaaS they already use, than get a custom solution from IT. Also low code often comes with guardrails and permission sets tied to existing users.
I see low code as a tech equivalent of the last mile problem in logistics. It addresses a large number of concerns with simple tools, but doesn’t scale well and needs to work in tandem with a stronger central system. End to end low code is a trap, but low code at the fringes is a multiplier.
I like your analogy to the last mile problem in logistics. I would argue in that case people know they are using bespoke, last mile only, systems because there is no other option. Low code vendors promise much more than that, end to end capabilities.
I adopted an official personal policy of not working on any data project referred to as "last mile". It's a big sign it's going to be under-resourced and under-appreciated. The last mile is brutal. And that's in the physical world!
You can tell when your last warehouse is close to the customer by looking at a map. You can't tell when your tool is close to what the user needs with nearly the same accuracy. There are a ton of gotchas, and as part of the "last mile", it's now your responsibility.
> as part of the "last mile", it's now your responsibility.
You also are at the whim of the SaaS vendor to give you the help you need. If they can't do something you think it should, good luck making a hacked workaround to function as it must.
This is still usually tech solving an organization problem. Launching normal apps gets gated under security, product, or technical reviews but the low code tool becomes a backdoor to all that.
If you just deleted a bunch of processes, or just reserved it to when it actually matters, you wouldn't need to pay a low code vendor to basically allow your team to do their job.
Low code with an escape hatch is quite nice, because yeah - many things can and probably should be low-code. It's a big productivity and standardization enhancer.
That escape hatch is absolutely necessary for longevity though. It lets you keep your low-code environment simple because you can leave it and write real code when necessary, rather than forcing everything into an over-complicated and under-capable custom thing with no editor tooling.
Agreed, with the caveat that you also need a policy/culture that the escape hatch should be avoided whenever possible and the low-code work should not be done by developers.
Whenever I've discussed this, the common theme is that business users continue to request features that would be easily achieved in the low-code platform being used. It's hard to blame them; that's been standard procedure for them for their entire career.
But if you're not strict about saying "no", you still end up writing all the same methods but now on top of that you have a GUI that's not providing any value. Or maybe worse, your developers end up maintaining all of the low-code stuff too when they could have just written the code, switching context pointlessly and (probably, depending on the platform) not using source control.
An interesting thing with developers getting involved in those boxes-and-arrows UI things is outages. I made a mistake with one once, and the postmortem quite reasonably asked:
* Where was the design doc?
* Where were the alerts?
* Where was the code review?
* Why didn't you write an integration test?
* What do you mean it just rolled out to production instantly?
When we're considering options in advance of building something, it's a more time-efficient, less wasteful alternative to programming. But having built it, everyone acknowledges that what we have done is programming, and now they wonder why we've programmed so badly.
Maybe the standard IDEs, Git, code review, CI, metrics, and incremental deploy workflows were fine actually?
For me, none of the learnings is a direct result of using a low-code, arrow-boxes environment. I can deploy instantly to production using any programming environment, if I don't automatically have design documents when using a much-code environment.
Without discipline, any programming environment can lead to failures.
It is true that there aren't any well-defined workflows for using an arrow-boxes environments but that does not mean that these environments don't support specific workflows.
Are these environments attractive because boxes and arrows are actually better than characters for expressing programs? Or are they attractive because they encourage you to skip steps that turn out to have been important? Sure, you can replicate a normal, responsible development process with a no-code tool, but at that point do you really have a compelling alternative to a more traditional programming environment?
Low-code tools have a market fit problem because of that escape hatch. The players keep trying to sell it as a solution to IT deficiencies but it should be sold as an IT empowerment tool. It really doesn't matter how good your last mile delivery is if the shipping container with the product isn’t where it’s supposed to be to begin with.
All the components and modules that low code tools provide should be nothing more than an onboarding tutorial like the first few levels of Factorio, before letting the engineering team loose hand in hand with the users. It shouldn’t be an escape hatch, it should be the front door.
As such all these low code tools make the mistake of making it really difficult to bring the engineering team into the fold: modularization, logging, debugging, version control, and development tools are absolute garbage so instead of engineering providing a few sane company specific building blocks that they can tend and nurture, it inevitably turns into a shitshow because you can’t use a tool that ultimately depends on the IT department to fix the IT department!
The best “low-code” tools have already been around for over a decade: it’s the headless CMS and autogenerated admin pages ala Django and Wagtail. They’ve been focused on solving the content management problem for e-commerce and marketing, but IMO it’s the write path for other groups too. The engineers write the pages and blocks and components while defining an input/configuration schema for an automated tool that is usable by laymen. Up the level of abstraction to a well curated (by the engineers at the customer level) IFTTT layer and bam, you’ve 95% of use of low code without the 5% that inevitably ruins it.
I totally agree on the "IT empowerment" perspective, but unfortunately the price model of these tools makes it hard for many IT departments to introduce them, at least in established corporate environments, for internal use. Startup and public facing stuff is different of course but my experience is medium enterprise internal IT..
Per end user rather than per developer means they're far too expensive to introduce as a general IT toolbox item, they need to be part of a major strategic project where the $5-30/month per staff user has a hope of being justified.
But that also often takes it outside the "IT Dept", which is often just "infrastructure and pc fleet" support, not development ( at least, that's my experience ). IT might do internal scripting and some service interface tooling, but business tooling and software is rarer, that's usually either dev teams or ERP teams. The ERP teams will already using ERP platform tooling, so that further narrows the market.
I don't have a good solution for this, but it's always been the hurdle I've tripped on working for medium size enterprises.
There would seem to be an opportunity for "open source platform, commercial training and support" here, but vendors seem to gravitate to per user head and cloud only for more immediate revenue and easier support., but again many enterprises still have huge internal only IT landscape's, because cloud is still expensive and the value often isn't seen in relatively static envs.
It's possible this niche has been filled now too, it's been a while since I looked...
Possibly they can be introduced on a "just those who need it" basis, but honestly that's just so bloody tiring for internal tools, not to mention demotivating as you can no longer build tools for "everyone or anyone", it's back to specific narrow business cases, not IT empowerment, but narrow business case also means your usually competing with cots tools or consultants.
The escape hatch is where most low code products fall down, I think. This is because of market fit as you correctly point out, but not only that.
It's also because knowing where the escape hatch and how to use it requires greater than average development skill and finesse and it isn't at all obvious when this is required.
The people who use these platforms aren't usually able to tell what kind of problem requires a developer and what kind of problem requires them doing just a bit more research. They're usually vaguely aware that the limit is out there somewhere but in the specific instances when they hit it they often don't know it's happened.
I've also seen some low code platforms get a little excitable about the idea of nearly or even fully reinventing the turing complete programming language to introduce more flexibility to their platform and make that their escape hatch. This is when things go really downhill.
This reminds me of the deskilling problem, where operators whose tasks are automated away and end up being relegated to monitors and troubleshooters need to be even more knowledgeable and skilled to identify and resolve the ever-more obscure problems/edge cases that the automation cannot handle, but because the operators do not perform those tasks any longer, there is no reasonable way for them to maintain their advanced level of knowledge and skill. And the more automated the processed get, the greater the deskilling problem.
The success of low code implementations often comes with a curse of investing man-years of development effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor.
I believe there is a place for enterprise app platforms which are a) open source, b) not based on proprietary languages, c) with low code capabilities, fueled with AI code generation, d) runnable anywhere without staying dependent on typically user-based commercial model.
Shameless plus: we are working on such a thing, and competing with traditional low code platforms is not easy, I could tell a few stories about what we have tried, what works and what not really, if you are interested. I would be also extremely thankful for any comments and hints you may have, see https://openkoda.com
> effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor.
That's the definition of vendor lock-in. Once the vendor has it's hooks in your organization, good luck removing it. Sometimes it's just the cost of doing business, but the more the hooks, the greater the chance that a vendor triples or quintuples the cost of their product that affects your organization's secret sauce.
I feel like the goal of low-code solutions is to get you over the barrel. Much in the same way AWS tries to get into your company's operating costs.
I'd love to hear some of your stories about marketing it!
I create nocode plugins on a specific proprietary stalled platform, for a living, for a few years now, so I am definitely aware of the pitfalls in the area.
For me the problem is that the API to it got created in a nice format but then got abandoned, if they just listened over the years and added the changes we third party devs needed it would have been great.
Having escape hatches is critical, but they should also be well built, or it can cause just as much headache.
Example from us using Azure Data Factory: You can add a step to call out to an API, which we did for a data flow that had a lot of calls. Performance was atrocious. Dug into it, and the API getting called was replying in 100ms or so, but ADF's "escape hatch" was adding 5-10 seconds of overhead to send the POST and parse the HTTP status code.
Microsoft Support said that's normal, expected behavior for the service.
In the end, we had to write an additional batching layer ourselves.
This ADF abbreviation remind me of another framework we used, it is Oracle ADF (application development framework) and it was awesome low-code tool! You can literally create CRUD with entry form within minutes, we Spring Boot and ReactJs it could take substantially longer. The good part of the tool is that the code is available and you can make any changes you want. In the enterprise they prefer time to market over beauty or UX, so it did its job perfectly.
I develop plugins for a specific nocode proprietary platform, sixth year now doing it for a living, 95% of all apps use plugins, which are the custom code interface, the escape hatch.
The ones that don't are very CRUDy apps with no remarkable features, like just some pretty design to input and show information.
I'm curious, do you ever mention anything along the lines of "don't put your core business logic or mission critical stuff in this" ? That could backfire, but it needs to be said.
So from a certain perspective, the positive niche / need it would fill is enabling the local power users who might also do complex Excel queries, or have their own MS Access, etc?
Similar, low code is a bit broader and is usually associated with a business process like taking in a lead, providing a quote, or approving a transaction. Excel can do the calculations for these things but still requires a lot of human interaction. Low code can do a bit more like generating a form, evaluating branching logic, or handling an async process over time.
We tried low code (citizen development) as a solution to the "IT dept sucks" problem. It worked pretty well at the start but eventually became a data governance nightmare and as soon as we needed to restructure the business we ended up with ownerless applications and datastores all over the place.
It eventually turned out there was a prioritisation problem rather than a development capacity problem.
my guess: There's enough developers but things need to be prioritised one by one. If everything is a priority and everything is being worked on at the same time then there's not enough devs to go round.
Not a parent poster - but building all kind of crap that anyone can come up with is not the right thing to do.
One might think you need all of it right here right now - but in reality if you build 20% that is really really needed you get 80% or I could bet even 95% of actual work done needed for the company to improve productivity/performance etc.
> But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power.
It's not just business knowledge, it allows the people who are most committed to project success to do the work.
I think that's the real pain point with IT departments in large organizations. They aren't feeling the pain that made you need the software in the first place.
>Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end?
Oh my... Many, many, maaaany reasons.
For example, your entire stack is built in a certain way and you don't want to introduce new dependencies.
What if your cicd requires your config and code is separate and that you build a code artefact, and let's say 3 config artefacts (dev, cert, prod), all these are then uploaded to a central repo and handed over to some proprietary security/code scanning thing every time you merge new code. Then let's say your deployment is done the same way, you have your "deployment config" artefacts for each environment, but an infrastructure team manages all the infrastructure-as-code artefacts that take your config.
I worked in a bunch of big companies each having their own version of such process.
In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.
this is simultaneously a valid reason not to use low code tools - and why they find favour in many organisations.
>In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.
I've also seen the opposite. Someone in the org wants a simple site. Maybe a sign up form, or CMS/wiki for internal docs, etc. The dev team says "sure, that'll be 6 months". A large part of which is constrained capacity - the devs need to fit it in alongside a buch of other stuff. Another part is tech choice: the corporate stack uses e.g. React on the front end, calling web services written in Java, backed off to Postgres for storage (or whatever). The devs estimate for building the CMS/wiki/whatever from scratch - because it has to fit the tech stack.
At that point the (internal) customer screws up their face and utters all the familiar frustrations about "IT". Someone somewhere mentions to them that there's a way to sidestep it all, and do it yourself. In their position it's very hard not to see that alternative as attractive.
It's a hard problem. That same internal customer will similtaneously rail against the recharge in their budget for IT. It's a cost: a drag on their P&L. IT says they're under-resourced, and they could do it quicker with more people - but that would increase the P&L drag. Vicious circle.
Software is a sociotechnical endeavour yet we too often focus on the technical and ignore the social aspect. Yet "Low Code" and similar emanate primarily from the social side. Coming back to your post though, not exclusively. Development teams can be equally culpable when zeroing in on tech stacks that aren't a good fit for the problems at hand. Or, perhaps, stacks that are a good fit for the problems they were chosen to solve - but not so much when the new requirement comes along.
Of course, low code is no panacea either. Most non-technologists have no perception of the need for ongoing evolution, even if there's no new feature development. Patching/upgrading is a must. And new features always emerge - most after the original "citizen developer" has moved on / lost interest / whatever. So the whole shebang gets foisted on IT, who are expected to operate and maintain it. Usually with no tests, automated builds, documentation, ...
It's pernicious. At heart, though, it's primarily a social problem that needs a good underlying relationship between the customers/users and the developers. It's Conway's Law. Of course tech choice still matters. But no tech stack is going to magic away problems rooted in organisational friction.
> It's a hard problem. That same internal customer will similtaneously rail against the recharge in their budget for IT. It's a cost: a drag on their P&L. IT says they're under-resourced, and they could do it quicker with more people - but that would increase the P&L drag. Vicious circle.
I started my career as a Solutions Consultant. Our primary customers were small business units in large organizations that were frustrated with “IT” and looked externally to solve their problem. Low code is a variation on this strategy.
Our delivery time estimates always beat IT estimates and our costs were often less.
Maybe because we were seen as a competitor to IT, or maybe some manager was being sneaky our first interactions with IT was usually after the engagement contract was signed. (None of these projects had RFP/RFQs)
During the discussions with IT was when the hard parts of the engagement really happened. It was then we learned about the compliance requirements. Security, data integrity, availability, platform standards, ci/cd, pmi, etc…. These unknowns often dragged out our delivery times and skyrocketed our billable hours. Putting us equal to or behind internal IT.
In my experience at large organizations Compliance is more closely aligned with legal than IT but is often an a function of IT. The rules set forth by the legal teams are enforced through technical/process controls by IT. This makes IT look like the ‘problem’ went in fact they are just following mandates set forth be legal.
It’s often easy for a business unit to complain about IT preventing revenue growth and get an exception. If a business unit complained to upper management that legal wouldn’t let them do something I doubt exceptions would be granted as easily.
I’d suggest that compliance be its own department and review all external tools or vendors instead of IT. This would put external consultants or low-code solutions on par with internal IT. If would also shortened the feedback loop between those creating the rules and those it causes grief.
> Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool.
I feel like you just explained how salespeople can scam decision-makers into thinking low-code solutions will do more than they can do, and in no way countered any of the arguments in the OP about it's dangers.
> I see low code as a tech equivalent of the last mile problem in logistics.
Ironically it's the OT and logistics people who've figured this out, with low / no code solutions fit for purpose, which don't necessarily run in the cloud, which have full microservice / SQL integration... and baked in OT drivers, RFID and bar codes.
Seems like the generators and gem ecosystem in Rails already solved these problems. I can easily build a devise login in less than 10 minutes. Low code in Rails is almost instantaneous and you get tests automatically too.
I use n8n.io hosted locally to abstract away authentication when building complex api integration mvps that I use to show as possible and working, and then that gets sent to engineering to convert to something that follows better best practices.
As an SRE that occasionally encounters low-code things I'm also pretty skeptical..
* there is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control.
* the workflows are poorly if at all documented.
* they still require a lot of custom code but that code isn't as reusable, tested or testable
* they often require a proprietary runtime, worse this may only run on windows
* they are difficult/impossible to instrument and so are difficult or impossible to monitor. Or if they do have monitoring it is going to work differently than the rest of your stack - likely using email based alerting which isn't ideal.
* the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
The only tool that was semi-reasonable here was Looker which isn't exactly marketed as low code but at least in the version of the product I used did integrate with source control. Though generally the people writing lookml were still engineers.
I'm much more a fan of composable platforms that compress complexity but still make it possible to delve, customize and extend when necessary.
> * the workflows are poorly if at all documented.
Ideally it would be easier to understand if there's less code involved. Things should be more declarative, or the low-code solutions would generate good descriptions for what is actually happening.
> * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
Or worse: "Why does this connection to this server fail with SSL Certifcate Invalid? Oh, nm, we'll just uncheck the SSL validation box."
But really you are missing a key piece of the puzzle, it matters less what is happening and more why. Sure a low code tool could churn out a textual description to say if the value of some variable is < some threshold branch to X else branch to Y, but thats generally easy to figure out, why is that threshold important, that’s a question that requires understanding the intention of the user of engineer who set it up, that’s not something you can just puke out of an auto-doc tool.
I would go so far as to say the inability to capture intention is one of the sharpest edges for low-code tools, it makes the solutions built on then extremely brittle and creates silos of knowledge.
Expanding on that further this is why most auto generated documentation is worth the effort put into it.
All programming languages are some sort of abstraction to the underlying machine language. Low code is just "one more abstraction to machine language".
Previous art in this area would be Lotus Notes (1990's), Hypercard (1980's), and Lotus 123 (1980's).
Low code should be as close to a speaking language as possible. Declarative ideally. e.g. "Create a read-write rest framework for the database table named orders".
An engineer would then go, "Oh, so you know you're missing permissions from the LDAP groups", and then solve that problem, and then figure out how make the LDAP groups map to the low code framework.
It should be easier to understand but lowcode designers seem to like making you jump between 30 different screens instead of having it all in one place. Unspooling a lowcode implementation has got to be one of my least favorite activities.
I think it would be too dense to have everything in one page. I don't remember any example of having it all in one page. Excel for example hides it all in modals.
> here is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control
I think this is an artifact of "source code is text" that our current tools assume (and is invalid IMO).
i think the concept of "source code as AST" or something like that is basically a fine one, but the devil is in the details. your "true source" must continue to support (just off the top of my head):
- precise "decompilation" to readable, idiomatic text
- comments
- line numbers or some semantic equivalent
The goal should be to store the inputs the user has provided. If your no code solution uses png files to encode the input, then store those, not an intermediate textual representation of them.
You do understand that source code as text in current form is most efficient way to do it?
There is no more efficient way unless you go to down to writing assembly or go down to writing 1 and 0.
Everything you build up as low code has to create much more data which takes obviously much more space than high level languages we use today and if you want to do change control - any other data structure will take even more space. Then all of it will be obviously slower because more data is not just a bit more data but at least order or two orders of magnitude more.
LLMs are great at compression but compression with them is not lossless so even if we write behavior to be interpreted by LLM to be executed it might turning out differently each time you run it.
That last one is not a tradeoff we can deal in I would guess 95% of applications. People expect 2+2=4 from applications but they want to say „computer add two numbers that add up to 4” and they don’t really want to to crash because pi+x=4 and LLM went hanging because it is now calculating PI and then it will move to finding X.
So this is why it will never work other way than „source code is text”.
Yes. Onshape is web based. Every change is tracked and can be rolled back. There are versions and branches. Multiple people can work on the same document. The equivalent of a git comment would be a version with a comment.
I think Retool is the best I've seen. They have source control, great documentation, reusable custom code, can tie in external apis for monitoring.
I'm someone that has a little less than junior dev experience (I can hack together a website), but nowhere near the ability to work on production code, yet I was able to be proficient with Retool. The only downside is the cost.
SQL is a DSL for data manipulation and I like it more than non-DSL code (ORM frameworks). Puppet language is a DSL and and I prefer it to Ansible (and alike) Yaml files (yaml is OK for small projects but hard and tedious to maintain for large ones).
Where I use low code is in essentially expert systems, where I need to encode the expertise of some SME. For instance, a lot of places have regulatory compliance burdens. The detailed rules for compliance changes by jurisdiction constantly. Most enterprises setup some sort of requirements to engineer pipeline that everyone’s bitterly unhappy with. It is never fully compliant, has tons of errors, the engineers resent their jobs, and the SMEs resent the engineers. Instead by instrumenting the system with a low code surface area with a policy management system overlaying it you get an excellent platform engineers like to develop, SMEs can author and manage their policies directly, and you capture a rigorous workflow which auditors and regulators really dig. This doesn’t make the engineer less important, in fact they’re much more important to ensure the policies are expressive enough and touch enough business data to ensure the policies are complete. They’re just not playing regulatory policy telephone games in code.
There's definitely something to this. What comes to mind is things like tax compliance. It's a moving target, software devs almost universally do not want that domain knowledge and accountants/lawyers almost universally do not want to represent that knowledge in C++.
My experience with low code is it's easy to get an 80 to 90% solution. Getting that last 10 to 20% may be very difficult. Also, source control, versioning, deployment may be open questions depending on the platform and project. Additionally, you will be locked in to a proprietary platform. Perhaps that is okay.
My personal view is that you're right to be skeptical, but perhaps not for the reasons you mention.
I think that GPT-4 today is good enough to replace about 80% of programmers in the right hands. Put differently: we probably don't need bootcamp grads anymore. The folks who keep their jobs are the ones who intuitively grasp what needs to be done, how to break that ask down into iterative tasks, and how to word those tasks as prompts.
Instead of scrambling to replace application stacks with layers of dumbed down abstractions, we are actually replacing the less experienced people working with application stacks.
Dramatically better outcome for everyone but the people who thought they could take a bootcamp and create generational wealth.
Yes, and I strongly suspect that this is conservative.
Mid-term future iterations will quickly get to 10x and beyond.
Also: your math is based on the random elimination of 80% of programmer roles. I was specifically talking about the elimination of the worst 80% of programmers.
By worst, I mean "the least productive" - not "terrible persons".
Not to be a raging egalitarian, but it’s hard for 20% of workers to have enough business context as 100% of workers to be able to maintain the same level of productivity. Things like gathering requirements become massive bottlenecks to productivity.
As people in this thread have stated elsewhere, there’s a HUGE last-mile problem in programming. For this reason having 20% of the programmers we have now might not be the ticket. We may even want to take some of these mediocre programmers we have now and have them do other duties like say, systems administration. In other words, it could be that hours spent programming decreases rather than the number of workers, to allow for higher communication bandwidth.
Eliminating 80% of programmers does mean that on paper "output per worker per hour" has increased, but it doesn't necessarily follow that you can deliver faster i.e. the output/hour of the business as a whole might stay the same.
In a degenerate case this might take the form of AGI replacing the lower tier workers but doing the same thing at the same speed.
Last night, I spent about five hours just beginning to think about reverse engineering a proprietary file format that packs multiple MIDI files so that I could extract them. There was a whole lot of reading the MIDI spec, searching for strings in a hex viewer and calculating values in a hex to decimal calculator. I didn't write any code in this time, just satisfied myself that it was possible.
Today, I asked GPT to do it for me, and it basically wrote the program for me. I did 1-2 follow-up requests, but I figure that it saved me about 2-3 days of effort. It's relevant to say that I wouldn't have ever actually proceeded with that project because 2-3 days is not a luxury I can afford.
Now, someone who regularly works with MIDI files - heck, someone who regularly works with binary files - could probably do it in a few hours, but this entire process took minutes. It took longer for me to verify the results as perfect than it did to interact with the GPT instance.
I assume that the person who downvoted my comment is a bootcamp grad. Good luck with your future endeavors.
> Now, someone who regularly works with MIDI files - heck, someone who regularly works with binary files - could probably do it in a few hours, but this entire process took minutes.
In my experience, I think this is the key area it exceeds but this isn’t all that common. Hard to imagine 10x productivity boost unless you’re a jack of all trades master of none.
In my experience it’s really useful when you need to do something in a domain you aren’t super familiar with (that you don’t need to become proficient in). But when it comes to the everyday stuff that is my comfort zone I don’t need it. I’m years past looking up syntax or standard library functions for the languages I work in regularly. Every time I’ve tried to use it for a remotely complex algorithm I’ve found it to be much faster to implement by hand then try to debug whatever it got wrong. But for makefiles and gh actions — it’s a true godsend and those things can be major time sinks.
I’m also a developer who really likes to know what my code is doing. If I can’t code something myself I don’t feel comfortable deploying it. But I’ve found this is less universal of a sentiment than I would have imagined in the past year.
It looks like you got lucky and this proprietary format is nothing more than standard MIDI file concatenated together with perhaps some additional data that you are able to ignore +/- some header patch. Frankly this barely qualifies as reverse engineering, at least it represents some trivial case, I mean I'm happy it was easy, but reverse engineering just rarely ever works out so straightforward.
And I would expect someone with competence in scripting language of choice to pop out that script which is a loop and file IO in a few minutes, not hours (assuming it is even correct). And if they have a basic experience working with binary files should know how to google the necessary info about MIDI in seconds.
However looking at the transcript I am also confused because it says (correctly): MIDI files typically start with the header "MThd" followed by the header length, format type, number of tracks, and division. It goes on: "Once a MIDI section is found, we'll extract it according to the MIDI file structure". OK.
But the script does NOT do that it reads 4 bytes starting from offset 8 as a 32-bit big endian "length" which is not "according to the MIDI file structure". The standard format is 2 bytes for a format specifier (AKA type) (0, 1, or 2), and then 2 bytes for the number of tracks.
ie, this is wrong in some way:
# Read the MIDI header and length (14 bytes in total: 'MThd' + 4 bytes for header length + 6 bytes header data)
midi_chunk = io.read(14)
# Extracting the length of the MIDI data from the header
midi_data_length = midi_chunk[8..11].unpack('N').first
So either the proprietary format you're dealing with actually does have a variation on the header of the embedded MIDI file.
If that's the case, I would have to deduct points from ChatGPT because I would expect a competent developer to comment/document this fact, no where in the transcript is this stated.
The other possibility I can see is that if your file is a bunch of standard Type 1 MIDI files, the unpack/parse is going to read that as 65536 + some small amount and will extract files that are all around that size. Since the next step is to look for another MThd magic it will just gleefully resync (I assume these are small segments), but you will end up skipping a whole bunch of files and they will be unceremoniously tacked onto others (which will just be ignored in many players).
So what did it end up being?
If it was the second case, I would also be suspicious that a first crack LLM follow-up "fix" isn't subtly wrong and prone to false splits.
On further thought, how could it be the first case? If it were the outputted files are not standard MIDI. So something is fucked here. Either you have something totally broken or you have further follow-up and we have to believe it is not subtly broken.
"There was a whole lot of reading the MIDI spec, searching for strings in a hex viewer and calculating values in a hex to decimal calculator."
One pearl I would lend in relation to this: use your REPL, that is a productivity accelerator.
I am also sincerely interested in examples of LLMs reverse engineering something with compression or encryption or some checksum, or like some actual complicated structure that has to be teased out (this is something humans do all the time), maybe something that is most easily solved by cracking open the compiled parser, I'm not saying they can't do it, but plainly put this example is too trivial to be interesting and frankly barely qualifies as reverse engineering at least insofar as some sort of RE Turing Test analogue.
----
If the format works the way I think it does (and this is based on nothing more than general experience and this thread, so give me a break), the only robust way to deal with this is to either figure out where in the proprietary data some type of length field is, and clearly ChatGPT was not going in that direction, nor do I...
Ha! First: I appreciate the detailed and thoughtful reply, even if I feel wildly judged.
It's distinctly possibly that you're simply "better" at reverse engineering than I am, which really just means that you might do it frequently and I might do it a few times a decade. This isn't going to keep me up tonight, because my identity isn't tied to being someone who reverse engineers things.
That said, I am pretty thrilled with this solution. I launched a web-enabled version last night and so far about 1100 people have used it to convert 6800 files after I replied to some posts on relevant musician forums around the web.
In my defense, what you're not taking into any consideration is that until 48 hours ago, I'd never looked at the MIDI spec or opened a MIDI file, before. You clearly have a huge amount of domain knowledge that I don't pretend to have.
I also, shocking as it may seem, haven't worked with binary formats in over a decade. I'm a web developer. Binary formats aren't an alien mystery to me, but all of the tools for working with them had to be re-learned as I was working on this.
Anyhow, don't fall into the trap of equating typing speed with the time it takes to learn a domain and consider (design) an approach. If I could think at the speed I can type, John Carmack would have nothing on me.
In the end, I absolutely did get lucky. The proprietary format was, as you proposed, a bunch of 1 track/format 0 MIDI files, bounded by hierarchy metadata that was discarded.
Curiosity did get the better of me and you seem to be spamming every fucking forum so WTH. The longest time it took for anything was waiting for the file to download. The rest of this was about 5 minutes of effort. For the record I do not know the MIDI spec, but it must be one of the most easy to google and well documented things out there, and it's pretty simple likely because it's nearly 40 years old and had to run on potatoes.
The file you could have reverse engineered is not enough of a challenge for an interview question in a low level/systems field and yet you didn't even attempt to do that part. The file hierarchy is absolute offsets and sizes in 4 byte little endian quantities. It took less than 30 seconds to figure that out. How? Find MThd string, what offset is it at, search for that offset as a value. Notice that it is adjacent to a null terminated string with a name ending in .mid and a small quantity. Is that small quantity added to the original offset the start of the next MThd, yes? Done. Anyone with the shittiest hex editor and Ctrl-F can do this in a minute.
Rebuilding the hierarchy is quite simple since the absolute file offset to the entries is adjacent to every directory name.
These midinfo things are interesting they also have some sidecar data. Their content might also be something novel to reverse, that might be worth bragging about.
> I spent almost a week (!) reverse engineering their absurd proprietary format using a hex editor and the MIDI spec.
Since this whole affair seems to have just boiled down to naively iterating for the 4 byte MIDI file magic and then examining the MIDI file metadata you didn't even need all the bluster of breaking out the hex editor and a calculator... Bam https://github.com/jimm/midilib, done (the actual get the MIDI data part can be done in 1 line with a string split).
It's too bad ChatGPT didn't suggest that. That should extract the 3 pieces of metadata you attempted to store in the directories.
Sidebar, nothing here stands out as absurd. It just looks like the obvious solution some working stiff would put together to bundle some data up. They don't obfuscate or do anything that stands out as fucky. Since it's read only its not like not using sqlite is some cardinal sin and they probably gave it all of 3 seconds of thought it deserved.
If you were using this as a learning exercise, fine, but then go back and check your work because your tempos and key signatures are off. eg the tempos that you categorize as 104 have an actual encoded tempo of 571429 µs/beat, or 1.7499 bps or 104.9999 BPM, ie it's what humans would call 105 BPM. Not the end of the world but this is pretty rookie floating point mistake.
And I'm pretty sure you bungled the key signature because at least ones that say Abm are Fm. Why is that... ah you have ignored relative keys. For instance since the meta event FF 59 02 FC 01 has a sf value of 0xFC which is 2's complement -4 that's 4 flats. If this were a major key that would be Ab, but it's a minor key so it's Fm. Oh no, even simple keys are fucked. FF (1 flat, or F major is coming out as Cb, 7 flats), seems like a bungling of 2's complement.
My music education culminated in 2nd chair trombone in the 8th grade and everything I know about the MIDI spec I got from the top 3 hits of google, so caveat emptor.
The only reason I knew it was wrong was because I checked the files with mido (I know you claim ruby is superior, but I seem to be doing ok with dull old python like a rube).
I'd find this article more useful if it named names - I still only have a loose idea in my head as to what qualifies as a "low-code tool". I'd like to know which low-code tools in particular the author has experience with.
Salesforce is the most well-known example but it’s so popular that actually it’s not hard at all to hire experienced developers who know it’s custom server-side language and all its workflow automation and reporting tools. They just hate their lives.
Will add! For what it's worth, it's just my own internal list of tools in this space.
I have a few dozen such lists, I'll review one or two of them when building new things in a specific domain that might benefit from such tooling.
No requirement for open source, but I call it out explicitly in my notes since I do mostly use open source/self-hostable tooling, especially when working with nonprofits.
I'm skeptical of code. Code is needed to create operating systems, database engines, game engines, network servers, graphics and plotting libraries, and other tools that are typically used by software engineers but not end users, and yet most of us are not creating these tools. Most of us are using these tools to serve end users. This isn't a demanding task and it doesn't demand much code. Maybe in the UI, but for the vaunted "business logic"? Please. You don't need reams of code in a general purpose programming language to provide business logic.
Have you done a lot of low code work? I’ve found it just ends up with escape hatches everywhere because the low code platform can’t handle some edge cases or gets too complex for the non engineers to reason with. Other issues are observably, logging, testing, debugging, etc are often impossible or very difficult. Could work for small shops but the enterprises it gets marketed to usually need the normal code.
I do almost all of my work in the database. I don't know if you want to call that "low code" or not. Evidently, it doesn't look like code to many other developers but then again it precedes current low-code platforms by about 40 years, so who knows?
I feel like we are kind of trapped between simplistically polar notions. There's coding as we know it - complex & interwovenines of code - and there's this low code ideology.
Any area of code itself is usually fairly boring & irrelevant. It's systems that accrue mass & complexity. Low code systems sound good by demonizing the weird symbols & incantations that make up the lower level fo coding, but it's this systematic complexity, it's the aggregation of many things happening that makes things opaque & difficult.
Finding patterns to suss out broader-scale understanding is what really tempts me. I don't have super strong vision here, but I'm interested in projects like Node-RED, or even to a degree works like jBPM. Both kind of speak to going beyond coding, but I think the valuable thing here is really that they are assembly toolkits for modules of code & data. They are just examples and not even good ones but this quest, to me, to get to the next levels of computing, is to make clearer portraits of what happens, that either are above to code level, or where the code's running creates higher level observability surfaces.
Code is so easy to demonize. The layering is often so implicit, handlers and DAOs and routes in different layers maybe but with no clear overview layer. Figuring out how to make legible these systems, without diving deep into the code, is what, I think, will make systems less intimidating & will serve as a bridge to make businessfolk and novides better able to intuitively grasp & meddle with these these artificed put before them, with courage. And making people less afraid of the machine, more interested in peeking in and meddling, that's where so much hope lies.
I was involved with a project to decomission a low code on premise platform (Sharepoint 2013). What we found was there was a lot of user enthusiasm to create stuff but when the platform was end of life and had to be decomissioned the users enthusiasm melted away.
The "IT" dept had to spend a fortune re-validating the user requirements for the various applications, documenting and then converting them into a new platform. Obviously a lot of feature creep and previously accepted bugs (no longer accepted now that responsibility was no longer theirs).
A lot of the applications were frankenstein efforts from people over the years - lots of dead code no longer used, no docs etc. As others have mentioned people create mission critical stuff for their project or team, and then leave or be away on extended leave and it breaks etc.
It is so so so close to being a silver bullet tool for quick front end crud that can use your AD to authenticate.
Instead though, it’s got the most absurd pricing model that even their own reps don’t understand and is missing critical or basic features, requiring strange workarounds (fucking UTC dates vs what’s actually in the DB).
They USED to have no way to reuse code as well but they fixed that.
I feel like the issue is they’re still too married to basically low/no code environments.
Having a “I’m going to need to do a custom script in whatever” option would smooth out the edges so much
Power Automate is great, but PowerApps is just a mess where every click in the dev interface takes like 5 seconds. On paper it looks so good, but in practice it is so painful to get that on paper performance and functionality.
For unrelated reasons i've had to hop back in to tweak an app we made a few years ago that's been buzzing along in production ever since. Last time I touched it was more than a year ago.
The actual editor interface is horribly unresponsive, but it seems to fix itself if i close and reopen the browser (firefox). Still it gets worse with time and it used to be no where near this bad.
As bonus points, functionality that is working in production no longer works in the editor! I found that I had to add yet another clause to all my functions because for some reason it no longer pulls all data from a sql table unless you use show columns to specify you do in fact want all of them.
I tried to use PowerApps 3-4 years ago and it was a hot pile of garbage. Slow, impossible to use, underwhelming configuration options, no version control...a developer's nightmare
Is it a programming language, a framework, a compiler/linker/IDL, etc.?
I mean, there are some that could argue that C is "low code," because it isn't Machine Code.
I started in Machine Code, and, these days, write mostly in Swift. Swift seems like "low code," compared to Machine Code.
I assume that they are talking about things like Qt, React Native, Xamarin, Electron, or Ionic (You can tell that I develop host apps).
I write native Apple, using established Interface Builder SDKs, mainly because of the first point. I like to have 100%, and Highest Common Denominator approaches don't allow that.
Also, I find that upgrading can be a problem. I have been in the position of not being able to support the latest OS, because a library hadn't been updated, yet.
It's interesting to think about this in the context of model based development / UML.
Both are situations where people are trying to make the primary source something other than written text. I guess I'm biased, but I think written text has been wildly successful. The more experience I've gained, the more I use text based tools and generally prefer text to alternatives. Even in a recent case where I wanted a diagram, I used graphviz to automatically generate it.
Generally low-code are those gui-driven development tools.
E.g. You can write a data pipeline in SSIS by just dragging boxes around and entering connection details.
Sometimes the abstraction doesn't expose something you'd like, so you add a bit of code (SQL/C# for SSIS), but that's the "escape hatch" rather than the default workflow.
You've also got the approaches like Power Query, where a frontend action is automatically recorded as code (M in that case) , but the code is largely hidden from the end user and only used for source control/escape hatch.
Oh. I have yet to encounter one of these that I'd take seriously.
I have an anecdote, from a friend of mine, from the 1990s.
He was a fairly well-paid team leader for an NYC bank. Ran a C++ shop. He had to wear a tie to work, but was paid enough to buy a house, in his twenties.
In any case, when I knew him, he was an even-higher-paid consultant, working for the same bank. This time, he wore a three-piece bespoke suit to work. He now owned a house in Port Washington, and he was still in his early thirties.
He told me that the bank wanted to release some new server-based product. This was before the Web was really a thing, so it probably was an EDI system (I didn't ask him what, as I knew he wouldn't tell me).
He consulted with his team, and submitted a proposal for a C++ project, taking several months, and costing six figures.
Some VP (banks have lots of those) came in, and had been studying Visual Basic. He also hated the IT teams (they can be like that, you know).
He told his higher-ups that he could write the whole thing, in VB, in half the time, for a quarter of the money (since he'd be doing most of the work, himself).
Stop me, if you've heard this before...
My friend lost the bid. He quit the company (along with most of his team), and traveled around the world for a couple of years.
When he got back, the bank was in a shambles. The VP had screwed the pooch in a big way, and was long fired. Attempts to redo the project were dumpster fires, since they no longer had any trained engineers on staff, and they couldn't hire new staff.
I think the point are valid but it comes back to a much simpler idea - what’s the right tool for the job. Figure out what you want to do then find the right level of abstraction to get it done. And salespeople are one data point, generally not to be relied upon. Or have I over simplified?
I agree. It isn't useful to think of "low code" or not. You think of what the tool offers and if it can be extended easily to do what you want. If you choose it and it isn't as advertised or doesn't fit, it was the wrong choice. We rely on all sorts of "low code" stuff and it works great because it's battle proven and provides the right abstractions. "Low code" is a misnomer, just say "esoteric specialized tool that isn't customizable".
As someone who worked at a low code workflow SaaS, I agree with this. The automation is a commodity, the value was in discovering that people wanted to talk to the LLM to orchestrate their automation vs bespoke workflow design UX. You can also decouple models from API scaffolding like Gorilla LLM (or rather, broad models that dive deep into use case specific models on demand).
Doesn’t matter, as long as users are getting value. How you solve the problem is less important than solving the problem. I expect LLM output to improve over time, along with mechanisms to coax deterministic behavior.
Software Engineering will be fine: it has been eating itself since Lisp invented macros. Maybe software engineering should be called “The operations of automation using data on general purpose machines”. That will not die. It will look different though.
Power Automate Cloud already has an AI builder, you type in "At 4pm every day check my Outlook inbox for an email from Suzie Snowflake, and if it says Critical, then check Sharepoint for a file from Integration Services and if its contents contain the string "Blorb" then send an email to Escalation"
the result is often slightly wrong, but if someone in MS management is paying attention and could get it to ChatGPT-python level of accuracy, it would take over an enormous amount of stuff.
309 comments
[ 4.4 ms ] story [ 274 ms ] threadSure there exist applications that do equivalent things, but when people start using the word 'low-code' to describe such an application they suddenly get the weird idea that the hard part of coding is typing the damn syntax and that if only you put a GUI in front of it they can do it themselves.
Conveniently forgetting that people have made the exact same promises about the first IDEs. Pretty sure there's an ad to that effect for Turbo Pascal somewhere.
As the other comment said, less code tools for developers can be quite helpful.
We've got all this spaghetti code.
-- I know, we'll rewrite it as a rules engine!
...
We've got all this spaghetti yaml.
What happens all too often is a hack week project that brings in some low code functionality in some simple use case gets shown off and kicks off a bigger effort. But then the edge cases buried in the spaghetti code come up in some way tangential to the low code approach, so it gets hacked in. This happens over and over, and eventually your low code model is just as spaghettified as your code was, except now that spaghetti spans yaml, some interpretation layer, and the remaining two thirds of the original code that you haven't migrated yet.
For this I'll coin my law of declarative intentions: the resulting low code cannot be simpler than well factored code itself.
In my experience, low-code is “easy software development” but without the guard-rails of version control, debugging, open standards, local development, unit-testing etc etc…
These are the things that really matter as software complexity grows…
I have been using Node-RED[1] for some time now and have began creating a visual version control concept. The difficulty is differentiating between visual changes and logical changes - visual changes aren't usually the cause of bugs.
[1]="Low-code programming for event-driven applications" - https://nodered.org
The rest is the nth failed tentative to makes users jailed by ignorance selling the idea people can do thing without knowing things. It will fail like any other tentative done before.
It is basically a database, reporting tool, IDE and half a dozen other things all rolled into one giant mess.
They had looked at getting a proper purpose-built system in place, but I don't know what happened after that.
From a business standpoint it's probably the single most useful software platform ever invented.
First: in classic systems the OS is a single application/framework where anything or nearly anything is accessible by end users, so there is no special integration limit that force devs to reinvent the wheel to have anything in a single modern app and reinvent it in bad way since they have no time nor resources even at the big tech sizes, plus the need to invent ways to circumvent system design limits.
Being a single app means if I have a CAS installed I can solve an ODE in an email just typing it and pass the math expression to a relevant CAS function, no need to reinvent a basic or less basic calculator. No need to know all the stuff about making it. I just access the relevant functions written by some expert and tuned for that purpose. The dev does not need to know, it's the user who know and use.
Secondly means an incredible simplification. Let's talk for instance about a Plan9 mail client: what kind of beast is? Well it's just a base64-to-text reader and writer. Nothing more. The connection to the webserver is just a universal system connection to a remote file server, a remote filesystem mounted somewhere under the local root. All you need to do is knowing how to access a local fs, read text files, read/encode base64. Nothing more. Sending an email is just saving a text file with a given name in the right place. Publish a website is the same BTW, so it's sharing a file. Being a single app-framework means that anything is simpler, there is not much duplication of functions, only tuning.
Now try to see an example of modern Emacs in action like https://youtu.be/B6jfrrwR10k how much complicated is creating a slide? Well just zoom some org-mode text. A table like a spreadsheet? It's just text and can be passed to any programming language supported by org-babel as data.
Doing so meaning no lock-in possible and the end-user in control, that's why all the modern IT industry starting back then with the not-so-modern IBM, have demolished this, but the result is a mess. A decade after another we tend to the old model wasting gazillions of resources to keep up an untenable business model.
Eventually we moved to nextjs and vercel. We are faster with iterating on our landing page as well as any engineer can be pulled into the implementation.
All lowcode platforms are great in basic usecases but fails when the usecases because complex.
We’ve moved to various platforms over the years so that our designers with a touch of web knowledge can build our marketing site. They’re happy bc they don’t have to wait to make changes and devs are happy bc they don’t have to work on marketing sites.
The designers actually enjoy the constraints to a degree bc it simplifies their job as well.
But like I said, it’s just a simple static marketing site
As you can see, it is more than a static website. Implementing this in webflow was nightmare.
https://webflow.com/blog/webflow-at-webflow
But the big issue seems to be that they're not marketing anything to the developers. They're marketing everything at the managers -- particularly the kind of manager that doesn't really understand software.
Although if your team is all engineers pushing to git every day, I could totally see how they'd find Webflow frustrating (since a UI instead of a codebase would be a huge pattern-interrupt for their daily workflow).
That said, once your startup grows, what typically happens is you'll need to bring in specialized marketing/sales/design/SEO folks (vs. Swiss army knife SV startup hustlers). Their hours are far cheaper than engineer-hours and they're also much better at marketing/sales/design/SEO work, like your landing pages & blog.
They will not be able to change anything on your slick NextJS/Vercel setup , and will be filing tickets daily and overwhelming your engineers.
Then you'll probably have to resort to some nightmarishly bloated "headless CMS," and waste a huge amount of time on implementation, and then it will be impossible to change.
That's when it makes sense to switch back to something like Webflow.
I've seen this happen multiple times.
Obviously it's not actually low code, it's 100% code, but it creates a space without a lot of the complexity and ceremony of 'real' software development. I don't write tests, I don't future-proof, I don't set up deployment or monitoring machinery, I don't worry about anything except solving a small, well-defined problem quickly.
It's definitely not a good approach to everything. But it's quite common for one of my users to say something like "I need a dashboard showing how the current reactor temperatures compare to the averages for yesterday, and also the available cooling water for each one", where that's all data we have existing websocket feeds for, and I can get that to them very quickly without it becoming formal feature development.
Lack of testing and monitoring means the products often break. But when they do it's typically benign - the page doesn't load, or shows no data, and if a user needs to use it, they'll complain, and I can fix it.
If a page ever got too complicated, or too critical, I might want to port it onto real software. But that hasn't happened yet.
Much of this feels like needless complexity, but its ubiquity in almost every stack points to something fundamental, in my opinion: the classic 80/20 rule. That last, irreducible 20% complexity is where the dragons lie. Expectations for software have grown, and boundless flexibility is table stakes.
If you want to build a shed, go to your local hardware store and buy a kit set.
If you want to build a skyscraper, get an architect, some engineers and a competent building company.
Building a simple shed isn't hard, if you can handle assembling the kit you can buy and cut the basic materials yourself. The trickier parts like getting it watertight or installing doors and windows have to be done either way, all the kit gets you is a bundle of inferior materials and a bit of time savings cutting studs.
Low code is very easy to sell. All you have to do is make a boogie man out of the IT department, and play on existing frustrations. Then play a demo where a sign up form is made in ten minutes and say your IT department would have taken 3 months. You just make sure to walk the happy path during the demo and don’t stress the tool.
Many things could be low code. Why do you need a developer for a sign up form if you are just making an API call in the end? Wiring up a form shouldn’t take html, js, and a serverside language.
On the flip side, don’t put your core business logic in low code. Low code builders assume anything complex will be offloaded to a specialized system. The best ones provide escape hatches by calling remote APIs or calling a code module.
Low code gets sold to smaller customers because it’s touted as a developer replacement. But really it’s most powerful in larger enterprises where individual teams may have technical people who have business knowledge but not much much IT power. It’s easy to get them to configure something in a SaaS they already use, than get a custom solution from IT. Also low code often comes with guardrails and permission sets tied to existing users.
I see low code as a tech equivalent of the last mile problem in logistics. It addresses a large number of concerns with simple tools, but doesn’t scale well and needs to work in tandem with a stronger central system. End to end low code is a trap, but low code at the fringes is a multiplier.
You can tell when your last warehouse is close to the customer by looking at a map. You can't tell when your tool is close to what the user needs with nearly the same accuracy. There are a ton of gotchas, and as part of the "last mile", it's now your responsibility.
You also are at the whim of the SaaS vendor to give you the help you need. If they can't do something you think it should, good luck making a hacked workaround to function as it must.
Imagine I bought a vacuum cleaner expecting it to clean all my floors, and never finding out what i bought was a pack of pocket tissues.
Pocket tissues are useful but not when im trying to clean my floor with them.
If you just deleted a bunch of processes, or just reserved it to when it actually matters, you wouldn't need to pay a low code vendor to basically allow your team to do their job.
That escape hatch is absolutely necessary for longevity though. It lets you keep your low-code environment simple because you can leave it and write real code when necessary, rather than forcing everything into an over-complicated and under-capable custom thing with no editor tooling.
Whenever I've discussed this, the common theme is that business users continue to request features that would be easily achieved in the low-code platform being used. It's hard to blame them; that's been standard procedure for them for their entire career.
But if you're not strict about saying "no", you still end up writing all the same methods but now on top of that you have a GUI that's not providing any value. Or maybe worse, your developers end up maintaining all of the low-code stuff too when they could have just written the code, switching context pointlessly and (probably, depending on the platform) not using source control.
* Where was the design doc?
* Where were the alerts?
* Where was the code review?
* Why didn't you write an integration test?
* What do you mean it just rolled out to production instantly?
When we're considering options in advance of building something, it's a more time-efficient, less wasteful alternative to programming. But having built it, everyone acknowledges that what we have done is programming, and now they wonder why we've programmed so badly.
Maybe the standard IDEs, Git, code review, CI, metrics, and incremental deploy workflows were fine actually?
Without discipline, any programming environment can lead to failures.
It is true that there aren't any well-defined workflows for using an arrow-boxes environments but that does not mean that these environments don't support specific workflows.
All the components and modules that low code tools provide should be nothing more than an onboarding tutorial like the first few levels of Factorio, before letting the engineering team loose hand in hand with the users. It shouldn’t be an escape hatch, it should be the front door.
As such all these low code tools make the mistake of making it really difficult to bring the engineering team into the fold: modularization, logging, debugging, version control, and development tools are absolute garbage so instead of engineering providing a few sane company specific building blocks that they can tend and nurture, it inevitably turns into a shitshow because you can’t use a tool that ultimately depends on the IT department to fix the IT department!
The best “low-code” tools have already been around for over a decade: it’s the headless CMS and autogenerated admin pages ala Django and Wagtail. They’ve been focused on solving the content management problem for e-commerce and marketing, but IMO it’s the write path for other groups too. The engineers write the pages and blocks and components while defining an input/configuration schema for an automated tool that is usable by laymen. Up the level of abstraction to a well curated (by the engineers at the customer level) IFTTT layer and bam, you’ve 95% of use of low code without the 5% that inevitably ruins it.
Per end user rather than per developer means they're far too expensive to introduce as a general IT toolbox item, they need to be part of a major strategic project where the $5-30/month per staff user has a hope of being justified.
But that also often takes it outside the "IT Dept", which is often just "infrastructure and pc fleet" support, not development ( at least, that's my experience ). IT might do internal scripting and some service interface tooling, but business tooling and software is rarer, that's usually either dev teams or ERP teams. The ERP teams will already using ERP platform tooling, so that further narrows the market.
I don't have a good solution for this, but it's always been the hurdle I've tripped on working for medium size enterprises.
There would seem to be an opportunity for "open source platform, commercial training and support" here, but vendors seem to gravitate to per user head and cloud only for more immediate revenue and easier support., but again many enterprises still have huge internal only IT landscape's, because cloud is still expensive and the value often isn't seen in relatively static envs.
It's possible this niche has been filled now too, it's been a while since I looked...
Possibly they can be introduced on a "just those who need it" basis, but honestly that's just so bloody tiring for internal tools, not to mention demotivating as you can no longer build tools for "everyone or anyone", it's back to specific narrow business cases, not IT empowerment, but narrow business case also means your usually competing with cots tools or consultants.
It's also because knowing where the escape hatch and how to use it requires greater than average development skill and finesse and it isn't at all obvious when this is required.
The people who use these platforms aren't usually able to tell what kind of problem requires a developer and what kind of problem requires them doing just a bit more research. They're usually vaguely aware that the limit is out there somewhere but in the specific instances when they hit it they often don't know it's happened.
I've also seen some low code platforms get a little excitable about the idea of nearly or even fully reinventing the turing complete programming language to introduce more flexibility to their platform and make that their escape hatch. This is when things go really downhill.
https://en.wikipedia.org/wiki/Ironies_of_Automation
The success of low code implementations often comes with a curse of investing man-years of development effort to build increasingly complex applications in proprietary low code languages executable in a closed ecosystem (and commercial terms) of a specific vendor.
I believe there is a place for enterprise app platforms which are a) open source, b) not based on proprietary languages, c) with low code capabilities, fueled with AI code generation, d) runnable anywhere without staying dependent on typically user-based commercial model.
Shameless plus: we are working on such a thing, and competing with traditional low code platforms is not easy, I could tell a few stories about what we have tried, what works and what not really, if you are interested. I would be also extremely thankful for any comments and hints you may have, see https://openkoda.com
That's the definition of vendor lock-in. Once the vendor has it's hooks in your organization, good luck removing it. Sometimes it's just the cost of doing business, but the more the hooks, the greater the chance that a vendor triples or quintuples the cost of their product that affects your organization's secret sauce.
I feel like the goal of low-code solutions is to get you over the barrel. Much in the same way AWS tries to get into your company's operating costs.
I create nocode plugins on a specific proprietary stalled platform, for a living, for a few years now, so I am definitely aware of the pitfalls in the area.
For me the problem is that the API to it got created in a nice format but then got abandoned, if they just listened over the years and added the changes we third party devs needed it would have been great.
Example from us using Azure Data Factory: You can add a step to call out to an API, which we did for a data flow that had a lot of calls. Performance was atrocious. Dug into it, and the API getting called was replying in 100ms or so, but ADF's "escape hatch" was adding 5-10 seconds of overhead to send the POST and parse the HTTP status code.
Microsoft Support said that's normal, expected behavior for the service.
In the end, we had to write an additional batching layer ourselves.
I'd be really interested in knowing how often escape hatches like that are actually used. I'd guess it's less than a fraction of a percent, if ever.
And most apps use about 10 to 20 plugins.
It eventually turned out there was a prioritisation problem rather than a development capacity problem.
One might think you need all of it right here right now - but in reality if you build 20% that is really really needed you get 80% or I could bet even 95% of actual work done needed for the company to improve productivity/performance etc.
It's not just business knowledge, it allows the people who are most committed to project success to do the work.
I think that's the real pain point with IT departments in large organizations. They aren't feeling the pain that made you need the software in the first place.
Did you have any positive experience on the after seeking low code?
Oh my... Many, many, maaaany reasons.
For example, your entire stack is built in a certain way and you don't want to introduce new dependencies.
What if your cicd requires your config and code is separate and that you build a code artefact, and let's say 3 config artefacts (dev, cert, prod), all these are then uploaded to a central repo and handed over to some proprietary security/code scanning thing every time you merge new code. Then let's say your deployment is done the same way, you have your "deployment config" artefacts for each environment, but an infrastructure team manages all the infrastructure-as-code artefacts that take your config.
I worked in a bunch of big companies each having their own version of such process.
In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.
>In such an environment, creating an "example project" that contains all of the scaffolding required and just writing that sign on form is going to take waaaaay less time than even initial planning how to integrate the "no code" tool into our processes.
I've also seen the opposite. Someone in the org wants a simple site. Maybe a sign up form, or CMS/wiki for internal docs, etc. The dev team says "sure, that'll be 6 months". A large part of which is constrained capacity - the devs need to fit it in alongside a buch of other stuff. Another part is tech choice: the corporate stack uses e.g. React on the front end, calling web services written in Java, backed off to Postgres for storage (or whatever). The devs estimate for building the CMS/wiki/whatever from scratch - because it has to fit the tech stack.
At that point the (internal) customer screws up their face and utters all the familiar frustrations about "IT". Someone somewhere mentions to them that there's a way to sidestep it all, and do it yourself. In their position it's very hard not to see that alternative as attractive.
It's a hard problem. That same internal customer will similtaneously rail against the recharge in their budget for IT. It's a cost: a drag on their P&L. IT says they're under-resourced, and they could do it quicker with more people - but that would increase the P&L drag. Vicious circle.
Software is a sociotechnical endeavour yet we too often focus on the technical and ignore the social aspect. Yet "Low Code" and similar emanate primarily from the social side. Coming back to your post though, not exclusively. Development teams can be equally culpable when zeroing in on tech stacks that aren't a good fit for the problems at hand. Or, perhaps, stacks that are a good fit for the problems they were chosen to solve - but not so much when the new requirement comes along.
Of course, low code is no panacea either. Most non-technologists have no perception of the need for ongoing evolution, even if there's no new feature development. Patching/upgrading is a must. And new features always emerge - most after the original "citizen developer" has moved on / lost interest / whatever. So the whole shebang gets foisted on IT, who are expected to operate and maintain it. Usually with no tests, automated builds, documentation, ...
It's pernicious. At heart, though, it's primarily a social problem that needs a good underlying relationship between the customers/users and the developers. It's Conway's Law. Of course tech choice still matters. But no tech stack is going to magic away problems rooted in organisational friction.
I started my career as a Solutions Consultant. Our primary customers were small business units in large organizations that were frustrated with “IT” and looked externally to solve their problem. Low code is a variation on this strategy.
Our delivery time estimates always beat IT estimates and our costs were often less.
Maybe because we were seen as a competitor to IT, or maybe some manager was being sneaky our first interactions with IT was usually after the engagement contract was signed. (None of these projects had RFP/RFQs)
During the discussions with IT was when the hard parts of the engagement really happened. It was then we learned about the compliance requirements. Security, data integrity, availability, platform standards, ci/cd, pmi, etc…. These unknowns often dragged out our delivery times and skyrocketed our billable hours. Putting us equal to or behind internal IT.
In my experience at large organizations Compliance is more closely aligned with legal than IT but is often an a function of IT. The rules set forth by the legal teams are enforced through technical/process controls by IT. This makes IT look like the ‘problem’ went in fact they are just following mandates set forth be legal.
It’s often easy for a business unit to complain about IT preventing revenue growth and get an exception. If a business unit complained to upper management that legal wouldn’t let them do something I doubt exceptions would be granted as easily.
I’d suggest that compliance be its own department and review all external tools or vendors instead of IT. This would put external consultants or low-code solutions on par with internal IT. If would also shortened the feedback loop between those creating the rules and those it causes grief.
I feel like you just explained how salespeople can scam decision-makers into thinking low-code solutions will do more than they can do, and in no way countered any of the arguments in the OP about it's dangers.
Ironically it's the OT and logistics people who've figured this out, with low / no code solutions fit for purpose, which don't necessarily run in the cloud, which have full microservice / SQL integration... and baked in OT drivers, RFID and bar codes.
Kind of like “consultants” coming in with advice on how to improve the organization?
This falls apart when:
* legacy systems/data must be integrated
* the requirements get interesting
There is just no substitute for a good working understanding of the tools, and that means staff that can go past the low-code facade when needful.
* there is like no source control, or if there is the source controlled thing is an unreadable artifact which generally doesn't belong in source control.
* the workflows are poorly if at all documented.
* they still require a lot of custom code but that code isn't as reusable, tested or testable * they often require a proprietary runtime, worse this may only run on windows
* they are difficult/impossible to instrument and so are difficult or impossible to monitor. Or if they do have monitoring it is going to work differently than the rest of your stack - likely using email based alerting which isn't ideal.
* the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
The only tool that was semi-reasonable here was Looker which isn't exactly marketed as low code but at least in the version of the product I used did integrate with source control. Though generally the people writing lookml were still engineers.
I'm much more a fan of composable platforms that compress complexity but still make it possible to delve, customize and extend when necessary.
Ideally it would be easier to understand if there's less code involved. Things should be more declarative, or the low-code solutions would generate good descriptions for what is actually happening.
> * the work is still 100% done by engineers either way, I've never seen a low code or DSL be picked up by non-engineers. (I am also skeptical towards DSLs)
Or worse: "Why does this connection to this server fail with SSL Certifcate Invalid? Oh, nm, we'll just uncheck the SSL validation box."
But really you are missing a key piece of the puzzle, it matters less what is happening and more why. Sure a low code tool could churn out a textual description to say if the value of some variable is < some threshold branch to X else branch to Y, but thats generally easy to figure out, why is that threshold important, that’s a question that requires understanding the intention of the user of engineer who set it up, that’s not something you can just puke out of an auto-doc tool.
I would go so far as to say the inability to capture intention is one of the sharpest edges for low-code tools, it makes the solutions built on then extremely brittle and creates silos of knowledge.
Expanding on that further this is why most auto generated documentation is worth the effort put into it.
Previous art in this area would be Lotus Notes (1990's), Hypercard (1980's), and Lotus 123 (1980's).
Low code should be as close to a speaking language as possible. Declarative ideally. e.g. "Create a read-write rest framework for the database table named orders".
An engineer would then go, "Oh, so you know you're missing permissions from the LDAP groups", and then solve that problem, and then figure out how make the LDAP groups map to the low code framework.
That's kinda the sorta thing we do already.
I think this is an artifact of "source code is text" that our current tools assume (and is invalid IMO).
Otherwise I agree
- precise "decompilation" to readable, idiomatic text - comments - line numbers or some semantic equivalent
There is no more efficient way unless you go to down to writing assembly or go down to writing 1 and 0.
Everything you build up as low code has to create much more data which takes obviously much more space than high level languages we use today and if you want to do change control - any other data structure will take even more space. Then all of it will be obviously slower because more data is not just a bit more data but at least order or two orders of magnitude more.
LLMs are great at compression but compression with them is not lossless so even if we write behavior to be interpreted by LLM to be executed it might turning out differently each time you run it.
That last one is not a tradeoff we can deal in I would guess 95% of applications. People expect 2+2=4 from applications but they want to say „computer add two numbers that add up to 4” and they don’t really want to to crash because pi+x=4 and LLM went hanging because it is now calculating PI and then it will move to finding X.
So this is why it will never work other way than „source code is text”.
I'm someone that has a little less than junior dev experience (I can hack together a website), but nowhere near the ability to work on production code, yet I was able to be proficient with Retool. The only downside is the cost.
What you would suggest instead of DSL?
SQL is a DSL for data manipulation and I like it more than non-DSL code (ORM frameworks). Puppet language is a DSL and and I prefer it to Ansible (and alike) Yaml files (yaml is OK for small projects but hard and tedious to maintain for large ones).
I think that GPT-4 today is good enough to replace about 80% of programmers in the right hands. Put differently: we probably don't need bootcamp grads anymore. The folks who keep their jobs are the ones who intuitively grasp what needs to be done, how to break that ask down into iterative tasks, and how to word those tasks as prompts.
Instead of scrambling to replace application stacks with layers of dumbed down abstractions, we are actually replacing the less experienced people working with application stacks.
Dramatically better outcome for everyone but the people who thought they could take a bootcamp and create generational wealth.
Mid-term future iterations will quickly get to 10x and beyond.
Also: your math is based on the random elimination of 80% of programmer roles. I was specifically talking about the elimination of the worst 80% of programmers.
By worst, I mean "the least productive" - not "terrible persons".
Not to be a raging egalitarian, but it’s hard for 20% of workers to have enough business context as 100% of workers to be able to maintain the same level of productivity. Things like gathering requirements become massive bottlenecks to productivity.
As people in this thread have stated elsewhere, there’s a HUGE last-mile problem in programming. For this reason having 20% of the programmers we have now might not be the ticket. We may even want to take some of these mediocre programmers we have now and have them do other duties like say, systems administration. In other words, it could be that hours spent programming decreases rather than the number of workers, to allow for higher communication bandwidth.
Eliminating 80% of programmers does mean that on paper "output per worker per hour" has increased, but it doesn't necessarily follow that you can deliver faster i.e. the output/hour of the business as a whole might stay the same.
In a degenerate case this might take the form of AGI replacing the lower tier workers but doing the same thing at the same speed.
Today, I asked GPT to do it for me, and it basically wrote the program for me. I did 1-2 follow-up requests, but I figure that it saved me about 2-3 days of effort. It's relevant to say that I wouldn't have ever actually proceeded with that project because 2-3 days is not a luxury I can afford.
https://chat.openai.com/share/82e85eb9-1f80-46d5-a75c-29a437...
Now, someone who regularly works with MIDI files - heck, someone who regularly works with binary files - could probably do it in a few hours, but this entire process took minutes. It took longer for me to verify the results as perfect than it did to interact with the GPT instance.
I assume that the person who downvoted my comment is a bootcamp grad. Good luck with your future endeavors.
In my experience, I think this is the key area it exceeds but this isn’t all that common. Hard to imagine 10x productivity boost unless you’re a jack of all trades master of none.
In my experience it’s really useful when you need to do something in a domain you aren’t super familiar with (that you don’t need to become proficient in). But when it comes to the everyday stuff that is my comfort zone I don’t need it. I’m years past looking up syntax or standard library functions for the languages I work in regularly. Every time I’ve tried to use it for a remotely complex algorithm I’ve found it to be much faster to implement by hand then try to debug whatever it got wrong. But for makefiles and gh actions — it’s a true godsend and those things can be major time sinks.
I’m also a developer who really likes to know what my code is doing. If I can’t code something myself I don’t feel comfortable deploying it. But I’ve found this is less universal of a sentiment than I would have imagined in the past year.
That said, the simplest way to understand the code is to read it before committing it.
Meanwhile, the tooling will only continue to get better as larger and larger context windows are introduced.
And I would expect someone with competence in scripting language of choice to pop out that script which is a loop and file IO in a few minutes, not hours (assuming it is even correct). And if they have a basic experience working with binary files should know how to google the necessary info about MIDI in seconds.
However looking at the transcript I am also confused because it says (correctly): MIDI files typically start with the header "MThd" followed by the header length, format type, number of tracks, and division. It goes on: "Once a MIDI section is found, we'll extract it according to the MIDI file structure". OK. But the script does NOT do that it reads 4 bytes starting from offset 8 as a 32-bit big endian "length" which is not "according to the MIDI file structure". The standard format is 2 bytes for a format specifier (AKA type) (0, 1, or 2), and then 2 bytes for the number of tracks.
ie, this is wrong in some way:
So either the proprietary format you're dealing with actually does have a variation on the header of the embedded MIDI file. If that's the case, I would have to deduct points from ChatGPT because I would expect a competent developer to comment/document this fact, no where in the transcript is this stated.The other possibility I can see is that if your file is a bunch of standard Type 1 MIDI files, the unpack/parse is going to read that as 65536 + some small amount and will extract files that are all around that size. Since the next step is to look for another MThd magic it will just gleefully resync (I assume these are small segments), but you will end up skipping a whole bunch of files and they will be unceremoniously tacked onto others (which will just be ignored in many players).
So what did it end up being? If it was the second case, I would also be suspicious that a first crack LLM follow-up "fix" isn't subtly wrong and prone to false splits.
On further thought, how could it be the first case? If it were the outputted files are not standard MIDI. So something is fucked here. Either you have something totally broken or you have further follow-up and we have to believe it is not subtly broken.
"There was a whole lot of reading the MIDI spec, searching for strings in a hex viewer and calculating values in a hex to decimal calculator."
One pearl I would lend in relation to this: use your REPL, that is a productivity accelerator.
I am also sincerely interested in examples of LLMs reverse engineering something with compression or encryption or some checksum, or like some actual complicated structure that has to be teased out (this is something humans do all the time), maybe something that is most easily solved by cracking open the compiled parser, I'm not saying they can't do it, but plainly put this example is too trivial to be interesting and frankly barely qualifies as reverse engineering at least insofar as some sort of RE Turing Test analogue.
----
If the format works the way I think it does (and this is based on nothing more than general experience and this thread, so give me a break), the only robust way to deal with this is to either figure out where in the proprietary data some type of length field is, and clearly ChatGPT was not going in that direction, nor do I...
It's distinctly possibly that you're simply "better" at reverse engineering than I am, which really just means that you might do it frequently and I might do it a few times a decade. This isn't going to keep me up tonight, because my identity isn't tied to being someone who reverse engineers things.
That said, I am pretty thrilled with this solution. I launched a web-enabled version last night and so far about 1100 people have used it to convert 6800 files after I replied to some posts on relevant musician forums around the web.
In my defense, what you're not taking into any consideration is that until 48 hours ago, I'd never looked at the MIDI spec or opened a MIDI file, before. You clearly have a huge amount of domain knowledge that I don't pretend to have.
I also, shocking as it may seem, haven't worked with binary formats in over a decade. I'm a web developer. Binary formats aren't an alien mystery to me, but all of the tools for working with them had to be re-learned as I was working on this.
Anyhow, don't fall into the trap of equating typing speed with the time it takes to learn a domain and consider (design) an approach. If I could think at the speed I can type, John Carmack would have nothing on me.
In the end, I absolutely did get lucky. The proprietary format was, as you proposed, a bunch of 1 track/format 0 MIDI files, bounded by hierarchy metadata that was discarded.
The file you could have reverse engineered is not enough of a challenge for an interview question in a low level/systems field and yet you didn't even attempt to do that part. The file hierarchy is absolute offsets and sizes in 4 byte little endian quantities. It took less than 30 seconds to figure that out. How? Find MThd string, what offset is it at, search for that offset as a value. Notice that it is adjacent to a null terminated string with a name ending in .mid and a small quantity. Is that small quantity added to the original offset the start of the next MThd, yes? Done. Anyone with the shittiest hex editor and Ctrl-F can do this in a minute. Rebuilding the hierarchy is quite simple since the absolute file offset to the entries is adjacent to every directory name. These midinfo things are interesting they also have some sidecar data. Their content might also be something novel to reverse, that might be worth bragging about.
> I spent almost a week (!) reverse engineering their absurd proprietary format using a hex editor and the MIDI spec.
Since this whole affair seems to have just boiled down to naively iterating for the 4 byte MIDI file magic and then examining the MIDI file metadata you didn't even need all the bluster of breaking out the hex editor and a calculator... Bam https://github.com/jimm/midilib, done (the actual get the MIDI data part can be done in 1 line with a string split). It's too bad ChatGPT didn't suggest that. That should extract the 3 pieces of metadata you attempted to store in the directories.
Sidebar, nothing here stands out as absurd. It just looks like the obvious solution some working stiff would put together to bundle some data up. They don't obfuscate or do anything that stands out as fucky. Since it's read only its not like not using sqlite is some cardinal sin and they probably gave it all of 3 seconds of thought it deserved.
If you were using this as a learning exercise, fine, but then go back and check your work because your tempos and key signatures are off. eg the tempos that you categorize as 104 have an actual encoded tempo of 571429 µs/beat, or 1.7499 bps or 104.9999 BPM, ie it's what humans would call 105 BPM. Not the end of the world but this is pretty rookie floating point mistake. And I'm pretty sure you bungled the key signature because at least ones that say Abm are Fm. Why is that... ah you have ignored relative keys. For instance since the meta event FF 59 02 FC 01 has a sf value of 0xFC which is 2's complement -4 that's 4 flats. If this were a major key that would be Ab, but it's a minor key so it's Fm. Oh no, even simple keys are fucked. FF (1 flat, or F major is coming out as Cb, 7 flats), seems like a bungling of 2's complement. My music education culminated in 2nd chair trombone in the 8th grade and everything I know about the MIDI spec I got from the top 3 hits of google, so caveat emptor.
https://en.wikipedia.org/wiki/Key_signature https://www.music.mcgill.ca/~ich/classes/mumt306/StandardMID...
The only reason I knew it was wrong was because I checked the files with mido (I know you claim ruby is superior, but I seem to be doing ok with dull old python like a rube).
Als...
Triple their payments, and they will be fine. :-)
* Retool - https://retool.com (not OSS)
* OpenBlocks - https://github.com/openblocks-dev/openblocks
* Saltcorn - https://saltcorn.com/
* Interval - https://interval.com/
* Bracket - https://www.usebracket.com/
* Windmill - https://docs.windmill.dev/
* Budibase - https://budibase.com/
* AppSmith - https://www.appsmith.com/
* ToolJet - https://www.tooljet.com/
I only have direct experience with AppSmith.
I have a few dozen such lists, I'll review one or two of them when building new things in a specific domain that might benefit from such tooling.
No requirement for open source, but I call it out explicitly in my notes since I do mostly use open source/self-hostable tooling, especially when working with nonprofits.
I jest, of course.
If you're using a tool like Oracle APEX you're doing Low Code, bar the few escape hatches.
Occasionally, I use a procedural programming language in the database. Usually, I don't.
Any area of code itself is usually fairly boring & irrelevant. It's systems that accrue mass & complexity. Low code systems sound good by demonizing the weird symbols & incantations that make up the lower level fo coding, but it's this systematic complexity, it's the aggregation of many things happening that makes things opaque & difficult.
Finding patterns to suss out broader-scale understanding is what really tempts me. I don't have super strong vision here, but I'm interested in projects like Node-RED, or even to a degree works like jBPM. Both kind of speak to going beyond coding, but I think the valuable thing here is really that they are assembly toolkits for modules of code & data. They are just examples and not even good ones but this quest, to me, to get to the next levels of computing, is to make clearer portraits of what happens, that either are above to code level, or where the code's running creates higher level observability surfaces.
Code is so easy to demonize. The layering is often so implicit, handlers and DAOs and routes in different layers maybe but with no clear overview layer. Figuring out how to make legible these systems, without diving deep into the code, is what, I think, will make systems less intimidating & will serve as a bridge to make businessfolk and novides better able to intuitively grasp & meddle with these these artificed put before them, with courage. And making people less afraid of the machine, more interested in peeking in and meddling, that's where so much hope lies.
The "IT" dept had to spend a fortune re-validating the user requirements for the various applications, documenting and then converting them into a new platform. Obviously a lot of feature creep and previously accepted bugs (no longer accepted now that responsibility was no longer theirs).
A lot of the applications were frankenstein efforts from people over the years - lots of dead code no longer used, no docs etc. As others have mentioned people create mission critical stuff for their project or team, and then leave or be away on extended leave and it breaks etc.
It is so so so close to being a silver bullet tool for quick front end crud that can use your AD to authenticate.
Instead though, it’s got the most absurd pricing model that even their own reps don’t understand and is missing critical or basic features, requiring strange workarounds (fucking UTC dates vs what’s actually in the DB).
They USED to have no way to reuse code as well but they fixed that.
I feel like the issue is they’re still too married to basically low/no code environments.
Having a “I’m going to need to do a custom script in whatever” option would smooth out the edges so much
Power Automate is great, but PowerApps is just a mess where every click in the dev interface takes like 5 seconds. On paper it looks so good, but in practice it is so painful to get that on paper performance and functionality.
For unrelated reasons i've had to hop back in to tweak an app we made a few years ago that's been buzzing along in production ever since. Last time I touched it was more than a year ago.
The actual editor interface is horribly unresponsive, but it seems to fix itself if i close and reopen the browser (firefox). Still it gets worse with time and it used to be no where near this bad.
As bonus points, functionality that is working in production no longer works in the editor! I found that I had to add yet another clause to all my functions because for some reason it no longer pulls all data from a sql table unless you use show columns to specify you do in fact want all of them.
Is it a programming language, a framework, a compiler/linker/IDL, etc.?
I mean, there are some that could argue that C is "low code," because it isn't Machine Code.
I started in Machine Code, and, these days, write mostly in Swift. Swift seems like "low code," compared to Machine Code.
I assume that they are talking about things like Qt, React Native, Xamarin, Electron, or Ionic (You can tell that I develop host apps).
I write native Apple, using established Interface Builder SDKs, mainly because of the first point. I like to have 100%, and Highest Common Denominator approaches don't allow that.
Also, I find that upgrading can be a problem. I have been in the position of not being able to support the latest OS, because a library hadn't been updated, yet.
I don't think I ever heard of a system that was successfully shipped, using that.
Both are situations where people are trying to make the primary source something other than written text. I guess I'm biased, but I think written text has been wildly successful. The more experience I've gained, the more I use text based tools and generally prefer text to alternatives. Even in a recent case where I wanted a diagram, I used graphviz to automatically generate it.
E.g. You can write a data pipeline in SSIS by just dragging boxes around and entering connection details.
Sometimes the abstraction doesn't expose something you'd like, so you add a bit of code (SQL/C# for SSIS), but that's the "escape hatch" rather than the default workflow.
You've also got the approaches like Power Query, where a frontend action is automatically recorded as code (M in that case) , but the code is largely hidden from the end user and only used for source control/escape hatch.
I have an anecdote, from a friend of mine, from the 1990s.
He was a fairly well-paid team leader for an NYC bank. Ran a C++ shop. He had to wear a tie to work, but was paid enough to buy a house, in his twenties.
In any case, when I knew him, he was an even-higher-paid consultant, working for the same bank. This time, he wore a three-piece bespoke suit to work. He now owned a house in Port Washington, and he was still in his early thirties.
He told me that the bank wanted to release some new server-based product. This was before the Web was really a thing, so it probably was an EDI system (I didn't ask him what, as I knew he wouldn't tell me).
He consulted with his team, and submitted a proposal for a C++ project, taking several months, and costing six figures.
Some VP (banks have lots of those) came in, and had been studying Visual Basic. He also hated the IT teams (they can be like that, you know).
He told his higher-ups that he could write the whole thing, in VB, in half the time, for a quarter of the money (since he'd be doing most of the work, himself).
Stop me, if you've heard this before...
My friend lost the bid. He quit the company (along with most of his team), and traveled around the world for a couple of years.
When he got back, the bank was in a shambles. The VP had screwed the pooch in a big way, and was long fired. Attempts to redo the project were dumpster fires, since they no longer had any trained engineers on staff, and they couldn't hire new staff.
They were begging my friend to come back.
And the rest is history...
But not the conventional low code platforms like web flow or retool or power apps.
It will be AI native and built in a visual+conversational manner.
the result is often slightly wrong, but if someone in MS management is paying attention and could get it to ChatGPT-python level of accuracy, it would take over an enormous amount of stuff.