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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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.

Did you have any positive experience on the after seeking low code?

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?

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

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

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

Layers of abstraction are powerful when they're tight and well-suited to their purpose (I'm happy to never think about memory allocation -- thank you garbage collected languages!), but when leaky or ill-suited can be very frustrating and make things harder or impossible.

It's hard -- probably impossible actually -- to build a "general purpose" abstraction layer that will work for specific purposes, but that's essentially the pitch of low code -- we don't know your specific use case, but we have a tool that will abstract away all the code previously tailored to that use case.

Now, in fairness, there's a lot of code that has too much accidental complexity in it. A good abstraction layer strips away that accidental complexity and leaves only the essential complexity that's specific to your domain and use case. But that's hard to achieve -- it takes skill and experience (and not just general experience, but specific to your domain experience) to achieve. Most companies don't have that available to them, and don't want to pay rates to build teams that do have that skill set and experience. Low code holds out the promise of being a short cut to that, but clearly if your own dev team can't manage it, the odds of a generic platform doing it for you is slim to none.

> It's hard to build a "general purpose" abstraction layer that will work for specific purposes

I would phrase this a little differently. It’s impossible to make good tradeoffs without an understanding of the specific use case.

“Lossless abstractions” are possible, just rare as they usually come from understanding essential mathematical properties.

As for code vs. no code. If (big if!) bubble can do what you need it can be a cheaper route to launch an MVP.

Where I see no/low code fall apart is when complex input data validation is required. However, I can also see that this might be our old practices getting in the way of innovative forward thinking.

Maybe you've found a way, since you are starting from scratch :)

And when we continue to grow, there are ways off of Airtable since it’s all just CSV underneath.

In general I see little value in any large system intending to reduce the amount of code or the needed skills of the developer. Code is not costing you money. Good developers are not costing you money. You know what costs money? Bad developers making bad decisions using bad tools, necessitating years if not decades of paying armies of lesser-skilled developers to maintain the mess, slowing overall progress to a glacial pace.

That is some wild goose chase that also causes buildup of „agile” smoke and mirrors market and the same with „low code” smoke and mirrors market.

I was quite skeptical about talent shortage in IT but the loner I work on the space the more I see and understand. As there are real issues with talent and agile or low code are ways of coping with the problem.

I’m assuming you’re taking a rhetorical liberty here and really mean “net money”, but then what if you can get a similar end product for lower price? That’s higher net money.

Startup can't afford more than one developer? Product owner can hack the thing until you get customers, funding, or go out of business. Oh, and that bus factor goes up to boot. No more pager duty.

Code things that are core to your business and plan for the TCO. Use low-code for internal business apps and let your smart intern or low-code consultant make and own it.

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.

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.

I find that generally the answer is most often "no," which is kinda a nail in the coffin for serious usage of "low-code."

What im saying is that you should be wary of ignoring things that don't fit into your current work-flow, because sometimes that "critical" thing in your workload is less critical than you think.

So it's not like you can never go back and compare. And there are lots of ways of comparing text files if you need to know the difference.

Because it is "harder" to rollback, or perhaps because its harder to merge, different developer habits emerge.

A) signing code. As in identifying who wrote what and why. Done right there in the comments. There's no external comment section (aka checkin) so the comments go with the code.

B) there's more care over the code. Typically means fewer programmers. Typically means the code is "owned" by an actual person, who either makes the changes or is there to consult.

There's a lot less of "hire 20 contractors to earn in this" approach. (In a low-code situation, IME, programming teams are very small, and often single.)

C) domain knowledge of the whole system is more valuable than "git skills". The code is not the glory. The value is in the whole system coherence, the way everything interacts in service to the big problem area.

An imperfect analogy would be painting. You can get a squadron of labor to paint a house. But if you're looking for art then you let one person do all the work.

The goal of low-code systems is to remove the cheap-labor part (coding) and allow people to focus on the unique parts (the art). Which is perhaps why it's not beloved by those with cheap-labor skills. (And, not meant as an jnsult, but source-control is a cheap-labor skill - which can be used by laboror and artist alike.)

Most of the places I've worked value "global domain knowledge" over specific knowledge of slices. Junior engineers understand a small slice, seniors understand a subsystem component, architects understand the whole system. There are people who specialize, but they need to be a true specialist (i.e. understand their slice VERY deeply) for their value to be appreciated.

I agree that low-code has its place, like in painting a house versus painting a masterpiece. If you need a generic, off-the-shelf solution, low-code is great. If you need a work of art, it's just the wrong tool for the job.

The problem is that a lot of companies selling low-code applications try to advertise themselves as "able to create a masterpiece". A literal example of this is Dall-E and Midjourney trying to suggest that AI-generated art could belong in a museum. Maybe it could, in some one-off outstanding case. But for the vast majority of use cases that's just not true.

Decision-makers seem to be suckers for this kind of advertising - and why not? If you promise me a Rolls-Royce for $20,000 and without any pesky mechanic-work, I'd WANT to believe it's true! But unless they have experience as a mechanic, or as someone who's purchased a lemon, or just someone with good intuition, they won't be able to resist the urge to say yes.

...is baked into git, and is something I've used at my last two employers. You could daisy-chain a bunch of tools together for that, but why? And getting back to the original point: code signing isn't usually possible on "low-code" tools.

> there's more care over the code.

I think what you mean is "the minimum threshold of carefulness required of everyone at all times is higher." I don't think it's true to say "when you toss out industry-standard safeguards, everyone does better at never making any mistakes." I do, however, think it's true to say "when you toss out industry-standard safeguards, the likelihood of making a mistake is higher because of unfamiliar, imprecise, and/or buggy tools, and the cost of each mistake is higher."

This gets back to my original question about low-code tools: when (not if) a human makes a mistake, do low-code tools guarantee fast and simple rollback? Often the answer is "no."

> domain knowledge of the whole system is more valuable than "git skills"

This is just a strawman. No job where I've ever worked has valued "git skills" over systems knowledge — and even if you dug up a job where that was the case, that's a shortcoming of the company culture, not of the tool. In my experience, it's more common that companies value low-code-tool skills over domain knowledge, usually because they've gotten locked into their proprietary low-code tool already and are unable to select from the total pool of developers unless they're able to do a wholesale rewrite, and must instead prioritize "knows Pentagon" or "knows Salesforce" etc as their top hiring priority, instead of "understands software architecture".

This is the version control/CD process I designed:

- We have a normal Git repository, hosted in Azure DevOps cloud

- Developers work in the "unmanaged" cloud-hosted Development environment

- When ready to move a set of changes forwards, the developer branches the repo, and runs a PowerShell script to export the solution from the Development environment to a local ZIP file, which is then automatically unzipped. The only other thing I do is reset the version number to 0.0.0 within the `solution.xml` file, because I'm pedantic and the code isn't necessarily a deployable build yet - it could be an intermediate piece of work.

- Developer reviews the changes, commits with a message that links to work items in Azure DevOps, and creates a pull request -- all standard stuff

- On the Azure DevOps side, once a PR is merged, we build a managed ZIP -- which is really just the same code, with a flag set and re-zipped up with a version number that matches the DevOps build number (in the Power Apps world, "managed" package deployments can't be customized on UAT/Production without explicit configuration allowing it)

- We then use all the normal Azure DevOps YAML pipeline stuff to move this between UAT, Staging and Production with user approvals etc. The Azure AD and Power Apps integration makes this very pleasant - everything is very easy to secure, and you don't need to pass secrets around.

- You can rollback to a specific commit using normal Git tooling or just redeploy a past build if there is one available.

That all being said, most people don't do the above. I should probably sell a training course, because it took quite some time to put all the pieces together. The bigger problems are planning ahead for changes without breaking stuff that is already live, because you generally only use 1 development environment for an entire team.

I'm thinking of visual studio solution files which were XML that picked up a lot of spurious churn when written by visual studio. A formative moment was discovering that colleagues edited these by hand to remove some of the noise when checking them into source control.

XML has a canonical form idea, sorts attributes and similar. Mostly wondering if opening the trees of emitted xml/json in a diff tool is a vaguely credible way of diagnosing whatever seems to be going wrong / rolling back one part of a change made in the GUI tooling.

Does Node Red count?

I am a big fan of Node-RED but it lacks a visual version control and without that, it makes little sense creating visual code and then use a textual version control to revert changes.

Of course, just like say the SQL or NoSQL debate there are contexts where one wins, and another fails.

I did have to smile at this though;

>> "Now, rather than being to recruit from a large pool of ubiquitous, open-source language developers, the company has to find maintainers who are very specialized in this tool."

From a company point of view this is correct. You cant just discard programmers and get a cheap, out-sourced one as a replacement.

On the other hand, as a somewhat older programmer, I like the idea that I get more valuable with age not less. I like that I can't be replaced by some ubiquitous open source freelancer who works for $20 an hour.

For the record I've been working with a low-code tool for 30 years (since long before "low code" was even a description) and I've seen thousands of one-man companies be successful developing programs where the owners actual programming skills are, well, in most cases, somewhat poor.

Turns out, making something useful has more to do with fixing pain, and less to do either writing code.

And yes, all the points listed in the article, and these comments, are true. And ironically almost none of it actually matters.

There are a million reasons it -shouldn't- work and yet, somehow, at least in my world it does.

VBA (Visual Basic available in Excel and Outlook) had a lot of the same issues as low code, as in no version control, no workflow for review or continuous testing and integration, no ability to do lots of custom things, that did not stop it from running the planet. I mean if you did the VBA version of Thanos-snapping half of all VBA code out of existence, most of society would cease to function within a week.

Power Automate is going to replace VBA soon because VBA can no longer talk to web pages thanks to the end of Internet Explorer and lack of VBA updates. And like VBA, Power Automate has all of the same problems - no concept of code review, version control, history, logging, actually its worse.

VBA at least let you have custom Types and Classes but in Power Automate everything, literally everything, is a global variable. Power Automate is lower code than VBA. But I think it will be used even more.

Because it is already installed on every almost every office computer in the world. This is the only tool ordinary Ops people will have available to them to automate stuff, so that is what will get used.

Then I found out the developers assigned to working on the low/no code parts had a component where they could write Java inside their low code process. There were hundreds of lines of code in each business process in the low code parts. They were writing giant methods in their process wired up by the true low/no code part.

To make matters worse the tool did not support unit testing of the custom code.

It ended up being like dozer mapping entity to entity and then passed along to custom code. All wrapped in some crummy UI. It produced a jar file which would be deployed anyways.

Maybe the tools are better now. We had some Tibco product at the time.

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.

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.

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.

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.

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.

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.

In the end, you end up with either less skilled people getting in too deep, or highly skilled people unable to fully avail their skills. I get the appeal, but it always seemed like a local optima to me. It turns out code is a pretty good interface.

They could just provide the software library as a standalone but then there's too much competition and the competition is often free to use. So they don't even bother because their whole product is redundant without the GUI, and the GUI itself is just a pointless obstacle to a developer.

Low code GUIs are a weird code generator, just the same as all the other programming languages.

Whether it's an obfuscation or an enabler depends on your perspective and what you're trying to do with it.

In particular, programming languages are pretty much a library (called the compiler runtime) with a text user interface on top.

The low code systems being derided here are programming languages. They're languages you use to program computers with.

I suppose one could define "programming language" to be "a language for programming computers that is useful in some context", but they're pretty much all useful in some context. Maybe one could define it as being mandatory to use text editing to count as a programming language, but the smalltalk instances are something of a counter argument, as are the UML things.

You say low code systems are programming languages, I said they're GUIs on top of software libraries. So in essence we both just said low code systems are graphical programming languages, in different words.

The problem with these graphical programming languages is that they are constrained. To a developer like me they take away my freedom to do what I want, especially if they attempt to target non-developers. And even if there existed a totally complete general purpose graphical programming language, it would just be another programming language with the caveat that instead of just writing whatever I want I have to find it in some menu and drag it somewhere and whatever else. It's just a less convenient way of doing the same thing.

If you move from asm to C, suddenly goto is stuck within a single function and calling conventions are absurdly constrained. If you move further up the stack goto might be removed entirely and function calls might throw an exception if the calling convention is violated. People like this restriction.

CPython has id() to get the address of a value. Really convenient. Totally messes up alternative implementations of the language. Other languages won't let you talk about the address of a variable at all.

Removing capability from the programmer helps communication with other programmers, simplifies parts of the implementation, sometimes simplifies writing programs in the subset that remains.

Working in a non-turing complete language can give you hard guarantees on termination. If you go as far as regular languages, function equality is decidable. As in convert to a DFA, minimise it and alpha-rename, and the two functions compute the same result iff said DFAs are definitionally equal. You don't get that with a general purpose language.

Regardless, I share your irritation with low code systems to the extent I've tried to do things with them so far. An escape hatch to java is really not a thing I want. A wholly general purpose Turing complete graphical programming system sounds awful to me.

That doesn't make the fundamental premise of a heavily restricted language with a weird interface wrong though. All programming languages are more or less heavily restricted already, and a bunch of them have weird interfaces.

I believe low code style systems are the right things to program some applications in for much the same reasons that config languages shouldn't be Turing complete.

Less clear is whether any of the current low code tools (other than Excel anyway) deliver on that optimistic view.

Everyone is happy! Especially the people who actually have to use the software made this way! As we all know, enterprise software has a reputation for being extremely user friendly...

Talend is an ETL tool: Extract data from a data source (file, database, API), Transform it, and Load it into another data source (file, database, API), all in a pipeline. Talend's happy path is the same as Unix shell's happy path: A pipeline of data with no side-effects and no globals. Try to deviate from that and you hit walls, some more climbable than others.

For example, Talend absolutely will not allow you to re-combine a pipeline you've split; you can combine two separate data sources, and you can split to two separate sinks, but you absolutely cannot go from one pipeline to two pipelines back down to one.

The saving grace is that Talend is fundamentally a GUI for writing Java. You can see the Java it's writing, and you can add your own Java in a few ways, from adding jar files to just plopping a pipeline component that allows you to insert your own Java into the big God Method that the rest of your pipeline helping to form. Be sure you know how scoping works if you do that.

In extremis, you can "use Talend" in that you use the Talend GUI as an Eclipse IDE to write the one pipeline component that does everything because it contains all of the useful Java code. You can use it the way I often used it, to take care of some tedious "plumbing" code to route the pieces of data created by the hand-written component to their respective outputs, including handling some minor output conditioning that can be done in a stateless fashion. It can even be used as it was intended to be used, as odd as that sounds.

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

These tools can be useful for non devs to make very basic things, but they won’t be able to handle anything complex, and it’s hard to test and proof the correctness of the result. If you take it far enough you are always going to end up hacking around the tool.

For people who do write code these tools could be useful, but code is much easier to use as you are not stuck within the constraints of the tool and know what you are doing.

I think there is one success story for low code and its basic websites, mostly the part where a design is turned into code. I use Framer because it’s objectively quicker than code, with great results (I even design in framer), and once it’s set up non technical colleagues can make changes. Great for a landing page, but it won’t work for apps.

I think the article is right in pinpointing the logic as the problem. Coding is not about syntax and the language, it’s about the logic and ability to map that out into a program with all the edge cases and details.

Low code is a dumb persons idea how to make programming easier — the kind that thinks memorizing all the weird letters and signs is what makes programming hard. The result will be that you will have non-programmers learn how to become programmers by failure — in production — on the job.

I always welcome things that bring complex system interactions closer to learners. But it comes with considerable risk : )

You change the existing system slightly and a bunch of not obviously related parts fall over. Someone updates the OS on the CI box and now you're dealing with dependencies with dubious ideas about semver for the rest of the day. Nothing changed overnight but now the performance bot is reporting a regression.

Most of the problems have many inputs, some of them malformed, many outputs, race conditions, multiple writers, time dependencies, weird edge cases, etc.

If you really wanted to punish me you would force me to reimplement the good software I wrote in no-code tool. And I am a fan of node editors in VFX. I know how to wrangle complex node graphs efficiently. But in VFX you have a clear direction of flow and it is the simple black box described above.

Structured text is a great and extremely efficient way of describing, editing and manipulating programs. Your node editor has to beat that for anything non-trivial — because even the simplest scripts I wrote for my employers had to handle any number of non-trivial cases.

You are aware that dependency problem would be literally the same if your dependencies were made out of nodes and connections? Only now the debugging is harder. If you hate dependencies fucking your day up in code, you could always just not have them and write everything yourself. Like our fictional node wrangler would have to. I mean I can feel you. But nodes don't make these problems go away and structured text didn't create them.

I meant what I said about complexity. This is not about code, it is about complex systems. A programmer who knows race consitions is also likely to be able to predict one in a completely peoples based procedure that doesn't involve computers. A programmer who knows about distributed systems will be likely to predict the same problems emerging from multiple distinct departments of a company, etc.

If you want to tackle a problem involving complexity, you get people who know how to do that and you don't care whether they use nodes or structures text to do it as long as it gets the job done. Or you could make the tools look harmless and give that power to people who have no idea what they are doing. In many cases it might go fine, in many it will lead to much more complexity for when you finally hire aomeone to clean it up.

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.

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.

From a business standpoint it's probably the single most useful software platform ever invented.

Low/no code solutions exist for when there isn't enough time or budget for a developer created solution, which is to say, pretty much all always. In the real world of business problems, almost nobody has access to a professional developer.

The main point is it has its place — and choosing when and where to use it is critical.

A few years go by. Someone in Big Important Company decides the courses need updating. Work ends on my desk as my bosses have the contract to maintain various other bits of BIC's creaking self-hosted intranet. I ask questions like "What software did BIC use to develop the courses?", and "can we charge BIC the cost of getting the software so I can do the work?" Of course, the answers are all along the lines of: no.

So all I have to work with is an extensive set of hefty change requirements to the courses, and a SCORM package downloaded from BIC's intranet. A huge amount of learning (how to manually edit SCORM packages) and frustration (how to test changes to SCORM packages), and a few months of time when I could've been doing something better without deadlines harassment ... I completed the work. Which I wasn't allowed to test on BIC's intranet servers for "security". So I just uploaded the new SCORM package to their production servers and went on 2 weeks leave.

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.

Which I can understand, because engineers are expensive and behave in ways that are unintuitive for non-tech people.

But I fear “generative AI coding tools” appeals to the same people for the same reasons, leading to the same results.

Much discussion around low-code (and no-code) miss that it is just abstraction. The question is not if we should use abstractions or not, but what constiutes good and bad abstractions.

> Despite forty years of commercial products, open source, and deep academic work, we have yet to reach an end-user programming utopia. In fact, the opposite: today our computing devices are less programmable and less customizable than ever before.

https://www.inkandswitch.com/end-user-programming/

COBOL, BASIC, SQL. HTML, CSS, JavaScript. All these started as relatively low-code solutions to what came before. And surely textual programming languages aren't the only way to empower users to take control of personal computing. Excel formulae to express dynamic values. Visual builders that internally compile to syntax trees.

They all have their own problems and room for improvement, but one could say the same for "high code" programming languages. It's a means to an end, and for computer users who don't have time to dedicate to become a high-coder, they will use whatever is available to solve their needs.

The only 4gl I know of that held the test of time was SQL. Every other one ended up being an embarrassing wart of "technical dept". The same could be said of most "enterprise software". For them that don't know enterprise software is code for "It's 70% done and we will charge well to finish it for you"

> They wanted truly custom functionality that the low-code solution could not handle.

It's important that the low-code solution has an escape hatch, or a way to to interact with external "high-code" APIs. In sqlpage, we have sqlpage.exec

> They implemented a bunch of custom functionality in a product-specific or even proprietary language and now their pool of potential developer talent is tiny.

I agree that low-code makes sense only if the low code is in a standard, popular language. In SQLPage, it's all just SQL.

> Upgrades to the low-code platform would break their custom implementation.

This is a true problem. The low-code solution really has to be careful with updates.

> The underlying database structure was an absolute mess, especially after a bunch of incremental modifications

This! Most low-code tools take your data hostage. You shouldn't use them. In SQLPage, we add a layer on top of a database that you still fully control.

It's crucial to understand the advantages of low-code for specific situations, especially in developing internal applications. These tools, often neglected due to limited resources or developer disinterest, can be rapidly and effectively created with low-code solutions. Low-code excels in scenarios where internal teams are overwhelmed and business users face long waits for features. Although it's not a cure-all, low-code is highly effective for certain tasks where speed and ease are key, despite sometimes facing limitations in customization.

Some modern low code tools are also evolving to be closer to web frameworks. Plasmic is one my favourite examples of this.

So this hits on one of my questions/observations. How different is low code to the generators of various web frameworks? I'm thinking things like Rails, Django and the like where a lot of the "low code" appears to be templatized. They sure feel VERY similar.

Contrast to printing per se: You have some text and graphics. You do wire frames. Now you have to decide about the next part of the process: are you going to go with litho or a more traditional layout process? Now you do either cut & paste or cast / etch / burnish plates and / or masks. Now you print, which actually involves doing multiple prints in different colors which all have to line up. (And that's the simplified version, it's a lot more complicated than that.)

Desktop publishing is actually a code development process. A Postscript(r) printer knows a programming language called "postscript" which interfaces to something in the printing engine which is called the "raster image processor". Postscript programs have libraries, and the printer gets transpiled code for the RIP to execute. (Does this sound like your web dev shop?) The location of the RIP has meandered back and forth on the workstation <-> server <-> print engine continuum due to various factors; this looks a whole lot like the compute / display continuum and the endless debate about how smart a display device needs to be.

Now, the color is never quite as good with DTP, mach banding, dithering, blah blah blah. Like I tell my wife, the artist, the only person who knows that's supposed to be insane blue, and that over there is outrageous orange is you. (When she prints cards she secretly does hand touchups with the true pigments which are a mote in her mind's eye.)

For most things on the planet, normal people will settle for desktop publishing's shittiness. What's not shitty about DTP is the democratization. Instead of one person publishing to a million, it's (potentially) one to one.

I wish, I truly do, that all of this mattered for the web but it doesn't. The web is largely free, and at the scale of free everybody gets the same unique experience. On the other hand if I have a $1,000,000 warehouse facility even if there are 100 people working there I want them to have the best experience possible. I'm going to tailor that experience based on job function, where in the facility they operate, what they do. If someone is missing a finger, they should have an interface which takes account of that. $50,000 piece of machinery with one user? Optimize that user to optimize that machine. Welding gloves, or gloves covered in fish guts? Special interface for you too.

A good low code solution comes with OT drivers, speaks to SQL and microservices; produces true and correct (legally speaking) audit / transaction / snapshot logs (because if someone gets poisoned by the product or loses a hand working with the machinery...); has MES (workflow) as a low code function.

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.

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:

    # 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

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 believe it would be able to divine that information from a file upload. Or to use this slightly wonkier method but actually read every MIDI chunk header, since standard MIDI has no total file size length encoded in it. The loop should be: look for MThd, read the NEXT 4 bytes for the length, skip, read and write out chunks (ie 4 byte magic followed by 4 byte length), split when chunk type not seen (that's what makes this a bit fragile, but its probably good enough). If you just look for MThd, you'll split if the MIDI data has an 'MThd' in it.

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

Also in the file I count 640 MIDI headers and I only got 639 files out of your thingy so you might want to revisit that part I mentioned about bugs.

It might actually be interesting if you reconstructed the hierarchy in the metadata. That is not hard, it is all absolute offsets, sizes and null terminated ASCII strings.

But what you did seems to have written a (possibly buggy) loop that calls basic standard library functions in ruby, and attempt to poorly parse/convert a few MIDI meta-events. It's not reverse engineering if you have a nearly perfect spec in front of you, you completely skipped the (simple) reversing part and bungled the easy part. And this task shouldn't take a few days nor hours for someone experienced with basic scripting. https://adventofcode.com/2023

> the entire process of iterating through the binary blob, pulling out the MIDI header/track chunks, and then creating entries with smart naming in a zip archive is done entirely in-memory. For the non-programmers, this is otherwise known as "hard" or "showing off".

We have very different definitions of hard. Unless you were writing a shell script doing it any other way is bananas. These are like a few hundred bytes a piece.

Your technical chops are discordant with the arrogance and incivility you've displayed towards others on this forum. (And name dropping Carmack, that's bold)

eg: "Serious question: are you wickedly combative in all discussions, or just when you get the cold feeling that perhaps you might not know as much as you think you do?" in response to someone who simply had a differing opinion to this: "you keep implying HTMX is a good choice, when there are vastly more powerful solutions in play."

"I assume that the person who downvoted my comment is a bootcamp grad. Good luck with your future endeavors."

I see a common denominator here.

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.

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.

* no-code

Basically all SaaS solutions that provide a web form to integrate and link services. Changes cannot generally be reverted nor is there any sense of version control. Only limited approaches for collaborative workflows.

* low-code

Things such n8n.io and nodered.org - visual programming environments that place a focus on data flows and not algorithmic code, alternatively known as visual flow based programming. These tools currently lack proper workflows for version control, collaboration amongst folks involved in the project. Hence these solutions generally do not have alternatives for the much-code development workflows.

* much-code

Textual code solutions using any one of a number textual programming languages. Very clear workflows and well defined processes for version control, testing and collaboration. Being extended by using AI for code completion and code generation.

It interesting to realise that much-code solutions have been around since we stopped using punch-cards and many developers believe there are no alternatives to the classic keyboard,screen,mouse approach to software development.

Perhaps it is time to rethinking our approach to development. Perhaps a two dimensional approach is more appropriate. Text, for me, being one dimensional: text is read from top to bottom, there is no left and right with textual code (in its basic presentation).

However, I share the author's skepticism about other low-code tools that involve a lot of UI/visual flow building with limited insight into how the black box works and what its constraints are.

As the other comment said, less code tools for developers can be quite helpful.

I see this being our reality anyway. In many cases; not all.

You can’t ask the LLM, nor a hypothetical AGI, nor anything, to build the aqueducts. Especially if you don’t know you need them. And they won’t solve the problem if neither a human nor an AI know what the problems actually are. Let’s make em out of lead!

And they definitely won’t waste tokens on a postgres rollback migration unless we make that essential in the acceptance criteria.

An LLM is all of our ideas, in a search UI that dang nearly passes the turing test. (That says more about us than the state of AI technology.)

We are pattern machines in many ways, and many things we code are even lovingly called Software Patterns. The promise is not that software engineering goes away, it’s that we’ll all be managers for a while.

Low-code, to me, is different from “statistically generated solutions that pass the requirements.” Genetic programming was an idea for decades, but that is also different from stuff that combines yours and my most relevant github commits into a 90% best guess. Not random, hoping for the best, in this regime. Educated guess.

I suspect there is another opportunity coming along to make some good money bailing out folks who built 'no code' solutions that their business now depends on, but no longer meets the needs and has become to fragmented and complicated to tinker with and difficult to change, scale or adapt.

That said, I am not opposed to no-code - it is a good and often inexpensive way to solve some problems, or at least get a POC working - many of those solutions may never need to scale or adapt.

...but some will, and thus the coming opportunity.

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.

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.

Give an analyst with some technical acumen PowerApps and ask them to mock up requirements, and after awhile, they can produce a click-through prototype.

That same analyst will likely improve their UI, API, JSON and SQL skills in the meantime.

Low-code tools are also good for digitizing CRUD forms.

Much beyond that and things get very proprietary, very fast.

We're a low code platform (app integration) and what's worked well for us is to have the platform store the generated workflow design (yaml/json) in source control.

Additionally, we map environments on to source control branches so merging to a branch is what promotes a design version to qa or prod.

The real unsolved problem is lack of visual comparators that could show what really changed between versions. If you try to do diff those text serialization formats (those being yaml, json or, in old days, xml) you have to do a lot of mental gimnastic to map those onto visual changes that are meaningful. And most potential users of your low code tools are not capable enough to use it this way.

If you take into considetation that visual comparators of workflows is extremely hard problem to solve (probably only bunch of people in the whole world is cable enough to do this in a way that anybody sane would use) then you easily see why all visual dev tools of last 30 years went bankrupt. And if you did any sensible research you would know there were hundreds attempts at it with some spending hundreds of millions of dollars (Rational and later IBM being main ofenders here)

Hmm this looks more like na attempt at building better merger by getting rid of unstructured text and replacing it with some kind of structured/hierarchical data.

I think that this can be useful but I don't see how this helps to solve general problem of visualizing diffs between workflow versions (and making it readable and mergeable for mere mortals)

There’s some snippets of a visual diff in the docs here https://floro.io/docs/product/product-and-terms. If you do want to give feedback or see a demo I’d love to chat. Again, my email is in my bio.

I'm at some risk of replacing that with something hacked together out of XML. Hopefully you're doing something useful in this space.

My site is half built (lots of broken links and only half of the documentation is done so please don’t judge me), but I think my technical explanation does an okay job of talking through some of the complexities to think through in regards to structured diffing and merging. It might be helpful to you if you do decide to write a git merge driver. https://floro.io/technical-overview-part-1

Aside: The contrast on this website is really borderline. Extremely light gray, low font weight, white background. I thought we were past that particular trend in web design.

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.

The 80% is not evenly distributed. Marketing might have problems that are 95% satisfied by low-code and they can change their process for the last 5%, or accounting can do 100% of a 50% subset of their job with low-code. Logistics can't really do any of their job so they steer clear.

All the other points are related to trying to satisfy 100% of a custom problem with a generic low code framework. Don't do that.

You run into all of these problems with custom code solutions too; The debate should be about investment vs. control, of which no/low/custom coding is a component but not the differentiator as presented here.

The story is exactly like the fine article mentions. Heavy reliance on proprietary stuff making the organization heavily reliant on very expensive consultants to get stuff done, no way to sanely version things..

I now go out of my way to avoid working rescue jobs like these, unless the client is actively migrating away from them.

1954

https://www.softwarepreservation.org/projects/FORTRAN/Backus...

It's open source and built using NodeJS. No vendor, no lock-in and very extendable using javascript.

It's all a definition of low-code.

[1]=https://nodered.org/

Likewise an upgrade would break our custom SAP implementation. Most all big ticket business apps are "low code" and suffer this problem.

>The underlying database structure was an absolute mess, especially after a bunch of incremental modifications.

Ditto with all enterprise software I have used.

All big businesses depend on low code enterprise apps. For that matter, a SQL database is a low-code platform.

It can't do everything we'd like, but there is always a workaround that is "good enough".

Sure it had limitations but you could get an awful lot done within those limitations.

Low code is all about optimising the more important thing.

The downside is that all those software engineering concerns that the average business practitioner is poorly placed to cope with often find a way of reasserting themselves and when they do, you typically end up with a mess worse than if you'd started with a code solution in the first place. However, in the domains that they don't, or where the negatives are not business critical or can be adequately mitigated, low code can be incredibly empowering to noncoders (excel is probably the canonical example).

What I mean is that if the people who actually have the problem could describe the problem with sufficient detail and unambiguity, the core coding part would be very straight-forward, fast and cheap to do, regardless of the programming language.

Of course the additional things beside the core, like change management, monitoring, security, APIs etc. would add to the cost, but they are at least possible if you are not on low-coding platform.

The problem is that for anything basides the simplest applications, people cannot describe what they need in sufficient detail and unambiguity. This is where the cost of the application development comes from.

There are many means to bridge this gap: user interface design, prototypes, agile development, waterfall requirements gathering etc. Excel is a way to iterate, that many professionals learn to use. If the end users can develop software that solves their problems, and does not cause other problems, there is no problem.

From what I have seen, low-coding is sold to IT departments with promise of cost savings in the coding part, and to other departments as a means to bypass IT that they consider slow, expensive or not delivering what they want.

So we need to get down to what we mean by low-coding and what context we are talking about. In addition to Excel, Django appears to hit another sweet spot in many contexts. It is very fast to develop and iterate with, comes with built-in admin UI, but it is still possible to add fill all the corporate technical requirements as well.

The low-coding platforms the link points to that seem more problematic usually have some custom programming language, abstraction layers that often limit the extensibility for more complex applications, graphical ui designer, have difficulty supporting enterprise requirements (those security, auditability, monitoring etc.)

...which is also the expensive thing in most cases.