The Blind Spots Low-Code Development That Will Create Technical Debt

I reckon low code mandating a CI pipeline and solve the process issues mentioned

I was expecting things like..

- creating a huge number of poorly named, ill defined concepts, so your user can’t get their head around it and eventually neither can you

- expanding your product surface area too wide, with lots of shallow features and WIP and greyed out buttons

- not providing a strong nav concept to take a lot of the heavy lifting away from the screen

- using standard components in non standard ways, like clicking an image which then does a large change to your data with no warning and no undo

- building features as a set of functions rather than a full workflow that delivers a concrete piece of value

- anything to do with performance, like loading data too often, not batching the load, fetching too widely rather than only what is necessary

- not indexing their schema around common load patterns

- using too much nosql resulting migration headaches when it needs to change

- showing the user that a complicated thing happened, but not showing the working, which increases the number of people that think it’s broken and blow up support with dev level investigation tasks, only to find again and adding that there’s no technical issue

- building a new feature, but not taking it to it’s logical conclusion before release, meaning that even though it’s working it violates user expectations due to ‘obvious’ incompleteness at the user level, creating urgent unplanned work to fix

- rebuilding every function every time the application of it is slightly different, rather than creating modular functions that do one thing well, and compose together in ways that are easy to predict and understand

Overall I’d be happy if low code did take away more of the very basic problems, it would be great to raise the conversation of that development is up to the next level

While true, all these things are process/methodology issues; they will happen with 'yes-code' development too but possibly show up later if the process of creating is slower than the no/low code software is. I have seen all the things mentioned here in code and in low code environments. Not sure if there is enough data to show it is more in one or the other (yet).

Looks like the author has never developed any low code software at enterprise scale. Depending of the type of low code builder used, solutions to all of these problems exist in one form or other. We have backups, source control, multiple test environments and process documentation.

The title needs an "of"