Low-code is not a cure for overworked IT departments

And have a compelling product ...

You'd think the success of his model would be used elsewhere to reduce employer costs and increase retention (no SWE has left his org in 4 years). Instead other petty executives get pissy and poison the well.

Something is extremely off with modern corporate America.

"Good developers" are hard to find. Average developers aren't even easy to find nevermind ones that are actually good. The paying them a good salary and treating them well, companies are right onboard with in my experience. The tech department has better working conditions that most other departments. I worked at one company and one of the marketing teams once had to leave a resturant before eating because their lunch time ran out. So they paid for their food and left without it. All the techies just looked on in shock. We came and went as we wanted.

But the thing of finding good developers is hard. Even if you target just the folks in the top 50% of the bell curve, it's still going to be hard. And in my experience you get a few lower quality developers in and the next minute you've got someone saying their AWS lambda solutiuon can scale to any level 10 minutes after their solution took down the whole system in cascading failures because it was returning 500 due to the non-serverless database not scaling... I swear to god, even the non-technical folk knew the guy was talking nonsense. And the thing is, these people can and will pass your tech tests because honestly tech tests aren't really good at showing you how good a developer is actually understanding things. They can write quicksort but have no idea, how to figure out the best way to scale a data export feature that is crashing because of memory limits.

And the thing really with no-code, you encounter a bug, you're possibly dependent on a third party to fix the bug. Not a good place to be in because they never care as much as you do.

There are plenty of highly paid engineers who couldn’t build a decent product given all the coffee in Shoreditch.

As a non-tech person, how do I know to whom I should give all this money? Maybe a hands-off CTO or a hands-on architect cum engineering manager? Or a product person? Or maybe a skilled UX designer? Or a good infrastructure person? Or a DBA, and in which database? Or should I lower the money and get cheaper people in all those roles? Or maybe outsource the whole thing to an agency?

There are plenty of stories of companies who have hired all the above on good money and built an over-engineered, unmaintainable mess that solved zero real world problems.

I would argue that instead of money, you should build it with patience. Hire slowly. Solve one small problem at a time.

The problem is reasoning. Often the low code limitations funnels the implementation into a contorted state, so by the time they've decide to give up what I get is frequently exceptionally difficult to comprehend. Usually I peek at it, try to get an idea, and then do what I would have done if assigned to task from the get-go - read (or make) a spec, and go from there. I'm doing some quick napkin calculations from the time tracking system, and the ratio is approximately 13/2 on the last 7 of these no-code to code tasks. What they attempt in no-code in 13 hours and fail I finish in, yes, 2. Given, these are not developers, and sometimes these actually come from the CEO (who does not track their time so they're not in that ratio), but mostly they're just managers and remote hires. And I've been developing software for 28 years now, so I have some capability. Also, these are mainly data related projects, so maybe other types of work would have more success.

No code will get better, I'm sure, but the problems we're solving actually are getting harder (it seems to me) and reasoning about them is the difficult part. I'm not sure how to no-code that.

I wonder if it's because some of those at the mid-to-level making these decisions are under the same market pressures as the rest of us to show they've actually 'done sometime' - so they can slap this on a resume and prepare it for an interview when they roll out of the org in a year or two after implementation. This seemed to be the history in the IT department at the hospital I worked out where they had a decade of zombie projects that sorta worked because they were implemented, barely supported, and the persons that made the decision had bounced to something else, leaving IT holding the bag.

This is the core issue with any sort of complex system. Absolutely nothing matters when the customer is non-responsive with requirements or is not providing enough feedback on prior iterations.

Code vs no-code has absolutely no bearing on this part of the equation.

I do think there is value in low-code or scripted/DSL solutions, but it has to be a very intentional strategy that isn't simply leaning on "configurable == done faster".

And doing all that in a coherent way that’s ruthless about maintaining simplicity for as long as possible, including pushing back on business ideas that add marginal benefit but mushroom the complexity of the app.

    * An IDE that knew anything; I literally wrote in Notepad
    * Backup/restore procedures to speak of.
    * Defined release/rollback procedures.
    * Any monitoring beyond "walk to the server and look at the CPU monitor".
    * Source control.
    * 3rd party libraries.
    * Cloud deployment complexities; one server, one deployment.
    * A DBA or anything resembling one.
    * Automated testing.
    * A (solid) distinction between dev & production
    * QA
    * Cloud/reliable 3rd party logging.
    * PII or other info control issues
    * Security/compliance software, needs, etc.
    * Documentation requirements

Many of these are only partially automatable by some service. Some are not automatable at all. Some you can automate to your heart's content but it won't matter because the user has an irreducible responsibility to use them correctly themselves, no matter how much you simplify it, like source control or writing documentation.

Last week one of my tasks was to dive into codebases that were 17 years old, and hadn't been touched in 12, and figure out what was going on and how to fix a new issue. At that point in time this company was a startup and certainly wasn't following 2022 best practices by any means, but at least they had source control, the source code was checked in, and it still built. (Very simple C programs, fortunately, single files with no external dependencies.) On the one hand, enough good dev practices that I could still pick up the pieces even if they are sadly deficient by modern standards, on the other hand, still more good dev practices than you can ask for from a non-programmer.

What does the equivalent of this look like for this "no-code" stuff? Who is going to poke through a big pile of stuff, where even if it is nominally "source controlled" or has a "managed DB" was not source-controlled well and the "managed DB" amounts to "well, when they guy who didn't understand DBs at all and was in fact aggressively told he shouldn't have to because this software Does It All decided he needed to add a column, it just went ahead and did it" and so and and so forth, is now a 10-20 year old pile of vendor-specific "no code"?

The intrinsic contradiction of the "no code" stuff is that we programmers do not have all this source control and testing platforms and QA procedures and deployment and rollback procedures and all of that other stuff because we are sticks in the mud who love process. We have all these things because we've learned the hard way they are necessary. I use them even on my projects where I have a single developer for maybe a month! And that's a tiny project, and they still save my bacon over and over. I look at my 1997 list in 2022 and both despair and laugh at what passed for a production deployment back then. For a modestly critical system for what is basically a ~50,000 person company. No-code trades short-term easier for medium- and long-term harder.

I can't even imagine what legacy no-code will look like and what a nightmare it will be. Without sarcasm, I'm sure it will make the 20-year-old, umpty thousand line Perl code base that I was also in last week look like paradise.

No-code is great for exploration of problems, and for all I may seem to be slagging on it here, I believe it has a place and it is worth exploring. But it is sheer foolishness to think it can "solve overworked IT department"'s problems. A no-code solution would be lucky to make it easier in the short term, but even if it manages that, the medium and long term graphs of difficulty are a nightmare. As a professional programmer, I'd LOVE to just be able to bash on code and not worry about backups and staging and rollbacks and QA and source control and all this other stuff. I'm not doing these things to gatekeep, I'm doing it because I need to!

To put it in physical terms, sometimes I think no-code is like someone passing highway construction and asking "What's with all these people? What's with all these machines? What's so hard about highway construction, it's just concrete on the ground, right? We don't need centralized planning and all this money! Let's just give shovels out to everybody and some cement mixers and turn them loose!" Well, you know, arming people with shovels and cement mixers can be very empowering in certain circumstances. But try to build a local city network that way and you're just going to reinvent everything you threw away, because it turns out trying to drive thousands of semi trucks a day at 70mph down a path some guys shoveled out and poured a bit of concrete over doesn't work.

This is one of the biggest challenges I see people struggling with as they learn programming: Cutting out the implicit assumptions that humans make every time they communicate with each other, and interactively working to understand *exactly* what needs to happen and why.

Interactive AIs (e.g., Copilot, ChatGPT), in principle, could address the specification problem. Unfortunately, in their current state, they have no concept of what they don't know or understand. Gaps in the specification are filled in with assumptions, and one of the main criticisms of these tools at the moment is that they have no way to reason about how appropriate these assumptions are. It seems likely that we'll eventually reach a point where simple AIs can replace devs for the relatively simple tasks that low/no-code solutions target. However, for this to happen, (i) the AI would need the ability to reason about uncertainty/incompleteness in the prompt it's given, and (ii) the AI would need to be able to interactively work with the user to refine the specification.

Should large businesses going to build their most critical functions into a low-code solution? No, not at all. But one slightly technical person in e.g. the marketing department can unlock a lot of business value but automating a few workflows.

But besides this point, when the problem is now well understood, no/low-code is just like walking with rocks in the shoes: you think it will go away by itself and you end-up with bleeding toes in the evening!

What happens when stuff evolves and becomes integrated?

I’ve, several times, seen the result of tangled lc/nc stuff gone production critical and… it becomes an unmaintainable mess that no one wants to touch. This becomes a massive roadblock for agility and change down the line.

A simple, discrete, crud app that could have been an xls - sure. Great for PoC and demos; horrible in a live business setting. IME.

1) produces a just wildly, horribly inefficient solution, just doesn’t care about optimization or big-O at all.

2) guides the user through producing some reasonably sane design docs that describe what they are trying to accomplish

Then you’d pass those docs and the toy implementation along to a programmer

I'm increasingly beginning to question how this is even an advantage. If your IT team is overloaded... hire more and pay them better.

Another way of saying "allowing non IT teams to do the work themselves" is "taking a specialized job that can be efficiently done by a dedicated professional, splitting it into thousand pieces, and distributing those pieces evenly to everyone". Sure, it's nice that a marketing manager can no-code some automation without having to bother an overworked IT person, but now no-coding that automation becomes yet another little bullshit task that distracts them from their core competency, i.e. marketinging.

This is one of those trends that feel beneficial on the surface, but less so if you look closely, at least in job context. The OG one are office suites - particularly word processors, spreadsheets and calendars. Yes, it's nice that I can write my own reports, tally stats on my own, or manage my own meetings. It's less nice that I have to do it all the time, where in the past, there were people hired specifically to handle this job for everyone else. How many highly-paid software engineers are being distracted and waste their time on this, only so that corporate can save on hiring lower-paid secretaries?

I don't think it even adds up economically, but the trick is, once you eliminate a job with software by outsourcing it bit by bit on everyone else, even though it's now much more expensive, it disappears from the company books. Not having to pay extra salaries is legible. Overall unexplained productivity drop is not.

"I told it to delete users from my contact list, not just delete them from system!"

They are, therefore, largely tools for power-users. You need to understand why codepiolt/etc. is suggesting a completion before its actually useful.

If you prefer: Intelligence is knowing what question to ask, and knowing how to validate the answer.

I can easily imagine something like this taking off. After all it would be a giant step towards two things we have been trying since the 60s: a programming language intuitive enough that business people can use it, and a declarative approach where you describe what you want to achieve, not which steps to take.

That said, if all the current prompt engineering is anything to go by, using such an approach effectively might still require a lot of skill. But the barrier to entry would be a lot lower, and for some classes of problems it might be much more efficient in terms of programmer time.

What could possibly go wrong?

I know! Hook it up to manage people's retirement savings / 401(k) for pennies on the dollar compared to traditional portfolio managers.

(There were also highly pragmatic reasons behind that, such as the paucity of common symbols in the non-standard character sets that were used back then. This shows up in other early languages, but nowhere so clearly as in COBOL.)

Nowadays we know that the "low code" paradigm does not help beyond absolutely trivial examples. In particular it does not make the resulting artifacts easier to audit or survey, rather the opposite.

I'll repost an old post of mine:

https://news.ycombinator.com/item?id=33703563

The Curse Of Almost: Your tool is great, it's almost perfect... except for that one little thing it can't do, which your users need to do, which, therefore, leads to masses of ugly hacks unless you provide access to an escape hatch where sufficiently motivated experts can drop down to a real language which doesn't have your DSL's limitations and get the job done.

It's the Curse Of Almost because, if it were too much worse of a fit for the problem, nobody would even think of using it to solve that problem. Getting someone 90% there and crapping out puts your users in a more awkward position, especially if they feel they've invested effort in whatever tool they have.

An example is Talend versus CSV: Talend is an ETL Solution which Extracts data from some source, Transforms it according to a graphical DAG of ideally stateless components, and Loads it into some other storage. It's also a happy, friendly GUI on top of Java, which is nice, because the Real World isn't kind to happy, friendly GUI solutions which expect CSV is going to conform to any of your syntax rules or other misguided preconceptions about files having structure. So, when you have to run a Talend pipeline on vaguely-comma-delimited text files which may once have been machine-readable, you can make your own component which is literally just a block of Java code to parse the file using the Zerg Rush Of Ad-Hoc Rules Technique, an oft-overlooked method for designing parsers. You can also use that kind of thing to make components which are tasteless enough to demand state variables other than the stereotyped kind Talend itself provides.

> Another problem is that managers/CEOs think that if you have no-code tools you no longer need engineers.

Or you can cheap out on engineers, because they don't have to code, just use a GUI (which must be easy, it's just point-and-click right? /s) and don't realize that, to solve any problems except the most stereotyped happy-path examples, you need more expertise because now you're actively going against the grain. This isn't as bad in Talend as it is in other things I've worked with, but even in Talend once you start writing actual Java in the components you need to worry about scoping rules because your Java code is just dumped into the middle of a great big method written by Talend itself and the Java compiler isn't in on the gag.

No-code doesn't mean no code, it just means your code is hidden. Engineering is a skill set and it doesn't start and end with writing code.

Such things make the easy stuff easier and the hard stuff impossible.

As long as that's understood that's fine. If it's not you are in trouble.

I think that low-code platforms can fill a need where they can help a team iterate on a solution without IT and get to a 80% solution that solves real problems, then bring in IT to help productize it rather than trying to start from scratch.

But that's a lost cause until there's a meteoric shift in our industry towards standards and modularity, which either will never happen or won't happen in the lifetimes of the current generations.

That said, as development tool chains grow in options and complexity , I do see these things as being a bridge for some people to get their feet wet. Self taught devs can start here and then code later when needed. But that’s just a theoretical use case/market void that may not really exist.

Software Engineers will have their place but no code and AI is aiming for the masses.