Perfectionism, Exhaustive Models, and SysML

Prediction

Another prediction: if code-first hardware engineering is the future (and I think it is), then the language(s) of choice will be strongly typed but highly flexible. Composable and not exhaustive. Probably not SysML.

To be clear, by “code-first hardware engineering” I mean: specs + interfaces + tests as versioned text/code, with diagrams and CAD as compiled artefacts for review.

I might be wrong on this and so I gently provoke in the hope of gathering thoughts from all camps. My current thinking…

The perfectionism trap (seen up close)

At Palantir, we often saw enterprises hamstrung by their dogged pursuit of digital transformation governed by a “perfect” and “complete” industry data model. Electricity utilities have the Common Information Model, for example. Over-indexation on one of these was a pretty good heuristic for lack of progress.

The real world is really messy and therefore hard to shoehorn into an exhaustively specified data model, particularly on day 1. Such a digital strategy could be summed up in one word—perfectionism. “Done” is simply always better than perfect.

It’s hard for me to look at SysML and see something different.

For the SysML faithful: I’m not asserting SysML is useless. I’m claiming “exhaustive model first” is a great way to ship nothing.

Software’s move: standardize communication, evolve locally

It’s also hard not to look at software engineering and see that it already addresses these problems. That is, with APIs plus local, versioned contracts (driven by consumers), and strongly typed but otherwise loosely opinionated languages. Software touches everything, and some zealous engineers could have decided to define WorldML—but they didn’t.

Software engineers standardized how services talk, and let the data models evolve locally.

The trade-off triangle

Speed, global interoperability, single source of truth. In hardware development today, pick two.