Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". Th

Translating requirements into code - is about language and tools as you have to learn the language, as you noted "few people wanted to learn to use those". Third paragraph is saying about loads of amateur spaghetti code, so turns out it was not that hard. So third paragraph contradicts things written in the second. Low-code tools promise to address "problem of the language" so it is easy to translate business knowledge into the tool. Keep in mind low code tool should ideally be used by domain expert, so another promise is that you don't need business analysts and developers so problems with communication or misunderstanding is removed. Going back to second paragraph: Good part that was noted, there were loads of spaghetti apps in Access and File maker, let alone all those Excel sheets that are still everywhere. There was no one to maintain them and low code tools don't provide enough means for maintaining complex systems. Running and maintaining computer systems is 80% of cost for software, maybe translating it into code is hard, but debugging, fixing, adjusting, keeping operational knowledge is much more expensive. Silly Excel file that architect Jane was using for 5 years and then she quits, you hire John while you can do knowledge transfer - it is still hit or miss just as noted in second paragraph John will be more comfortable doing his own excel from scratch than learning what Jane did. Even with developers it is the way that everyone wants to do "greenfield" and understanding what other people wrote before in some unfamiliar system is hard work. Low code even makes it harder to understand existing stuff with their GUIs. Whole DevOps tooling/movement grew just because of that fact, none of the "low-code" tools is addressing it.