Supply Chain/Software Dualities

1. Responsive
2. Efficient
3. Risk-hedging
4. Agile

Scratching out some incomplete thoughts here, but I think there's a bit of a duality between supply chain strategies¹ and tech stack strategies, and that tech businesses can get something useful out of this by comparing where their product would sit in the supply chain view with what their current stack is.

Warning: considerable vibe analysis ahead.

There are four basic supply chain strategies: responsive, efficient, risk-hedging, and agile.

1. Responsive

Responsive strategies are used for innovative² products with reliable raw material suppliers, and revolves around handling the whims of the customers. Being able to adjust your production capacity and product elements is crucial here. This could be compared with the usage of low-cycle time languages (scripting in general, but especially Lisp, Python, Perl; cf Viaweb) and microservices³.

2. Efficient

Efficiency is for functional⁴ products, and focuses on cutting supply chain costs to the bone. This is probably corpo-style commodity software and CLI tools, using old and boring tech⁵ and trying to leverage economies of scale⁶.

3. Risk-hedging

Risk-hedging is used for functional products with uncertain raw material supply⁷. The stack here is gonna be similar to efficient⁸, but with extra attention paid to backups and redundancy (sysadmins/devops running the pipelines like the Navy, backups in multiple regions, multiple datacenters, focus on error handling and testing). Languages with strong typing systems like Haskell and Lean⁹ would be useful here, but they seem underused.

4. Agile

Agile supply chains are NOT to be confused with Agile software development or Agile business; they are the toughest supply chain to operate and something you don't want to have to do for long, requiring both hedging risk and handling changing customer demand at the same time¹⁰. Software-wise, I'd say this is a hedged-serverless kinda setup (renting platforms, but using multiple providers and regions to lower the likelihood of an outage), using low-cycle time languages and simple architecture.

Footnotes:

Fisher/Lee

Short lifecycle, unpredictable demand, etc.

Maybe, under the condition that they're architected correctly and allow you to add functionality on the fly.

⁴

Long lifecycle, predictable demand, usually lower-margin. Think white-label.

⁵

E.g., Java

⁶

Basic-bitch VMs on-site or in a co-lo center

⁷

E.g., masks during coof.

⁸

Since reliability & cheap scalability go hand-in-hand.

⁹

Where you could model the business logic directly in the type system, moving expected points of failure largely to the parsing stage.

¹⁰

If you think this sounds self-contradictory, you aren't wrong. That's why it's hard.