4 ms·

I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards. Proponents often cite ho

by bilalq 5y ago

I've seen "low code" and "no code" solutions running at huge enterprises and it always inevitably ends up resembling a house of cards. Proponents often cite how much quicker they can ship things and how it lets users define and automate their own workflows without waiting for engineers. The reality is that these time savings come by cutting corners from the development cycle. Because you're not doing "code", the code review step gets skipped. The authoring of automated test suites get skipped. The authoring of performance regression testing gets skipped. There's no waiting for things to bake in non-prod environments because people are changing settings directly on prod. No ones doing phased deployments with automated rollbacks here in these low code and no code environments. No design reviews mean you get solutions that are the absolute worst hacks.. Why go through the work of making "priority" a first class property on your ticket type when you can just string scan for "high" | "medium" | "low" on case titles when doing assignments? Engineering teams could also move fast if they just threw maintainability to the wind. There's a reason they don't. If you do things the right way in these low/no code environments, the complexity is even worse, because the features are so half-baked that you can't setup proper safeguards without doing crazy amounts of escape-hatches.

hk1337 5y ago
Yeah, the biggest flaw with the low/no code solutions is that end users want, and get, access to how the workflow works and/or it ends up this giant hero workflow handling every single possible scenario. Best to keep the task simple, pick up the response, do some sort of identification, pass on it to where it should go. That's it. Let the next destination handle more stuff.
adrianN 5y ago
To be fair, many "normal" software solutions also resemble a house of cards.
amitport 5y ago
In my experience there is one situation where no code shines, namely, in enterprise support and deployment assisting software. I've worked at a company that sold products to enterprise. There you have programmers writing complex features but you also have complex per-client requirements. Basically, software engineers maintained a nocode product that support / solution engineers use (not so much end users). So yes, there is a real programmer in the loop, but surprisingly, things also often get done without involving this programmer.
pydry 5y ago
From a coding perspective taking over these houses of cards are my favorite kind of project. If the spreadsheet (or whatever) is used to build a system that people start relying upon then the proof of concept is already done, the underlying domain model is fleshed out and the task prioritization is obvious. Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me. One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements. It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once. Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny. I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.
jmfldn 5y ago
So many good points here, best summary of the problem of no code I've read yet. Whether you write lots of code or no code, all the principles you mentioned remain i.e. testing, deployment complexity, maintainability, rollback, release strategies etc. If you tried to do all that in a no code environment it would be horrendous. If you skip it, as a non engineer might, you're courting catastrophe. No code will often make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things. I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.
- ethbr0 5y ago
  I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough software developers to build everything that needs building Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated Consequently this isn't about a choice between (traditional software development with all the trimming) vs (low-code). It's a choice between (nothing/Excel) vs (low-code). And given that reality, I'd argue that moving to a well-integrated, gutter-guards-in-place, documented low-code system is a HUGE win for the company as a whole. And sure, you can say "It isn't this or that" (that should be there in well designed software). But it's also a helluva lot better than what they were running their part of the company on before.
  - jmfldn 5y ago
    Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.
forinti 5y ago
It turns into a house of cards even when professionals use it. Oracle Apex is a great tool for simple CRUD and reporting apps. But as systems grow big, you start to have complex flows, integrations with other tools (for file conversion, image manipulations, etc). and it becomes a big mess.
beanjuiceII 5y ago
I been at one very large enterprise for the last 15 years; the amount of low/no code apps I've been through is...well you know when neo is in the matrix, he is shown the previous matrix versions by the architect? its that feeling, but in this case there is no version of reality where there is a win. The biggest problem I see even if this were to work, is that you don't really want non-developers using these tools. Who's to blame when the low/no code user makes a booboo ? These people typically don't want this burden, so I've always seen it pushed back to a developer...and the requests are usually beyond the scope of the low/no code tool such that it eventually always becomes a worse burden for devs than code
- ethbr0 5y ago
  That's an organizational problem. If you use this stuff right -- citizen-developers should be developing their own work. Or at most, the work of their immediate group / team. Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer! And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer. The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise. And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in. And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.
deleted 5y ago
[deleted]

by bilalq 5y ago

hk1337 5y ago

Yeah, the biggest flaw with the low/no code solutions is that end users want, and get, access to how the workflow works and/or it ends up this giant hero workflow handling every single possible scenario. Best to keep the task simple, pick up the response, do some sort of identification, pass on it to where it should go. That's it. Let the next destination handle more stuff.

adrianN 5y ago

To be fair, many "normal" software solutions also resemble a house of cards.

amitport 5y ago

In my experience there is one situation where no code shines, namely, in enterprise support and deployment assisting software. I've worked at a company that sold products to enterprise. There you have programmers writing complex features but you also have complex per-client requirements. Basically, software engineers maintained a nocode product that support / solution engineers use (not so much end users). So yes, there is a real programmer in the loop, but surprisingly, things also often get done without involving this programmer.

pydry 5y ago

From a coding perspective taking over these houses of cards are my favorite kind of project. If the spreadsheet (or whatever) is used to build a system that people start relying upon then the proof of concept is already done, the underlying domain model is fleshed out and the task prioritization is obvious. Greenfield projects where requirements are vague, priorities are vague, the underlying domain model is vague and the need for the project to exist at all is dubious bug the shit out of me. One of the most successful companies I ever worked at kickstarted many new business processes with a few guys importing, munging and exporting data from a spreadsheet and sending emails. It was manual and often repetitive. But, all the iteration happened in the background until they nailed down what was needed and then came to me with a set of crystal clear, validated requirements. It was quite a contrast to all of those other companies where I was given a feature to write that took a week to knock out because a powerful customer said it would be cool to have. Inevitably, even they only played with it for 5 minutes before never using it again and nobody else even touched it once. Or the other companies that went to the other extreme and treated random excel spreadsheets as fully fledged production systems that would trigger catastrophe if you looked at them funny. I can't help but feel that there's a sweet spot somewhere here that most people (& low code companies) miss.

jmfldn 5y ago

So many good points here, best summary of the problem of no code I've read yet. Whether you write lots of code or no code, all the principles you mentioned remain i.e. testing, deployment complexity, maintainability, rollback, release strategies etc. If you tried to do all that in a no code environment it would be horrendous. If you skip it, as a non engineer might, you're courting catastrophe. No code will often make little sense for a lot of "proper" software if you want something maintainable, extensible, safe, performant (add other engineering principles here). It's probably very useful for non devs to build tools and cobble things together, in a similar fashion to how Excel can replace certain programming tasks. Just don't build your whole system from these things. I think it's important that people respect the limits of these, no doubt useful, tools. We should also respect us software engineers and understand why we do things in the way we do. It might seem too complex but you might be suprised how complex, potentially unsafe and limiting the alternatives can be.

ethbr0 5y ago
I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough software developers to build everything that needs building Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated Consequently this isn't about a choice between (traditional software development with all the trimming) vs (low-code). It's a choice between (nothing/Excel) vs (low-code). And given that reality, I'd argue that moving to a well-integrated, gutter-guards-in-place, documented low-code system is a HUGE win for the company as a whole. And sure, you can say "It isn't this or that" (that should be there in well designed software). But it's also a helluva lot better than what they were running their part of the company on before.
- jmfldn 5y ago
  Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.

forinti 5y ago

It turns into a house of cards even when professionals use it. Oracle Apex is a great tool for simple CRUD and reporting apps. But as systems grow big, you start to have complex flows, integrations with other tools (for file conversion, image manipulations, etc). and it becomes a big mess.

beanjuiceII 5y ago

I been at one very large enterprise for the last 15 years; the amount of low/no code apps I've been through is...well you know when neo is in the matrix, he is shown the previous matrix versions by the architect? its that feeling, but in this case there is no version of reality where there is a win. The biggest problem I see even if this were to work, is that you don't really want non-developers using these tools. Who's to blame when the low/no code user makes a booboo ? These people typically don't want this burden, so I've always seen it pushed back to a developer...and the requests are usually beyond the scope of the low/no code tool such that it eventually always becomes a worse burden for devs than code

ethbr0 5y ago
That's an organizational problem. If you use this stuff right -- citizen-developers should be developing their own work. Or at most, the work of their immediate group / team. Who's to blame when the low/no code makes a booboo? The citizen-developer. And who fixes it? The citizen-developer. And who can fix it, because they already know how to do the work manually? The citizen-developer! And, most critically, who is then incentivized to correct their own low/no code so it doesn't break again? The citizen developer. The central organizational anti-pattern around this is "users build + IT maintains." Just... don't do that, or allow it. Make it clear when they get this capability, that they're responsible for fixing issues, and that IT will only advise. And have that talk with their VP up front, so that when he or she tries to escalate because they have an "Oh @&$+" outage, you let them suffer long enough to hurt, before pitching in. And then after the incident is over, you return with "So one way we prevent this on the other side of the house is {cvs/testing/environments/etc}..." And there's a chance they listen to you, because it's a solution to a problem they just had.

deleted 5y ago

[deleted]