At my workplace, one of our common sayings is “when you’re doing badly, users complain about bugs; when you’re doing well, they’re complaining about missing fea

At my workplace, one of our common sayings is “when you’re doing badly, users complain about bugs; when you’re doing well, they’re complaining about missing features.” From 1998 to 2004 I worked as the IT manager at a plastics manufacturer whose entire system was backed by SQL Server, and fronted by MS Access databases that people ran locally for the forms and reports (no data was stored in them) or Excel (same thing). This is low-code in a nutshell and it worked well back then: it was CRUD before websites were CRUD. And we were constantly developing it and building out more complex scenarios for industrial production control and accounting and reporting. Why? Because it worked, it allowed users to conceive of the next thing they could use, which inevitably led out of low-code scenarios. At one point we seriously investigated hiring trying to implement bin-packing algorithms in VBA so that warehouse pickers had better direction in order assembly. Low code systems either don’t work, or they do and create demand for “high code” solutions.