4 ms·

> They had committed to building all of this [a previous modernization effort] on Microsoft PowerApps, a “no-code” tool meant for building simple web apps > Wh

> They had committed to building all of this [a previous modernization effort] on Microsoft PowerApps, a “no-code” tool meant for building simple web apps > When we met with the developers in Macon, Georgia, OPM's engineering hub, they told us the PowerApps experience was so unfriendly that even they were afraid to make changes. Unless they’ve been specifically trained with PowerApps, most software developers would find it extremely unintuitive to build with, making it hard to apply classic coding skills or iterate quickly. How much longer is it going to take project managers to realize that no-code tools are inappropriate for large, complex codebases?

calvinmorrison 10mo ago
> How much longer is it going to take project managers to realize that no-code tools are inappropriate for large, complex codebases? Really depends. It can work great, I see some really good No/Low code tools in ERP systems. Things like alerts, workflows, custom fields, actions, etc are... you would be surprised the ingenuity of people, but also - yes there are limits. An ERP is practically an opinionated entire operating system with its own data, conventions, rules, ACLs, etc...
- shermantanktop 10mo ago
  Ingenuity is the word. Some of the things I’ve seen “nontechnical” people do in Excel are boggling. But I wouldn’t build the foundation of an ERP system on stuff like that. I think you’re describing a scripting interface, rather than the core?
  - calvinmorrison 10mo ago
    not scripting per se - yes that is part of it typically, with windows based ERPs, you get scripting for close to free if you can 'drop into' other stuff, like VB, or if your ERP leverages the COM interfaces, has an ODBC or even a straight SQL backend, yes there are many approaches. It's really - how does the scripting interact with the system What i am talking about is more simple 1. user defined actions. 2. common triggers (object X Save, object Y delete) 2. user defined fields on core data tables 3. user defined tables You can go very far with that, and a drop into a VB script, or run a prebuilt action (IE some verb on the object, like "print this document" on Save)
andy99 10mo ago
It’s enterprise software so product managers don’t decide anything. They’re just an automaton charged with implementing whatever complied with the RFP terms that were written by the vendor to wire the procurement. It’s basically a problem with central planning, there’s no easy fix but giving people agency is a big part of it instead of ramming some enterprise crap that was designed to sell to “leaders” or committees down their throats.
TheJoeMan 10mo ago
Many small businesses (and small teams inside large orgs) do not have “servers” in the sense that an employee can push code to it. It’s just Windows Server and handles email, file share, ERP, etc. I think those in the tech industry may not appreciate the ease of having a platform you can “program” jobs in, and it’s included in M365, despite the very-large warts.
- throw10920 10mo ago
  I specifically said "large, complex codebases", so I'm not sure how your comment is relevant. If the project you're implementing is Big (which the federal employee retirement system qualifies for by any sane metric), then the infra you described is inappropriate. If the project isn't Big, then my comment wasn't addressing it.
  - TheJoeMan 10mo ago
    I apologize, I misread your comment as “complex databases”. PowerApps could make simple queries across large databases, but you’re right that large software projects should not be in a no-code tool.

calvinmorrison 10mo ago

> How much longer is it going to take project managers to realize that no-code tools are inappropriate for large, complex codebases? Really depends. It can work great, I see some really good No/Low code tools in ERP systems. Things like alerts, workflows, custom fields, actions, etc are... you would be surprised the ingenuity of people, but also - yes there are limits. An ERP is practically an opinionated entire operating system with its own data, conventions, rules, ACLs, etc...

shermantanktop 10mo ago
Ingenuity is the word. Some of the things I’ve seen “nontechnical” people do in Excel are boggling. But I wouldn’t build the foundation of an ERP system on stuff like that. I think you’re describing a scripting interface, rather than the core?
- calvinmorrison 10mo ago
  not scripting per se - yes that is part of it typically, with windows based ERPs, you get scripting for close to free if you can 'drop into' other stuff, like VB, or if your ERP leverages the COM interfaces, has an ODBC or even a straight SQL backend, yes there are many approaches. It's really - how does the scripting interact with the system What i am talking about is more simple 1. user defined actions. 2. common triggers (object X Save, object Y delete) 2. user defined fields on core data tables 3. user defined tables You can go very far with that, and a drop into a VB script, or run a prebuilt action (IE some verb on the object, like "print this document" on Save)

andy99 10mo ago

It’s enterprise software so product managers don’t decide anything. They’re just an automaton charged with implementing whatever complied with the RFP terms that were written by the vendor to wire the procurement. It’s basically a problem with central planning, there’s no easy fix but giving people agency is a big part of it instead of ramming some enterprise crap that was designed to sell to “leaders” or committees down their throats.

TheJoeMan 10mo ago

Many small businesses (and small teams inside large orgs) do not have “servers” in the sense that an employee can push code to it. It’s just Windows Server and handles email, file share, ERP, etc. I think those in the tech industry may not appreciate the ease of having a platform you can “program” jobs in, and it’s included in M365, despite the very-large warts.

throw10920 10mo ago
I specifically said "large, complex codebases", so I'm not sure how your comment is relevant. If the project you're implementing is Big (which the federal employee retirement system qualifies for by any sane metric), then the infra you described is inappropriate. If the project isn't Big, then my comment wasn't addressing it.
- TheJoeMan 10mo ago
  I apologize, I misread your comment as “complex databases”. PowerApps could make simple queries across large databases, but you’re right that large software projects should not be in a no-code tool.