4 ms·
Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where secur
by jmfldn 5y ago
Not really. I've granted that there is a middle ground, it's just that you have to draw the line at systems that actually need proper engineering eg where security or performance has serious real world consequences. It's a question of where you draw the line. Use this for appropriate use cases but beware of abusing this stuff.
- ethbr0 5y agoEvery system should have proper engineering. Most systems need proper engineering. Few systems actually have proper engineering. I've seen stuff that has core-business, real world consequences, to the tune of affecting company's quarterly results, run off an Excel spreadsheet. And I don't think this is abnormal in large business land. So the line shouldn't be drawn at "Is this system too important to trust to low-code?" It should be drawn at "Is this system important to us?" + "If so, are we willing and able to assign development resources at it, to do it properly?" + "If not, what do we need from a low-code interim solution to keep it safe and maintainable?" If we can't fix it properly, then it's counterproductive to enumerate the ways the fix we can apply is less than perfect.
- jmfldn 5y agoYou said it really, we're already drowning in dodgy systems code or no code. I'm just concerned to not make the problem worse with an even more powerful way to cause a disaster. Think the excel spreadsheet powering the quarterly results on steroids. I don't deny there's a place for no code, I'm just sceptical about intended uses. Not least because a lot of what is written are puff pieces by someone with an agenda. This is big business.