3 ms·

I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough sof

by ethbr0 5y ago

I think this argument against low-code is based on a misunderstanding of how most companies are staffed. Truth: in normal companies, there are never enough software developers to build everything that needs building Consequence: tons of processes and people get by as best they can, their never-prioritized project languishing in IT's backlog, often manually processing things that could be trivially automated Consequently this isn't about a choice between (traditional software development with all the trimming) vs (low-code). It's a choice between (nothing/Excel) vs (low-code). And given that reality, I'd argue that moving to a well-integrated, gutter-guards-in-place, documented low-code system is a HUGE win for the company as a whole. And sure, you can say "It isn't this or that" (that should be there in well designed software). But it's also a helluva lot better than what they were running their part of the company on before.

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 ago
  Every 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 ago
    You 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.

by ethbr0 5y ago

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 ago
Every 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 ago
  You 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.