-4

In the question What is "low code"?, there are many comments against it. One example:

In my experience these tools are managed by business users until they've painted themselves into a corner. Then developers are brought in to untangle a gigantic mess of unreliable buggy garbage with gobs of unnecessary complexity.

However, I think that it's just one of the many tradeoffs that we have to face: simplicity vs complexity. If it's safe to say that Word is a no code program, then this Word vs LaTeX graph conveys my point:

Surely Word has a market for it. It will soon reach its limitations, and soon the users will be frustrated for having to learn another tool that they aren't familiar with it. But if low code is nothing different to rapid application development, then this frustration should be familiar way back to the 90's, and thus they have learned that it's really a need and had to deal with it. Either by:

  • educate the business users before they decide the tools to use, or
  • educate the business users to learn the better tools while the no code/low code tools are being used, so when the time comes the transition is easier, or
  • accept that when the "gigantic mess of unreliable buggy garbage with gobs of unnecessary complexity" happens, it's their job to fix that

Based on the number of upvotes for the frustration in the linked question, and the lack of comments acknowledging that this has been happening from the 90's, I assume that this is still a frustration. They still not accept that this is really a need and have to deal with it. Is this correct?

If you need the software and the segment I'm thinking at, it's Fibery in the ERP segment. You can read its blog here: No-code Revolution. Why Now?

Ooker
  • 315
  • One problem here, is that the process of understanding the problem at a detailed consistent level is a major part of the software development process, that low-code tools claim to avoid the need for. – user1937198 Oct 07 '23 at 16:07
  • Does RAD claim the same thing? If not, then isn't that RAD ≠ low code? – Ooker Oct 07 '23 at 16:10
  • 2
    RAD claimed to reduce boilerplate, allowing you to focus your code on the buisness logic that matters. Not to avoid the need to code buisness logic. Thats the critical difference. – user1937198 Oct 07 '23 at 16:11
  • And RAD did win. Its just thats how we build UIs now so no one bothers to give it a name. – user1937198 Oct 07 '23 at 16:12
  • so basically UI = RAD? – Ooker Oct 07 '23 at 16:15
  • Pretty much. UI + Agile. – user1937198 Oct 07 '23 at 16:15
  • RAD is fundermentally the idea that you don't need to write hundreds of lines describing how to layout the textboxes in your window, you can just have a generic layout engine do it for you. – user1937198 Oct 07 '23 at 16:16
  • hmm. So how are Graphviz and learn.microsoft.com/en-us/dotnet/desktop/winforms/ different to RAD? Also, how would you compare low code with UI+Agile? – Ooker Oct 07 '23 at 16:41
  • 3
    This post of full of wrong assumptions and overgeneralizing statements, which makes it IMHO nothing but a rant. I could start to debunk this one-by-one in an answer, but I think it is better to close the question until you manage to find a way to make it look less biased. – Doc Brown Oct 07 '23 at 16:42
  • 1
    The goalposts are constantly moving. What can be done with "no code" is no longer valuable and now more complex projects are needed, again needing actual engineers – whatsisname Oct 07 '23 at 16:47
  • 1
    ... for example, start with the title, saying "all devs over the world haven't learned to deal with ....". Or "If it's safe to say that Word is a no code program" - em, last time I used MS Word, it was quite programmable with VBA. And as a long time user of Word and LaTex, I can tell you this diagram is nonsense. – Doc Brown Oct 07 '23 at 16:47
  • @DocBrown why is simply saying "developers" the same with "all devs over the world"? Sure, logically it is, but why does it leave you an impression that I actually mean that? As for the second part, that's why I ask this question: to have an explanation – Ooker Oct 07 '23 at 16:52
  • @Ooker: well, tell us which group of devs you mean - and ideally give us a reference for your claim below "... It seems to me that this is not the case" - which kind of statistics can you reference for this claim, and which group of devs was interviewed for this statistics? If you cannot give a reference, you better don't make such claims in a question you want to survive on this site. – Doc Brown Oct 07 '23 at 16:55
  • @DocBrown I don't have a statistic admittedly, but is having a statistic the only way to have the justification to say "it seems to me"? Can a simple observation be enough? And the source for my observation is the number of upvotes for the frustration in the previous question (What is "low code"?), and the lack of comments acknowledging that this has been happening from the 90's. Anyway, as I write this I realize that it's not safe enough to say. Thanks for pushing me to answer your questions. – Ooker Oct 07 '23 at 17:07
  • So your observation is based on only one old question on this site, where ~5 people having a debate in the comments, and the specific comment you are referring to got 6 upvotes. I call that pretty few, not many. Definitely nothing from which I would jump to any conclusions. – Doc Brown Oct 07 '23 at 17:26
  • @DocBrown OK. But do you call that's a consensus? Plus that if you insist that I really shouldn't generalize (and how can I ask whether the generalization is correct without at first stating it?), then I can still always limit to only that group – Ooker Oct 07 '23 at 17:45
  • 1
    @Ooker, the only part of Winforms which is "low-code" is the visual form designer itself. That form designer does still produce a coded representation in a standard programming language. It relieves a programmer from having to describe the visual layout as a procedure for the assembly of its elements, or to swap back and forth between the programmatic representation and the visual representation. It's provably quicker and easier (even for programmers who could do it all programmatically). It doesn't relieve the programmer from programming overall, nor intended to pander to those who can't. – Steve Oct 07 '23 at 19:07
  • 1
    Actually, "low code" / "no code" approaches, while not necessarily feasible for general-purpose programming, are successfully used in some niche ways. Node-based systems (where you have nodes that "do stuff" and you wire them together) are used in game engines, where they allow level designers to rapidly prototype gameplay logic - reducing iteration times and speeding up development. Sometimes these are left in as is in the shipped product, sometimes the logic is rewritten by developers to make things more efficient at runtime (my guess is many (most?) devs see this as a chore). 1/2 – Filip Milovanović Oct 08 '23 at 08:57
  • 1
    Similar systems are used by artists in 3D modeling/animation and in video compositing. And then there's Microsoft Excel, which is essentially a programming language of sorts that ships with a next-to-no code environment (+ a scripting language if you need more control). 2/2 – Filip Milovanović Oct 08 '23 at 08:57
  • excel is not a good example of a thing that doesn't cause dev frustration :) – Ewan Oct 08 '23 at 10:24
  • Ok, I see you have improved this question a lot, and though this absurd Word-Latex-comparison is still in there (where did you get this diagram from?), I vote to reopen. Maybe when I gets reopened I will write an answer. – Doc Brown Oct 08 '23 at 12:30
  • @Ewan: being a successful low-code tool is not a contradiction to "being a tool which can sometimes cause dev-frustration" – Doc Brown Oct 08 '23 at 19:18
  • doesn't it sum the problem up though? excel can be great, but add enough macros and VBA and you are soon in a world of hurt. https://www.youtube.com/watch?v=J2qU7t6Jmfw – Ewan Oct 08 '23 at 20:36
  • @Ewan: yes - and if the question gets reopened, I would be happy to write an answer about a few real-life cases about Excel-solutions - some very successful, some with the potential to frustrate the developer who got the task to maintain them (the dev was me, and fortunately, I am very resistant against frustration). My point is: the OP is wrong in believing "low code solutions always seen negative by devs", but right when we change this statement "low code solutions can sometimes cause dev-frustration". – Doc Brown Oct 09 '23 at 21:46
  • ... side note: your link above points to a Doom port which uses Excel as a display engine, but the code window at the first second of the video clearly shows a C# program. So I think this is not an example of a low-code solution, quite the opposite. A better example is here: https://www.youtube.com/watch?v=iCeOEQVUWZ0 - a 3D engine completely made using Excel formulas, no VBA and no external program. – Doc Brown Oct 09 '23 at 22:10

3 Answers3

5

The problem is that "no code development" is rather like "no words lawyering" or "no numbers accounting".

Part of the problem is that the level at which the latest GUI fad - often devised by some new corporate non-entity rather than any established force in technology - becomes inferior to battle-tested programming languages is surprisingly low.

The more major part of the problem however is in how it suggests that the average business user is only held back by their lack of knowledge about some strange programming language.

The reality is that what holds most people back is their total lack of proficiency in any kind of developer competence. They don't just not code like developers. They don't think like developers and don't have the cognitive skills that developers have.

I think developers express frustration at low-code environments for much the same reason that lawyers would express frustration at pictographic law or accountancy would express frustration at dramatic/theatrical accountancy.

Specifically, that the suggestion law or accountancy can be done without the usual form of recording characteristic of their profession, is not only an absurd claim in its own right, but what is even more absurd is that it attempts to suggest that lawyers are only word-writers or accountants are only number-writers, and that the form this writing takes is their primary skill.

For obvious reasons, when businesses indulge this nonsense for a while and then finally hire real lawyers and accountants - often when some shock has already occured or blatant dysfunction has already set in and is now causing real harm to profits - they ultimately find that there is a lot of lost ground in designing and refining things properly, and there is a huge mess to rectify (such as that the company may now be bound to contracts that are riddled with holes and abnormal risks, or their books don't balance and originating documents are long-lost).

The same is true for developers. When businesses let non-developers work too long, and then finally hire real developers, there's an immediate massive mess to correct in the design and arrangement of things that defies everything real developers know.

That redesign often has to occur as a big-bang and be done by someone brand new to the business. Had real developers of appropriate skill and experience been involved from the outset, the design would otherwise have been done steadily over a period of time.

Steve
  • 8,715
  • Do you agree that this is a tradeoff between simplicity and complexity, which ultimately a tradeoff between short-term and long-term? And in projects with short deadlines and tight budgets, or in small businesses that are in the survival stage, then you need to prioritize short-term over long-term? I see that this is the same with using design pattern: start small, and refactor as you grow. Applying them too soon will make them become anti-patterns – Ooker Oct 08 '23 at 06:43
  • So my question is not about why the devs get frustrated with short-term people, but why they don't frame the situation as each situation has its own solution, or each tool serves its own need, and too focusing on long-term solutions will not be good for short-term situations? – Ooker Oct 08 '23 at 06:44
  • @Ooker, given that "simplicity" and "complexity" are generally regarded as diametrically opposite qualities, it follows that there must always be a trade off between those two. I'm not sure that each corresponds to short-term and long-term however. Short-termism in development is often characterised by undue complexity on the whole, not by over-simplification. (1/3) – Steve Oct 08 '23 at 07:51
  • 1
    I'm not sure devs get frustrated at single short-term solutions when an emergency demands it, but by management who are insufficiently strategic in thought and who (lacking the slightest understanding) think that everything can be solved with short-term solutions. This is roughly what developers mean by "technical debt" - it's basically work that should be done but hasn't yet been, and therefore leaves the existing situation over-complicated or error-prone. Eventually, the situation becomes unmanageably complex and highly incorrect and prone to dysfunction. (2/3) – Steve Oct 08 '23 at 07:56
  • Often what finally happens is that key development staff become overly-stressed by having to cope single-handedly with too much complexity, they throw down the gauntlet, and then the company faces a massive upsurge in development costs as it has to recruit multiple people who know nothing of all the baroque complexity and who have a massive backlog of corrective work to execute, all while the business is struggling from dysfunction or an inability to progress with new development. It's why developers often avoid "brownfields", and why rewrites are the most common prescription. (3/3) – Steve Oct 08 '23 at 08:04
  • devs get frustrated [...] by management [...] who (lacking the slightest understanding) think that everything can be solved with short-term solutions — what makes them think so? Surely they don't think they know better than devs? – Ooker Oct 08 '23 at 09:11
  • 1
    @Ooker: wishful thinking, the Dunning-Kruger effect and the Iceberg Secret. – Doc Brown Oct 08 '23 at 10:36
  • @Ooker, I think you'll be surprised. Many non-technical managers understand (by observable conventions in other businesses, and by encountering specific computer-related problems that no other general staff seem to be able to solve) that they require 'someone who handles the computers', but they often have little or no appreciation of what those staff actually do. Developers, for their part, are often poor communicators, and are often considerably younger than non-technical management and have lesser experience overall. More could be said, but it all contributes to badly managed activity. – Steve Oct 08 '23 at 10:44
  • @DocBrown, a big irony is that even Joel Spolsky says "whatever it is you in-house programmers do; it’s rather mysterious to me"! They do exactly what he says the "customer" can't do - they exist to analyse and keep an understanding of the business operation, and to be fully steeped in the circumstances and concerns of that business they're employed in, so as to be able to devise software that non-technical management could not conceive or describe for themselves (and to advise on the prudence or otherwise of changes which may upset the business and its computerisation). – Steve Oct 08 '23 at 11:49
3

Going to give you the obvious answer to your current question

If the concept of low code/no code program is nothing new, then why do developers talking about it still get frustrated?

Because the sales pitches for these products are designed to pitch to people who want a solution to "developers telling me things are hard" and the sellers don't care whether their product does what it promises.

It's like me selling chocolate cake to your child. I don't care if they get fat and they don't believe they will get fat. Your arguments about eating vegetables are ignored, but you are the one that's going to have to deal with them being fat.

The fact that chocolate cake has been sold for years and has some legitimate uses... mmmmmm cake... doesn't make it less frustrating

Ewan
  • 75,506
  • hmm apparently a whole industry for parenting books and courses doesn't help mitigate this frustration or make them accept that they will be ignored. However, I think what's difference in here is that the cake is more instinctual, and the arguments about eating vegetables are indeed ignored. However, the business users can still acknowledge the limitations of their tools, and some are indeed willing to learn if there is time and help. And if they don't listen to the advise then they still have to pay money for their choice – Ooker Oct 07 '23 at 17:41
  • You have lots of thoughts on this subject, but I think you are just wrong. The cake is specifically designed to appeal to the child by unscrupulous big sugar, who also manipulate the laws (market) to allow TV advertising (kick backs and conferences) during their favorite cartoons (strategy meetings). All the cool kids (big name companies who tasted cake once) are allowed cake, why are you a bad parent!? – Ewan Oct 07 '23 at 18:10
  • 3
    In short, this is a constant war for senior devs at most large software companies, you might win a couple of battles, but every year there will be a cake evaluation where you have to trot out the same arguments for vegetables. You might not have experienced it yourself, or you might like cake and think its not fattening, but that is the reason why you will see lots of posts expressing frustration. – Ewan Oct 07 '23 at 18:20
  • @Ewan, I guess what might swing the war would be if there was clarity about what developers do which other staff don't, and why code is suited to that. Although I'm in full agreement and as developers we share a tacit understanding, for non-developers the contrast between cake and vegetables is highly abstract. – Steve Oct 07 '23 at 19:17
  • But if the business owner ignores the advice then they still have to pay money for their choice, while if the kid ignores the advice then it's our responsibility, because we assume that the kid doesn't have the capacity to take the responsibility? – Ooker Oct 08 '23 at 04:45
  • Do you agree that this is a tradeoff between simplicity and complexity, which ultimately a tradeoff between short-term and long-term? I consider myself a long-term person, but I think ultimately if we don't support short-term sometimes, we won't be able to acknowledge and appreciate the long-term – Ooker Oct 08 '23 at 06:28
  • 1
    you are missing the point The scenario of small business uses wordpress + shopify rather than hiring a dev team is NOT what causes frustration. It's organically grown massive infrastructure should be replaced with websphere/erp of the month so that "managers can make their own changes" – Ewan Oct 08 '23 at 10:10
  • 1
    also you are massively over simplifying "the owner pays not you" 1. usually its some manager making the choice, not the owner. They can totally get a bonus/promotion out of a new project before it starts to break. 2. the owner doesn't pay, the company does, which means the employees do. In terms of devs, a switch to an erp can mean either you are now an erp X dev or you change company. So yes there is a personal cost. 3. devs get attached to their work. You want to throw that all in the bin? thats an emotional cost – Ewan Oct 08 '23 at 10:21
2

They still not accept that this is really a need and have to deal with it. Is this correct?

You're missing the point. It does not matter if it is a need or not.

I would love a unicorn that poops gold, but my need doesn't make the product any more feasible.

If the concept of low code/no code program is nothing new, then why do developers talking about it still get frustrated?

Because the no-code revolution happens every four years or so, and fails for the same exact reasons every time.

  1. Someone gets the bright idea to let non-programmers configure the logic for the system.
  2. A basic system is put together to handle a domain specific problem, which works okay!
  3. Users slowly want to do more with the system (after all, if anyone can make the software easily, it isn't valuable).
  4. The system becomes more and more customizable, until eventually people are writing code again.

(Older) developers are frustrated because they see people repeatedly making the same mistakes.

Telastyn
  • 109,398
  • gold pooping unicorn you say!!!??? shut up and take my money!! – Ewan Oct 07 '23 at 18:24
  • my need doesn't make the product any more feasible — hmm, but in projects with short deadlines and tight budgets, or in small businesses that are in the survival stage, then one one hand (1) you don't have programming skills and time to learn the skills and time to develop, while on the other hand (2) you need to make the product as quick as possible. So isn't that suffice to use the low code products? I see that this is the same with using design pattern: start small, and refactor as you grow. Applying them too soon will make them become anti-patterns – Ooker Oct 08 '23 at 04:37
  • @Ooker, "in projects with short deadlines and tight budgets" - only a fool commissions development work with short deadlines and tight budgets. The reality is that these are often highly artificial constraints imposed at the whim of higher management, and the intention might even to be to wage war on the development staff and sweat them to within an inch of their lives. Obviously, it doesn't take imagination to understand why developers might find this frustrating or might resist it. – Steve Oct 08 '23 at 08:20
  • @Steve only a fool commissions development work with short deadlines and tight budgets — can you elaborate that? I thought that overcoming the survival stage is a legitimate reason? I understand the part about "often highly artificial constraints", but that makes your first sentence applies to most people, not all – Ooker Oct 08 '23 at 09:03
  • @Ooker, not all companies have to survive - they can fail because of insufficient profitability and a consequent inability to do things successfully that more profitable companies already can (like software development, done on proper timescales and budgets). But I don't accept that the general tension is between corporate survival and competent development. I more often witness, or hear of, on-the-cheap development disasters that consume profits but don't fold the company. I've never once heard of a company failing because their software and systems were built too well. – Steve Oct 08 '23 at 10:03
  • @Ooker - if a company doesn’t have programming skills, then it is foolish to make programming part of their critical path. And if it isn’t part of their critical path, then they can outsource the work. Hell, even when it is part of their critical path, founders will often outsource the programming work for their initial prototype. – Telastyn Oct 08 '23 at 15:17