> The best software around is the one that's opinionated.

This. And it isn't going to change.

The post avoids trying to answer "Why are opinionated tools popular and effective?"

The answer is that a standardized process that they encourage is often more efficient than whatever bullshit {random company} came up with in-house.

Malleable software needs to produce two equivalently good outcomes to beat opinionated:

1. Improve the underlying process at the customer's business (in terms of effectiveness)

2. Avoid a customization maintenance burden

The seductiveness of "just for you" bespoke solutions is they avoid (1) by telling the customer what they want to hear: you're so brilliant, your process is actually better, our product is a custom fit for your exact process, etc. That's bullshit -- a lot of customer processes are half-baked dumpster fires, and their companies would be better served by following standards.

To (2), I am incredibly skeptical on the long-term tech debt that malleable solutions will impose. What happens when there's a bug in the version only you use? Is that going to be the vendor's priority? Oh, you're supposed to fix it yourself? Congrats... we've just added a requirement that these tools are capable of making random mid-level in-house practitioners as competent as focused dev teams. That's a tall order.

Exhibit A that I'd want a follow-up post to address: SAP.

The above are the reason they realized they were trending in the wrong direction and have been dragging their customer base back to Clean Core.

Walk me through how malleable software would work better for SAP as a product, and I'll begin to believe...

▲

ch4s3 6 days ago | parent | next [-]

Highly customizable configuration causes all kinds of problems in healthcare, and EHR customizations have actually killed people.

▲

RUnconcerned 6 days ago | parent [-]

In my first job I had to work with healthcare software and it horrified me. There is a standard for interop, HL7, but every system implements HL7 in its own special way so there are "integration engines" to massage the data so that they all conform to the same standard.

It's a gigantic grift.

▲

ch4s3 6 days ago | parent [-]

The history of HL7 is kind of nuts. It was originally developed for copper wire communication in 1979. Formalization was ongoing until maybe the early 1990s and lots of proprietary usage arose, because back in the 1990s none of these systems really inter-operated and everything eventually ended up on paper. It wasn't until after the ACA that a lot of interoperability pushes really got going at scale. Before that you had a few Health Information Exchanges at state levels so there was usually a local standard if there was an HIE. HL7 FHIR is much more standardized now.

I wouldn't call any of it a grift. It's just old tech built for a fragmented archipelago of systems that didn't communicate. Also you can write a pretty good HL7v2 parser in an afternoon, I've written maybe 5 of them.

▲

ethbr1 5 days ago | parent [-]

The koan that unlocked why healthcare technology is the way it is for me:

I was working on automating health insurance claims processing on a mainframe system.

In their key interface, a key form had 8 blanks for ICD codes. If more than 8 codes were needed, a child claim was created and linked to the parent claim.

This was a long project, so I was staring at this interface for months, as linked child claims made automation more complex than it needed to be. (E.g. if a parent claim had aged, been archived, and needed to be reloaded to active overnight before processing the child claim)

Finally, I started asking around. "This is a computer system. Why are there a finite number of fields for something that might need more?"

Nobody knew. Project continued. I continued asking different people.

Finally, I asked a guy who had been working in the industry since the 1960s...

"Oh, because that's how many fields there were on the paper version of the form that preceded the mainframe app."

Which seems insane, until you think it through. There were innumerable downstream processes of that paper form.

Changing the number of fields on the digital version would have cascaded that change downstream to all those processes. In the interest of rapid implementation, the optimal approach was to preserve everything about the form.

And then nobody had a reason to go to the bother to change it for the next 50 years. (And that was a process within a single company!)

▲

1718627440 5 days ago | parent [-]

But you can split these claims into child claims upon printing. That's the thing with good software, the user model and the internal implementation are completely orthogonal. I think a good example of this is postfix.

	▲	ch4s3 5 days ago \| parent [-]
		> But you can split these claims into child claims upon printing Maybe, if business rules and the law allow a thing like that. If insurance won't pay claims like that then you can't do it.

▲

BinaryIgor 6 days ago | parent | prev [-]

100%; customization maintenance burden is underrated - it simply costs a lot of time and energy to customize things; often there are better uses of this time, especially in the business context