[isquaredr]

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]

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

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

[chasd00]

I see this almost every day. A low-code/no-code platform configuration change rolls through the testing lifecycle of straight up code. All the advantages of a low-code/no-code platform fly out the window because the time from feature request to prod is the same as if it were developed from code.

[isquaredr]

Exactly. A configuration change is the same as a code change: it should be tested and reviewed before it goes live

[suzzer99]

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.