3 ms·
> Counterexample: MS Access apps are often a maintenance nightmare. They end up being a maintenance nightmare because they are undocumented and flooded with po
by Closi 6y ago
> Counterexample: MS Access apps are often a maintenance nightmare.
They end up being a maintenance nightmare because they are undocumented and flooded with poorly written VBA, which is hardly low-code. A non-VBA Access Database is trivial to maintain, but VBA is a full programming language, so if that's heavily used it's really maintaining a VB6 Winforms application, which isn't what we would now typically call 'low code' in terms of this article.
(As an aside, I would actually personally argue that a completely undocumented MS Access database is actually slightly easier to maintain than an equally undocumented web application anyway. The reason these tend to be a 'maintenance nightmare' is that they are typically made in Shadow-IT rather than the technology itself which is very simple).
- q-big 6y ago> The reason these tend to be a 'maintenance nightmare' is that they are typically made in Shadow-IT Low-code and no-code solutions are often created by shadow-IT.
- dragonwriter 6y ago> Low-code and no-code solutions are often created by shadow-IT. Heck, while it is phrased differently, enabling Shadow IT is an explicit selling point of low- and especially “no”-[0] code tools. Of course, Shadow IT isn’t the tools fault, it is the organization that segregates IT into a separate heirarchy often the whole way up until the C-Suite. If IT was a function integrated within each business unit empowering it, rather than external silo alternately constraining arbitrarily and granting favors, Shadow IT woudn’t be a thing. Shadow IT is a symptom of a broken relationship between IT and the broader organization. [0] but often not really “no”, just as Excel isn’t.
- Closi 6y ago> Low-code and no-code solutions are often created by shadow-IT. In that case the issue is Shadow IT then, not low-code tools.