Low-code is not a cure for overworked IT departments

https://www.zdnet.com/article/low-code-is-not-a-cure-for-overworked-it-departments-just-yet/

by Brajeshwar • 4 years ago

162 202 4 years ago

I think low code and AI have an incredible productive future. ChatGPT can create simple python programs right now. Imagine a few years from now, where it can output a low code program; that will be game changing since there won't be a need to have a software engineer to deal with the code. It's coming and it's coming fast.

mrits• 4 years ago

I don't see the benefit of creating code with ChatGPT. I can already get code for next to nothing by outsourcing.

arcturus174• 4 years ago

Next to nothing eh. Tell us more about the technological complexity of what you're building... Because I'm already seeing good dev shops in India charge $30 and upwards, and while that's "nothing" compared to US salaries, it's non-negligible (and it has trade-offs).

denimnerd42• 4 years ago

sounds like optimism we saw with self driving cars

WheelsAtLarge6• 4 years ago

True, cars may never drive themselves but I guarantee that at some point we'll have vehicles that have very specific functions self drive. I can even say that cars that self drive in the highway only are just around the corner.

No code won't fill all needs but they have a place in business.

debarshri2• 4 years ago

Everyone is talking about chatgpt and code generation this week. I think the code generated with chatgpt might be 90% accurate but how confident would you be to deploy that in production. We know empirically that last 10% can take decades to get it right. Using gpt to generate a blob of content is different from using gpt to generate code.

tablespoon• 4 years ago

> I think low code and AI have an incredible productive future. ChatGPT can create simple python programs right now. Imagine a few years from now, where it can output a low code program; that will be game changing since there won't be a need to have a software engineer to deal with the code. It's coming and it's coming fast.
Everyone is talking about chatgpt and code generation this week. I think the code generated with chatgpt might be 90% accurate but how confident would you be to deploy that in production.

I haven't been paying close attention, but all the code I've seen it generate is also very simple -- like the kind of stuff someone could write after taking an intro programming class, prompted by a pretty detailed specification.

Modern-day software engineers basically write detailed specifications, they don't translate specifications into "code." Whether you're writing "AI prompts" or Python, it'll still be software engineering. Though my gut feel is software engineering by prompts will feel like typing with a wet noodle to hit the keys.

adolph2• 4 years ago

Maybe it would be better to use AI on the test side of TDD. Have the AI listen to the requirements and write tests. Have the human write code to the tests and update the nonsensical parts of AI generated tests.

CodeyWhizzBang• 4 years ago

The problem is, creating the code isn't really the bottleneck. It's the stakeholder negotiation and conversations and understanding the business problem and updating the site when the business problem changes and updating the wording and changing the site because legal are unhappy with it then changing it back because the CEO overruled them and so on and so on.

zubairq• 4 years ago

So spot on! +100 this!

acedTrex• 4 years ago

since when has writing the code been the hard part/blocker for this stuff lol

WheelsAtLarge6• 4 years ago

What people aren't seeing is that this opens coding to a large number of people that only need minimum skills to create a solution. A determined business user can put together an app that takes an expert now. No code is targeted towards the users that have a relatively simple app but don"t have the skills, budget or time to learn a programming language. I've known people that have put together the needs requirements and design an app but don't have the skills to write it. That's the ideal market no code is aiming to get.

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

maxbaines2• 4 years ago

I think this is exactly where the value is - I commented similar on this thread (didn't see you comment..)

arcturus174• 4 years ago

Low-code has been promised for the masses for ages, and has barely fulfilled that promise. I have seen a lot of non-techies come up from solutions, from websites or eCommerce stores, to little Zapier integrations, to a simple CRUD system with Airtable. Low-code is great for these use cases, but they're really simple. Anything beyond trivial complexity, these people generally stall and they need to hire designers or programmers. Hey, it's fantastic for that first 1% and that's already a lot, I'll give you that.

I actually think low-code will see a resurgence serving "almost technical" people such as tech business analysts, and also, drum roll... programmers. There is a current generation of maturing low-code tools (ex: Retool, PowerApps, Plasmic, Builder.io) which allow tech people to combine low-code and code as needed and which programmers may actually find attractive.

As for AI (ex: GPT), the main output it provides is code. It's nearly impossible to operate it at present for code-generation tasks without knowing how to code. Yes I think it's inevitable we will see a tool that blends current low-code graphical programming with NLP inputs. But it sounds very complex to make and I think it is likely to face the same base problems that low-code has.

arcturus174• 4 years ago

Are you a programmer? Or are you basing this off the results that programmers have been getting out of the tool?

WheelsAtLarge6• 4 years ago

I'm a programmer that has been in many situations where I've had to tell business users that I don't have the capacity to work on their project even though it's relatively simple. That's why I believe no code will be a great asset to companies.

YurgenJurgensen2• 4 years ago

What good is a chatbot that can write code if nobody knows how to maintain the system that code runs on? In the time it takes to learn how to use AWS and administer servers to the point where you're not a massive liability, you could have learned JavaScript and Python from scratch (and learned actual Scratch while you're at it).

recursivedoubts• 4 years ago

There is one thing that works in tech, and boss man doesn't want to hear it: pay a small team of good developers a good wage and treat them well.

The second a difficult bug arises in your low-code (or, now, GPT-generated) solution, good luck.

giantg2• 4 years ago

Yep, the auto-generated stuff is a nightmare to understand. I've found it hard even switching from the old monolith architecture to the new Cloudformation stuff. But maybe I'm just stupid

mathgladiator2• 4 years ago

But maybe I'm just stupid

No, I believe the cloud stuff has evolved in a way that is just strange. I know I'm not stupid, and I look at this stuff with suspicion. This is why I'm going vertical by owning my entire stack (except Amazon S3 because it is awesome...)

ilyt2• 4 years ago

I think it's just idiosyncrasies of one system create idiosyncrasies in next system that uses it.

Nobody would design it like that from scratch but having only already existing stuff to build on makes the end result more complex that the problem it solves requires

theteapot• 4 years ago

There is one thing that works in tech, and boss man doesn't want to hear it: pay a small team of good developers a good wage and treat them well.

And have a compelling product ...

azemetre2• 4 years ago

I know someone that is an executive at a F500 who does this with his team. According to him most divisions similar to his require a staff of 150-200 but he gets in done with 50 distributed around the world (mostly Poland & US). He tells me that he still has to argue for his budgets despite massive success and other adjacent coworkers get very toxic once they find out a division in the company pays good wages to their workers. Not only do they get good pay, but the SWEs love working in the org because their leaders regularly listen to them and employ solutions they suggest. There is very very little turnover in the rg.

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.

galdosdi• 4 years ago

What they don't get outside of Big Tech is that non-junior developers are (relative to the traditional pre-software 20th century industrial business model) more like managers than like line workers. It's just that the "workers" we manage are robots.

But even a pretty low level developer is going to end up making important business decisions just incidentally as part of their job, because it's hard to specify out every little decision that could impact the business without basically doing the dev's job for them.

Businesses can embrace that or they can ignore it at their peril.

ok_dad• 4 years ago

I bet your friend works super hard to manage 50 people as well as you say. I was in the Navy and the primary way to make a division/department great was for the leader to work 2x as hard as their peers to make sure theor division/department was performing awesomely. I recall having to get up 2 hours early to review my division's maintenance schedule so I could do surprise spot-checks. Peers would let the 1st class PO choose the spot-checks, and of course they're going to chose the easiest and fastest ones to finish, rather than something representative of the most important maintenance that day. The thing is, my division wasn't angry at me for doing the hard spot-checks (or anything else I was a hard-ass about), because I also spent more time to make sure they got ranked at the top of the stack and fought for them to get more time off and freedoms even if my superiors got irritated at me, so they were willing to work hard and perform above the rest of the crew. Managers that suck and don't work as hard have shit teams.

Joeri• 4 years ago

Something is extremely off with modern corporate America.

That’s because large corporations are typically run like communist states, where the workers have little say in their own work, and tyrannical unelected leadership sets up hierarchies that reward political infighting to build power.

Why don’t corporations try democracy and bottom-up decision-making? Is corporate capitalism incompatible with democracy?

andrewflnr2• 4 years ago

I'm curious exactly what that toxic and pissy behavior looks like, and how it's motivated. Is it just because he's making them look bad?

that_guy_iain5• 4 years ago

The reason the boss man doesn't want to hear your thing is that it's basically super hard to get.

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

ambicapter2• 4 years ago

The tech department has better working conditions that most other departments.

How many departments are asked to check in every single day with what you did yesterday and what you plan on doing today?

orwin• 4 years ago

Not a good place to be in because they never care as much as you do.

What you really want is developers who understand your solution and your stack, and actively want to contribute.

And for that, you need a good team mentality, easy-to-read code, and a good onboarding. And avoid crunch time as much as possible, especially when a new hire arrive, because you want him to ask dumb questions asap.

[useless personnal anecdote because i feel great about my new workplace removed]

loudmax• 4 years ago

Without knowing the background to that anecdote, the impression I get is less that the tech folks at that company were coddled than that the marketing folks were undervalued. If the marketing folks really are providing value for the company and doing a good job marketing the company, then there's no sense in forcing them to miss lunch. If the marketing folks require so much micromanagement that they can't be trusted to schedule their own lunch breaks they probably aren't contributing significant value to the company anyway, so they should be let go and replaced with a more responsible marketing department.

It takes a lot of different skills to run a company. Even at a tech company, tech isn't the only skill that matters.

BlargMcLarg• 4 years ago

after their solution took down the whole system in cascading failures because it was returning 500 due to the non-serverless database not scaling

Why is a single dev able to take down your entire system without intention?

They can write quicksort but have no idea

So don't use quicksort or identical questions and ask them more.

Your entire anecdote can just as well be held as testament of how a company's process is completely fragile. Which is at least a yellow flag as to what else it is hiding.

Yizahi• 4 years ago

You don't need good developers as in top quartile genius ones. Even more, they don't want to work at your bank or web shop. You need good developers, where good means "decent human beings" while being just average ib talent. Those can be found without gigantic effort, I'd say a majority of developers fall in this category. There is only one hard requirement for recruiting such average team. To hire and retain developers who are "decent human beings" the manager/hr should also be good, as in "decent human beings".

chasd004• 4 years ago

you're possibly dependent on a third party to fix the bug.

IT departments love this, because it's not their problem and they don't have to do anything except press reload in the third party's ticketing system.

jjav• 4 years ago

"Good developers" are hard to find. Average developers aren't even easy to find nevermind ones that are actually good.

That's really not true. You don't need to find a Linus or Ken Thompson for that enterprise system. All you need is developers with sufficient maturity to not be distracted by shiny objects, who are proud to build reliable secure systems with the most boring technology applicable (complexity is the enemy of everything, including security, availability and maintainability). These people are easy to find. Yes, you still have to treat them humanely and pay fairly, but finding them is easy.

One factor that may seem to make them difficult to find is the current interviewing landscape. If your hiring process is laser focused on hiring leetcode ninjas, you will staff teams full of leetcode ninjas. I will say the union between the sets (leetcode ninjas) and (maturity to favor stable solutions) isn't super huge.

If for anyone who is doing leetcode hiring (not specifically leetcode, but that mindset) and finding hiring competent people difficult, I can suggest to change your hiring practices and your world will change dramatically.

(Or don't, leaving even more competent developers for me to find even easier.)

blowski• 4 years ago

It’s not that simple though, is it.

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.

ckdot3• 4 years ago

If you are a decision maker, especially a CTO, you should be able to know who to give all the money. True, there are too many people making the wrong technical decisions and by this increasing the complexity of a project easily by 10x or more. But, to answer your question, if someone doesn’t know, (s)he’s actually simply not in the right position.

Nextgrid2• 4 years ago

When it comes to over-engineering and solving zero real-world problems, that's mostly a company, management and/or investor problem. There's many startups out there where the primary goal is not to solve a business problem profitably but to build a complex engineering playground so they can be part of the "cool kids" club and justify the next VC round.

This translates to hiring - if your job spec is nothing but buzzwords you'll attract the kind of people that "engineer" for engineering's sake and resume value as opposed to solving your business problem (hell, does the job spec even include the actual business problem you're solving beyond vague platitudes about changing the world and boasting about their VC funding?).

Salaries need to reflect it too - if you pay too low, the only people that can afford to work for you are those that do so for the resume value rather than the money or the fun of playing in an engineering playground and potentially becoming its lead - with again zero concern as to whether they're solving the business problem. The kind of engineer you'd actually want usually already makes good money and no longer needs the resume value nor can be bothered to over-engineer.

Even as a contractor I've had plenty of leads where it became clear they weren't looking for an efficient solution to their business problem but an over-engineered mess to expand their engineering playground and my counterpoints fell on deaf ears.

ken47• 4 years ago

And/or find a developer who makes your other developers better. I've been on many teams now where basic principles of establishing positive team dynamics are ignored so that people can gratify their insatiable egos.

tommiegannert• 4 years ago

The Capterra post that zdnet refers to: https://www.capterra.com/resources/how-pms-can-use-low-code-...

zerkten• 4 years ago

It's worth noting that these low-code solutions indirectly drive usage of the SaaS products that Capterra lists and analyzes.

tootie• 4 years ago

I think the low-code app market has largely fizzled but the low-code data integration market is red hot. Building ETL/ELT and the like is now very much automated with platforms like fivetran. Things that used to require a date engineer are now routinely being done by analysts in much less time.

maerF0x03• 4 years ago

You don't pay a great team of engineers for a solution today. You pay them for the agility it gives you tomorrow.

Too often I've seen companies offshore a project only to require a full rewrite in 6 months because "that wasnt in the spec" during the first version.

Well written software expands your options as it grows, not shrinks them.

miroljub• 4 years ago

That's true, but if you don't pay in advance for well-written software, you are not going to get it later.

maerF0x03• 4 years ago

While there is a correlation to pay, I'd say it's more true to say it's more about hiring for that mindset, and cultivating a culture that understand quick hacks are the slowest/most expensive way.

You can pay more for crap engineers if you dont know what you're looking for.

macspoofing• 4 years ago

What are examples of 'low-code'/'no-code' approaches/products used by PMs?

dysarray• 4 years ago

Perhaps Mendix, Bubble, AppSheet, and QuickBase fit the bill.

isquaredr2• 4 years ago

Our team has built a low-code solution to build simple web views and help lower the barriers to making changes. So far it has not saved us any time and arguably has made things worse. The requirements coming in are complex, so instead of building the views in a comfortable environment (our IDE) we are building the same amount of complexity in an environment with rough edges (our LC/NC tool). In my opinion we have misidentified the bottleneck. In reality the time sink is getting clarity on the requirements and understanding the interactions of the components on the page. Whether that page is made in an IDE or in our tool is largely irrelevant.

bob1029• 4 years ago

In reality the time sink is getting clarity on the requirements and understanding the interactions of the components on the page.

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

robertlagrant• 4 years ago

"Configurable" is a manager-trap, just like low code. If something's configurable, you now need to forever test all the potential configurations, which always seems to become a combinatorial explosion of tests.

suzzer99• 4 years ago

A huge part of my job as a developer is organizing the business person’s thoughts for them, and filling in the non-happy-path 80% of the app that they don’t care about, but their users do.

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.

brundolf• 4 years ago

I've had some bubbling thoughts about no-code that I think just congealed:

No-code is subject to simplicity vs easiness just like code is (https://www.infoq.com/presentations/Simple-Made-Easy/). No-code tools tend to put a huge focus on doing one or both of these things. They're core value-props. But I think the question of whether or not a tool gives you sustainable value comes down to the simplicity axis (vs just making it easier to add more complexity)

A no-code tool that's easier but more complex than the equivalent code solution is probably going to be a net-loss, at least in the long run. Whereas a no-code tool that helps keep things simple by presenting a narrow, focused representation of a system (instead of general-purpose code) can be beneficial.

In a way, no-code can be thought of as a(n invisible) DSL + a GUI

twawaaay• 4 years ago

The issue with low code tools is that they typically solve the easy problem.

What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way.

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

Guess what. Software engineers do not just code. They know how to build stuff, which includes a huge amount of knowledge of how to construct maintainable and reliable systems. Put non-engineers on the problem and you will get an unmaintainable mess that is going to be failing a lot.

You try to string your system from a bunch of low-code tools. You quickly integrated a dozen different online tools. Now you find out nobody can understand what is going on. If you hire a person, they will spend a huge amount of time learning all of those tools.

If you build an application let's say in Java, it is much easier to get around the system and understand how it works. If you can read and understand one module, you can pretty much read and understand all of them. But with low code tools strung together there is pretty much new problem, new language, new paradigm for every of those tools.

Part of software development is ability to modify things in a safe way. Having test environment, code versioning, integration and deployment pipelines, etc. Having practices around building stuff. Almost no low-code tools respect any of it. At best you can build your own custom solution for each one but forget trying to prepare v2 of your system and deploy it in any organised way. Your production usually becomes your test environment and your deployments will typically result in some minor drama.

I get the appeal of low/no code tools. It is super fun to get something working very quickly with no resources. If you have a simple problem that matches the tool perfectly and you will never want to make it much more complicated -- it might even be the best solution for you.

The issue is that management wants more and you will have to field requests for new functionality and requirements. And you will quickly find adding those will start taking exponentially more effort while you are necessarily spending time talking to your sales reps trying to figure out if/when they can provide the functionality. All this while you have trouble hiring and onboarding people to maintain it because there is just so much magic that only your initial staff is only ever able to understand what is going on.

msla• 4 years ago

What happens is that it is usually very easy to get a simple thing up. Then you try anything a bit more complicated or not standard or anything breaks and you spend way more time trying to figure it out than it would take to building the normal way.

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.

malfist• 4 years ago

Non engineers know nothing about big o notation or tight coupling. Every time I've seen no-code solutions created by non-engineers it's been O(n^4) monstrosity or worse that's so tightly coupled with it's dependencies that it's a fragile nightmare to keep running.

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.

hateful• 4 years ago

I always give the example of my first .NET program (2003? Forgive me if I forget some of the names of things). It was a report page for showing some counts of a field in a file. I build an aspx page and put the asp:Table on it and set the DataSource and in no time I had the list. Then we had to add the total. This required adding a Footer control and some custom code - no problem. Next we had a requirement to add a sub total throughout. This was impossible. So I had to completely throw out everything I'd done and re-write it.

DrScientist• 4 years ago

Yep you nailed it.

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.

bitwize• 4 years ago

It creates work for already-overworked IT departments.

Think about the sales pitch of low code: Now your marketers and business people can put together solutions to automate business processes, without writing a single line of code (or while writing very few lines of code)!

Except yeah, weeks or months in, those solutions have to be maintained as the business shifts. Sales, marketing, and executives have better things to do than maintain a bunch of instructions for the computer. How will we handle this? Oh, I know! Let's throw it over the wall to the people who specialize in this sort of thing: the software engineers! I'm sure they won't mind prioritizing maintaining the automation we built in $LOW_CODE_PLATFORM over the backlog of other things they have to do.

What are you asking? Where are the debugging tools? Low-code is supposed to have no bugs, what do you need debugging tools for?

Version control? Pffffffff.

Oh, and while you're at it could you integrate the $LOW_CODE_PLATFORM stuff with our mainframe? The source of all truth for customer records is still in the mainframe and--you need to write an extension module to do that? In Java?

pizzaknife2• 4 years ago

wordpress has modeled this for ahhh almost 2 decades? infer what you will from that analogy ;)

maxbaines2• 4 years ago

One advantage with low/no code I have seen be successful, is allowing non IT teams to do the work themselves therefore reducing the load on IT teams. Notice I said reducing as oversight and training is still required.

It also helps the other teams understand the complexity of there problems (sometimes), and helps IT teams understand the use-case or idea.

I have seen project lead times reduce from month's to days.

All said and done though technical oversight and management is still required.

jordanbeiber2• 4 years ago

Have you lived with it over longer period of time?

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.

WheelsAtLarge6• 4 years ago

Lots of code gets rewritten as it evolves. Even the best developer can't predict the future. And very few can write code so fluid that it adapts to future use.

Also, there are apps that are useful but don't need to be used enterprise wide. No code will change the work environment similar to the way the the spreadsheet changed it.

bee_rider2• 4 years ago

I wonder if it would be possible to have a no-code tool that

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

TeMPOraL• 4 years ago

One advantage with low/no code I have seen be successful, is allowing non IT teams to do the work themselves therefore reducing the load on IT teams.

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.

WheelsAtLarge6• 4 years ago

The company IT department has been disappearing from enterprises for years. Companies use SaaS apps and outsource many of the other functions so no code is just another step towards a no IT department. IT costs are an easy target for cuts so expect all functions to be reduced or outsource over time.

raviparikh• 4 years ago

Agree with this post. Low-code lets a non-engineer build 80% of an app quickly, but then ultimately that last 20% requires engineering work and it ends up taking more total eng/IT time to create something far less maintainable and useful.

I think the best low-code platforms are ones that are ultimately built on top of code (eg Webflow, where the underlying representation is normal HTML/CSS/JS). I wrote a blog post about how I think low-code platforms are broken and how they could be fixed: https://www.airplane.dev/blog/how-to-fix-low-code-with-more-...

weego• 4 years ago

I would like to see a general acceptance from people that the thing they think they need can really just be described in a more generic and less "we have unique needs" way, which is often a good chunk of the missing 20%.

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.

adolph2• 4 years ago

Low-code tools are typically oriented toward technology rather than information. As such they are analogous to automating buggy-whips instead of improving transportation. Below is an example of what focusing on information can do.

IKEA’s knowledge graph and why it has three layers: https://news.ycombinator.com/item?id=32749633

ogogmad• 4 years ago

If you allow LLMs (Large Language Models) to directly call out to APIs, like POSIX, Vulkan, Win32, X11, etc. then it may become possible to program things using a "Socratic" method that involves producing no code at all. You simply channel inputs to the LLM, collect API calls from the LLM, and execute the API calls it makes. This will create a feedback loop that'll eliminate the need to produce code at all. Code can then be produced selectively as an optimisation, like what we call "compilation" today.

Of course, it's currently unreliable and slow, but the trend is a fast one.

Additionally, it might be given a memory store it could read from and write to -- and a StackOverflow-like network to curate advice from other AIs like itself.

A half-way version of this might soon start to exist.

ilyt2• 4 years ago

And we will be able to blame production melting down on "AI" misinterpreting what someone said.

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

dragonwriter3• 4 years ago

Fortunately, the business user to analyst to dev game of telephone with people never results in misinterpretations that survive to production.

ehutch79• 4 years ago

100% someone would say 'delete the users from my contact list in the system'

mjburgess• 4 years ago

The problem with these generative systems is that they're synthesizing existing code and their output isnt therefore always valid. Ie., they arent programming (which involves following discrete constraints of the language).

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.

anotheracctfo• 4 years ago

Oh god no. No please don't let "power-users" anywhere near a Low Code framework. It doesn't take long for them to fuck up and go ask a real developer what is wrong. I've seen things...

dragonwriter3• 4 years ago

The problem with these generative systems is that they're synthesizing existing code and their output isnt therefore always valid

Actual programmers have this problem too, though they often use non-AI tooling to catch and prompt them to correct invalid code.

No reason a system using an LLM for code generation couldn't do that, too.

Anticipating the “but even if it is valid it won’t always be correct” followup: well, valid human-written code also often has bugs.

wongarsu• 4 years ago

At that point, the LLM is just a compiler, and your prompt becomes the "code".

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.

thesuperbigfrog• 4 years ago

> You simply channel inputs to the LLM, collect API calls from the LLM, and execute the API calls it makes.

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.

rustybelt2• 4 years ago

My low-code exposure is mostly limited to Microsoft SSIS, but my experience is that the only people skilled enough to build reliable and maintainable packages were already good coders.

hinkley2• 4 years ago

QA took a hit because developers saw how unmaintainable the test code was. Operations writes code that’s almost as bad as what QA writes. Non coders writing code always makes a bigger mess for the actual coders.

pizzaknife2• 4 years ago

friends, lets not berate, belittle, or subjugate each other and instead share the practical experience. Its a hard sell - i guess my so is right: i should start a blog. downvote this old timer's ramblings - sometimes we need to spell out what we resist

wonderwonder2• 4 years ago

I am currently working with low/no code to build an application that will form the backbone of the core domain at a F500 company. The application will eventually host 1000's of users across the world. The main takeaway is that there is a world of difference between work produced by someone with actual real world coding experience and those that just learned on the no code platform. Real engineers are able to use the platform as essentially just another programming language while the non engineers build horribly inefficient outputs. When you speak to the non engineers its clear they have no concept of what it takes to make a system work and scale or anything that a software engineer would consider vital to a robust application, they just connect component A to component B. No code is just a tool, the quality of the builders controls the quality of the product. I will add though that there are definite gotchas to no code environments that can spell disaster to the end result. I have found things like hidden settings in the platform that control memory management, state, etc. Pretty frustrating to realize suddenly your application cannot scale and its because of something hidden in an environment level setting somewhere that no one even told you existed.

bee_rider2• 4 years ago

Were you in the room when it was sold to you? Curious if these things are sold as “more convenient tool for your existing programmers” or “you won’t have to hire so many programmers.”

wonderwonder2• 4 years ago

Nope, project was already rolling full steam ahead before I joined.

jerf2• 4 years ago

Circa 1997 I started work in web development. It was a wild and wooly time. We effectively produced a time & attendance system for a major university using ASP. Not ASP.Net, ASP. And frames, lotsa frames. Fun times, but... we did not have any of the following:

    * 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

and I'm honestly probably forgetting a few things I could add in that I now consider a bare minimum for a production professional deployment.

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.

marapuru• 4 years ago

Thanks for this great piece of text. It triggered some memories. These tools exist for a reason. Let’s hope we don’t have to use your highway construction analogy too often :-)

/me standing up from seat and clapping loudly

Tomis02• 4 years ago

certainly wasn't following 2022 best practices by any means

Could you please share a few examples of best practices not followed?

chasd004• 4 years ago

This sounds like either a Salesforce project or the Microsoft equivalent (i forget what it's called). I do a lot of Salesforce, the best Salesforce people for configuration and customization are seasoned software developers.

mmcgaha• 4 years ago

My own experience with a few low/no code tools:

Power Apps: A raw app is easy to get running but a nice app that does what I want is hacky.

Pentaho Data Integration: Super easy to use and maintain.

MS Access: Fast development and you can do actual programming if need be.

Among these tools, I just don't see a need for power apps and desktop apps written in MS Access are not something people are looking for any more. PDI on the other hand makes it easy to ETL data and has saved me countless hours over the years.

AtlasBarfed• 4 years ago

These are code generators right? Right? With the usual code generation issues with debugging, verification, or long term maintenance?

Or they are workflow tools, sold with simple graphical demos of easy state machines / START -> box -> box -> box -> DONE flows, but when the rubber hits the road you encounter branching, loops, retries, subroutines, error codes, suspended/paused flows, state management, and full on turing machine processing.

Or they are AI tools, and you are relying on statistical probabilities that the code does what you want to, and statistical probabilities that the AI isn't producing the answer that looks right and the one you want versus the actual answer?

Or you are writing so much testing/quality control /verification that you might as well have coded in the first place?

Finally, you are invariably dealing with a vendor, and massive massive massive vendor lockin. Have fun when Oracle acquires them, triples the price, and audits you every other year.

heisenbit• 4 years ago

LC may be a way to quickly get to the happy path but for reasons deep in business processes and underlying technology the happy path is just one of billions of possible paths most of them leading to a not so happy result. Dealing with exception and error situations in a sane manner is hard and I don't see it getting easier. Certainly not by adding a few abstraction layers.

shireboy2• 4 years ago

I see the appeal of low/no code, but have yet to find a platform that I think does it well. The sell is that "business users" can write their own apps/sites/etc. That ends up not materializing - business users don't want to or can't. So they get a dev to use the tool. So now, a dev is stuck using a tool that feels like death by a thousand clicks and locks the org into a subscription and ecosystem.

I do feel like there is a solution here. On the dev side, what should be simple business apps written in code are too complex, and have too much cruft. Upgrading frameworks is a hassle. It should be easier.

I feel like a popular really well done open source AI code generation tool could solve this and is waiting to be written.

okennedy• 4 years ago

Good low/no-code solutions do a great job of aiding discoverability and cutting the need to grapple with a language's syntax. Unfortunately, while this is a roadblock for many, the challenge is more fundamental. What makes a good programmer isn't knowledge of a language, it's the ability to translate a vague description of objectives into a precise specification of a solution (especially when the vague description is under-specified).

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.

shireboy2• 4 years ago

Spot on. I tell people all the time my job is to translate from English into Nerd.

tstrimple• 4 years ago

I’ve had no issues with power automate and logic apps the few times I’ve had to use them. The last time I called voice to text and sentiment analysis APIs triggered on receiving an email with an audio attachment. It would reply to the email with the transcription and sentiment details. Was stupid easy and took about an hour to build and test and it just worked and has worked without any issues for the last three years. I have no idea how well most business users could work their way through something like that though.

pfoof• 4 years ago

ELI5: low-code/no-code is nothing new, it was with us for longer than you can imagine, so why do we expect that nowadays it's gotten so much better that it can replace normal programming?

For me it sounds like another Web3AIBlockchainVRMeta fad, like those trends in history: romanticism, baroque, enlightenment, etc.

tyurok• 4 years ago

It seems it comes back every year or two, coincidentally on market downturns.

conductr• 4 years ago

Asked and answered. But someone is selling the trend and making money on it. Whether it’s a good long term solution to anything is rather inconsequential to them.

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.

slt2021• 4 years ago

Low code/no code == low quality / no quality code. You produce simple hello world or CRUD type stuff (but these should be replaced by SaaS, like google sheets/google forms/airtable/etc).

Anything more complicated - you are looking at mountain of glue scripting to stich together different parts and maintaining that frankenstein of code

badrabbit2• 4 years ago

Low code like powerapps however solve a myriad of problems for regular users but I agree with the post.

The one area I find a bit concerning is governance/management around the data and permissions low-code apps ask. In a powerapps context for example, the app might ask permissions to read all your onedrive, sharepoint or email and it may even have a good reason to do so but now that means if the regular user who composed it gets compromised, threat actors get all that data from the user's of the powerapp.

I am guessing other low code frameworks also work with some business or user data. Low code means easy to compose and less low level coding error related vulns but you can still have a vulnerable low code app.

giraffe_lady3• 4 years ago

Yeah the only low code I respect is excel.

YurgenJurgensen2• 4 years ago

Isn't it even worse than "get all of the data"? Don't you also gain the ability to impersonate anyone who clicks through to the app?

badrabbit2• 4 years ago

Delegatedimpersonation is possible in an AAD context so technially they can request that but I'm not sure the lowcode UI would let them.

awesomegoat_com• 4 years ago

IT departments are not overworked.

They are burned out. Not overworked.

Burn out is malfunction of the meaning.

Somehow non-technical people managed to remove the meaning for the technical people. Is anybody surprised?

Fix is simple. Remove management insert leadership. Simple, not easy.

cogman10• 4 years ago

I was once a part of a team who's job it was to create a low/no code solution for our product.

The issue we hit square in the face is that while it was easy for our C level person to say "Yeah, this is simple, let's just make a low code solution!" when rubber hit the road and we started asking "but, what should this DO. What sort of solution do you want?" we got nothing but "We want it to do everything, but we also want that in the next 3 months".

In other words, they wanted a full blown programming language and integration with our legacy system (with literally 1000s of datapoints) all done with like 5 devs and no requirements other than "everything" and a PM that couldn't give us a "we are successful if we can do x" sort of usecase.

Needless to say, it was a giant CF and failure.

On the flip side, the low/no code solution that I've seen work unreasonably well was doing a custom groovy dsl hooked into the necessary bits doing data transforms. It worked great for us in dev because we simply wired in an existing language and it worked great for the product because the people writing the groovy scripts were easier to hire (and often got moved over to dev if they were good enough!).

matus_congrady2• 4 years ago

For me, the main issues of low-code/no-code tools are:

1. Leaky abstractions. Our industry has been developing software for decades, and we almost generally agree that MVC-like architectures offer the best ratio of flexibility-to-productivity. How am I supposed to trust that an abstraction made by the low-code/no-code tool will allow me to implement even a slightly less-common use-case? When I use these tools, I'm constantly 1 use-case away from having to throw everything away and start from scratch using something else.

2. It doesn't solve the most prominent problem - designing the system. Implementing the software is in fact very straightforward and isn't that time consuming. On the other hand, having to think of all the use-cases that your application needs to support, thinking of all the edge-cases and less-obvious quirks is 2 orders of magnitude harded.

3. The highest degree of vendor-lock.

4. Not clearly stating what their limitations are.

I'm not entirely dismissing the idea, and I believe these tools can be helpful in some cases. But I believe that more often than not, people don't get the promised outcome, or even if they do, it doesn't come without significant tradeoffs.

In my oppinion, the better approach to save the time of your development team is to just give them better tools. Tools, that don't require them to completely dismiss the workflows and architectures they are used to. But rather tools, that just improve and simplify what they are already doing.

This was also my main goal when designing https://stacktape.com

I wanted to create a tool, that provides the highest possible level of simplification of DevOps, while at the same time being flexible to cover any-use case. I also very clearly state our limitations - it's only for AWS. If that's a dealbreaker, you won't need to spend 2 weeks to figure that out.

Hermitian9092• 4 years ago

I think the end goal of most low-code/no-code tools to be something where you can get an 80% solution without hiring a real engineer. The second part of that sentence is really important.

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.

matus_congrady2• 4 years ago

This is exactly something I don't necessarily agree with.

I think that this "slightly technical person" won't be able to create that application/workflow with a sufficiently high-enough quality.

Is he going to think about all of the edge-cases? Does he know how to properly validate user inputs?

Also, quoting from the article: "Interestingly, while low-code/no-code are seen as the tool of citizen developers, its primary users are IT professionals, the Capterra survey also shows."

chasd004• 4 years ago

Salesforce does this pretty well. Allowing users to put something together to automate a business process quickly.

Their concept of custom tabs, custom objects, fields, page layouts and the way different layouts are assigned to groups of users by profile make it easy to stand up a lot of record keeping and management that's needed in a lot of plain boring business.

Granted, Salesforce is so immensely wide and deep that many of those advantages get lost in the complexity of the platform itself.

RajT88• 4 years ago

Low code solutions are great for what they call "Shadow IT".

RcouF1uZ4gsC• 4 years ago

While everybody is arguing about how useful low-code/nocode is to IT departments, the people that actually need to get stuff done are just writing it themselves in Excel. It may not be the best software engineering, but it gets stuff done with a minimum of fuss.

dboreham• 4 years ago

mcdonje• 4 years ago

Instead of low-code solutions, we need to better empower data analysts and data engineers to solve problems for BUs. DSLs, API access, config files, templates, etc.

Devs own the infrastructure. BUs own the business logic. Data analysts and data engineers are embedded in BUs, and they're the primary people involved in getting the platforms devs own to service business needs. Instead of giving them low-code garbage, give them an API to call, SQL access, and the ability to build, run, and distribute python applications.

Data analysts are the layer between devs and operations that can solve the problems and ease the natural tensions that arise between devs and ops. Support the data analysts and data engineers.

Don't buy into low-code sales pitches.

rsj_hn2• 4 years ago

The quality of IT reporting continues to disappoint.

The idea of no-code/low-code is to lower barriers to entry. This is a process that started with the invention of C, continued with the much-despised COBOL, and had perhaps its greatest success with Microsoft Visual Basic macros. Yes, professional developers complained about the quality of that code, but it was a boon for many offices and was wildly popular. The idea is to make programming available to more and more people, so that with macros even secretaries could automate some Windows office tasks without needing to learn C++.

This is just a continuation of that process of trying to lower the entry bar for deploying automation. You are not going to write an auto-safety feature or build a load balancer using these technologies, but you are going to allow someone on the margins to automate a data entry process or put together a simple series of webviews.

However if you provide someone with a new tool to take on a new role, that isn't going to solve the problem of the person being too busy with all their existing roles. That's a completely different problem. Of course low-code isn't a cure for someone being overworked. It's meant to help someone with a lower skill level take on new work.

zozbot234• 4 years ago

Not sure if serious... COBOL was one of the earliest 3rd gen programming languages. Back then no one had a clue what high-level programming would ultimately look like, so "make it read kinda like English" was a nice first try at the problem.

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

rsj_hn2• 4 years ago

Not sure if you read my post, but yes I used COBOL as an example of a high level language because it was one of the first attempts. That is what the phrase "long line" refers to. A historical look back at the earliest attempts to do this.

Also, the idea of lowering the bar does not mean you spend 50 years on doing the same thing over and over again. This is also the point I made. First, they dropped the requirement to program in Assembly and created higher level languages such as C or COBOL. Then they dropped the requirement of having a separate toolchain/build infrastructure and created VisualBasic. It is quite foolish to think that VisualBasic was popular because of its syntax. VisualBasic was popular because the developer environment/runtime were bundled into the office suite. Programs were extremely portable and the runtime was everywhere. It is the same reason that javascript became popular. That got rid of a lot of infrastructure and lowered the entry bar. It was the macro feature that made it a success, not the syntax. Then comes the no-code toolkits which have drag and drop and other features which you can get really distracted by, but they really work on the basis of a fixed set of libraries and a fixed set of calling conventions that is intended to simplify the chores of library selection and invocation. Again, the point is to remove or simplify something by automatically providing it.

How much of a success it is will depend on how good it is at removing complexity for the set of tasks it is designed to tackle, which will ultimately be decided by market adoption. But one thing these tools cannot do, is free up people who are already busy. What they can do is lower the entry bar so people who wouldn't be productive because the barriers to entry are too high can be productive at rolling out simple automation tasks. The Marketing exec rolling out some clumsy dashboard reporting tool via a no-code process is the natural evolution of the secretary creating a form with visualbasic, which is itself the natural evolution of an accountant writing a script that calculates a depreciation schedule with COBOL.

atoav• 4 years ago

In a lot of areas the cure is just hiring the right amount of people instead of trying to milk every last drop of work out of the existing workforce.

Parcel delivery sucks because the routes the normal delivery person has to drive are so on edge that even the slightest anomaly will produce delays. I'd happily pay a euro more for shipping that does not suck and the employees would happily work in such an environment. Still it does not happen, because somehow somewhere someone decided this was the way it should be.

Same for IT. Want things not to suck? Just hire the right amount of people, pay them the right amount of salary (to get the right amount of expertise) and you are good to go. Don't want to spent that money? Then you are paying every day for the money you saved there.

swagtricker• 4 years ago

No, no. Go right ahead and sink time and money into this sort of crap. Just like every attempt before, it'll generate a pile of garbage that's unmaintainable yet will still manage to poop out ONE single nugget of value: determining what needs to be built after the idiot suits thrashed all around with the 'wonder toy' system. Then, we experienced developers can have a walk in the park while cashing out on contracting rates. Fat stacks of cash simply for replacing exact like-for-like functionality with REAL software and then bring in the extensions the vendor toy systems couldn't. I could do with a nice, easy, early retirement path to pop up in 7 years. Bring it on ;)

rmnclmnt3• 4 years ago

This is exactly what the "booming" HRTech sector is doing right now, crazy stuff going on

redleggedfrog• 4 years ago

I'm frequently on that receiving end of low-code implementations that have failed, and I'm not quite as fond of it as you. ;^)

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.

tabtab2• 4 years ago

"Those who don't know history are doomed to repeat it." I haven't seen any "low-code" tool with technology and ideas noticeably beyond what such tools tried in the 90's. If there were some kind of breakthrough that gave such tools something earlier tries didn't have, then maybe it would be time to take a new look. But until then, I'll remain skeptical. Remember Steve Balmer's smarter brother: "Maintenance, maintenance, maintenance!" (hypothetical brother)

yrgulation• 4 years ago

Yes please. Do the same with ai generated code.

JBlue42• 4 years ago

It's interesting how we have decades of knowledge and experience that sales people typically blow smoke up the execs you-know-what and fail to deliver to various degrees yet those execs are still gung-ho on implementing expensive 'solutions'. I've seen it where the people below them that have to do the day-to-day work on it have other ideas but are then forced to use these platforms and explain it to those execs, and why they may not be working.

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.

rustybelt2• 4 years ago

"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'"

Definitely true. Also don't discount the influence of good old fashioned corruption - cash kickbacks, job promises, gifts, etc., I've seen IT contracting decisions so dumb that graft is far and away the most logical explanation.

carl_sandland• 4 years ago

I think that low code has some promising application areas, just not building operational systems; 1. As a requirements gathering (business prototype?) tool (the outcome is a spec used to develop the real system). 2. As a 'leverage' tool to magnify experienced coders time. 3. As a 'partial' core in an operational system written by coders (the business engine), but that's just rules based and has been around for ages.

Drag and dropping boxes with arrows for a fully operational system? yeah haven't we already being trying this for decades, quite unsuccessfully? I'm more intrigued by the idea of using AI to generate acceptable boilerplate crap (eg CRUD crap) and still think very high level languages has potential (small, focused DSL).

A lot of frustrated, abused coders here in the threads, I feel it to.

teddyh• 4 years ago

https://www.commitstrip.com/en/2020/10/07/the-no-code-dream/

dhbradshaw• 4 years ago

I think a lot of times the problem that people want low code to solve isn't IT being overworked but IT being out of their control.

To put it another way, I think the demand for it is often just another manifestation of Conway's Law.

gav• 4 years ago

Exactly, there's a huge appetite for products that allow Marketing, for example, to get things done without IT involvement; I'm not sure why people are surprised that other departments want to do the same.

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.

wanderingmind• 4 years ago

I see the arrogance of devs here who think scalability and performance are the core metrics. They are not. Outside of security, its the customer requirement that takes priority. We can point to a mountain of well written software that the customers wont touch with a ten feet pole.

The trouble is treating No-code as the final product. Its the MVP that can be rapidly iterated which the end customers can play around to visualize and make sense of the product. This helps to understand what the customer wants and if it makes significant improvement to their workflow and creates value. It helps to streamline requirements and get you as close to final design as possible. Any executive worth their value should not be paying smart engineers to build a product that noone is going to use.

rmnclmnt3• 4 years ago

That's the right approach to higher-level tools such as no/low-code! Trying to model your problem using a pre-built software gives you constraints to think about, provides you with an alternative data model from the one in your mind / paper, and can obviously validate an idea with a few days instead of weeks/months!

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!

rmnclmnt3• 4 years ago

In the meantime, most personnel in IT department do not have time for newer apps to be integrated as they are still battling against the organization of Active Directory made 20 years ago... (only half joking unfortunately)

user3939382• 4 years ago

I've been programming all my life, it's great to have the power to do almost anything logical with a computer. But even just CRUD can be a complicated hassle.

Most APIs have idiosyncrasies that you don't learn from the docs. With Zapier for example I can wire A to B without having to setup a project, repo, dependencies, look at docs, error handling, I don't know 100 other things? That's awesome.

Would I build, like, Honeywell's procurement system with a tool like that? No way.

stillbourne• 4 years ago

Low code was more time consuming than just writing ETLs

tabtab2• 4 years ago

We had a bout of a naive executive who wanted to "replace programmers" with such "instant" tools (MS-Power-stuff, cough cough). His team was frustrated that IT was skeptical. I had to write up a 4 page description of why we should tread slowly. Fortunately staff turnover not related to IT ended the nightmare.

I used a motel vs. house analogy. But you had to assume it's not easy to move out of a motel for the analogy work. I'm still looking for a better analogy from the everyday world; some variation of a stitch-in-time-saves-nine.

dgudkov• 4 years ago

Using low-code and no-code platforms is supposed to provide relief to overworked development shops, right?

No, you got it wrong, zdnet. No-code is for people who don't do software development. It's for finance analysts, marketing managers, and similar non-technical professions.

Also, no-code isn't something new. Non-technical people have been using a no-code tool for decades. It's called Excel. Now they just have more options.

danielvaughn• 4 years ago

Low-code/no-code is a mirage in the desert. The illusion is that complexity, cost, and difficulty are the result of "code". Code is actually extraordinarily simple. The simplicity makes it almost infinitely flexible, and because it's so flexible, it's often used to solve very difficult problems.

This leads business executives to think that it's the "code" that is difficult.

Sateeshm• 4 years ago

Bingo! Syntax is almost never _the_ problem.

smeagull• 4 years ago

low-code is a good way of preventing all the controls that development tools normally provide. Had to deal with these headaches when a team insisted on using Apache NIFI. You get merge problems, you can't examine changes on their own, you get one environment to test things (i.e. production) and if it breaks rolling back is extremely non-trivial.

All that work that could be done automatically by tools now has to be done by people showing restraint and following process. And these are the people who want a low-code solution so understand the problems far less.

It's a nightmare. Going to be good money to come in and clean it up later though.

willhslade• 4 years ago

I'm having an ok career in this space contorting Excel, Access, SQL, VBA and Powershell. It's going ok, but I do have to point out one thing that this hype cycle is missing. You are explicitly developing software by people who have never taken data structures, or algorithms or software design. The people developing these tools do not understand what a dictionary is and why you would use it, do not understand when and why you would use memory as opposed to disk, and routinely do things like triply nested loops rather than something sane. And that's before we consider that the tools themselves are nerfed and do not allow you to do things beyond their limits, usually something involving database size.

So, yeah, this is going to be a mess. Fight it, fight it hard and this is just another attempt by the MBA class to devalue skilled labor. Call it like it is, and if they built it and owned it, they can maintain it.

kgbcia• 4 years ago

shh, don't tell them the secret of job security. low code platforms have no version control system like git. it's perfect way to create silos of knowledge

whoIsYou• 4 years ago

There's definitely no reason to be skeptical of the self-reported results from managers that have an obvious conflict of interest when it comes to reporting whether the low code tools they advocated for were a good idea

pyuser583• 4 years ago

Low code makes more work because now product people can create very intricate demos, and expect us to turn them into features.

Low-code is not a cure for overworked IT departments

Related Stories