I think I finally get ‘testing in production’ conceptually. TIP is to software what simulation is to hardware. In hardware, TIP is default, since even in a lab you can’t turn off the real-world test environment of friction, gravity etc. Unless you build a software simulation.
Conversation
In software, you live on a map by default, unless you take explicit steps to turn it into the territory. In hardware, you live in the territory by default unless you take steps to turn it into a map (model).
2
6
27
While there are “physics” elements to software at scale (think 1000s of disks making r/w unreliable operations, or latency being an issue, or enough high-load test activity that the statistics start to matter), in general the only way to be “wrong” is “internal” like math.
1
1
12
This seems to be a key debate (to first order KU=math, UU=physics). The counter argument is that you want to find highest-risk and most difficult failure modes ASAP, regardless of whether they are KUs or UUs. So argument for TIP is basically fail fast, for worst case fails.
Quote Tweet
Replying to @vgr
TIP finds unknown unknowns, but you might as well fix the known unknowns first.
1
1
9
Replying to
I never did get comfy with traditional TDD. This may be because as a mech engineer by training it’s an unnecessary/artificial distinction. If you’re doing hardware, testing is sort of inescapably built-in. And you know exactly what you’re throwing away when you build a sim.
1
1
7
And in mechanical things, there’s no such thing as just flipping a switch and “deploying” a simulation model as the real thing and being surprised. There minimum unavoidable fabrication that immediately adds everything you threw away right back in. There’s nowhere to hide.
2
1
5
So I can see how that enforced discipline could be an attraction to those who have the option of pretending to believe in perfect models.
1
1
6
One of the stark things you realize early on in hardware is that if there’s *any* significant uncertainty, starting with math/simulation (in a CAD tool for eg) will take you down a radically different dev path than starting with physical prototypes, and the latter is superior.
2
2
7
Only in extremely mature applications like airliner design since the 777, can you start with modeling and simulation. Otherwise you start with the most uncertain, high risk bit and get it to hardware iteration as quickly as you can.
1
2
11
Cost is a factor too. Casual inspection might suggest software simulations cheaper. This isn’t actually generally true unless the thing is extremely high capex and one-shot. Often hardware iterations are cheaper. Atoms are sometimes cheaper than bits.
3
1
6
If you’re building a new kind of billion dollar factory, yeah... spend a million developing a useful simulation before breaking ground on it. But if you’re figuring the perfect chocolate-chip cookie, you’re better off making batches than writing a cookie-baking-physics simulation
2
1
12
This TIP trend is interesting because I think it’s the start of hardware eating software philosophically. Something big seems to be underway in all of engineering due to colliding trends of late-stage software eating world and early stage climate-tech eating world.
1
1
10
Call it 4th industrial Revolution or whatever, but a big game is afoot again in tech for the first time in like 30 years. TIP is part of it.
Quote Tweet
Not crazy about the term ‘4th industrial revolution’ but getting increasingly intrigued by the class of things it points to, which now includes mRNA vaccines. Kinda groping about for the essence now. The Hunting of the Meme is on.
Show this thread
1
1
11
Nearly settled on The Fattening as my meme for this whole thing. 3 threads in now, need to go essay soon 🙁
Quote Tweet
The biggest deep, lasting change needed is to run more fat. Give up some capital mobility efficiency for resilience. I need to dust off my old material on fat thinking and expand it to TED-talk level grand theory. I’ve been mailing it around more than usual but it’s too modest.
Show this thread
2
1
11
The motifs of the various industrial revolutions:
Zeroth: pendulum clock and telescope
First: steam engine
Second: light-bulb
Third: microchip
Fourth: Lithium battery
1
9
Interesting to think of non-consumable materials motifs in each case:
Zeroth: optical-quality glass
First: steel
Second: vacuum!
Third: arguably plastic (plays a weirdly critical role in electronics even though sand and copper are more obviously important)
Fourth: ?? not lithium
1
2
8
Can you imagine electronics without plastics? Insulation, packaging, petroleum-based solvents and glues, etc etc.
Battery based fat tech-stacks with high levels of software, resilience, etc don’t have an obvious signature material yet. I don’t think it’s lithium.
4
4
Oil as a fuel (as opposed to as a materials feedstock) is a weirdly missing actor in the big history of engineering. It entered the tech stack as a relatively natural and non-disruptive substitute for coal and wood for energy, and plant/animal oils/waxes/tallow for lighting.
3
3
It’s weirdly hard to pinpoint how exactly the oil age changed the course of technology history as a fuel. It was vastly more important politically, financially (as a de facto reserve currency) and economically (allowing vast wealth concentrations) than as a technology.
1
8
IC engines are sort of EC engines (contd) than a new thing.
Aerospace engines have more going on with materials than with dealing with oil per se.
Centuries from now, oil age will be more notable as a materials revolution. As an energy revolution it’s been more a wide detour.
3
3
Another angle: each of the revolutions triggered a sociological transformation.
Zeroth: secular philosophy displaces religion
First: rise of literate worker
Second: emancipation of women/consumerization
Third: specialization/org man/professionalization
Fourth: ? autonomization
1
1
3
Arguably ‘scientific revolution’ is a misnomer for the zeroth revolution because it suggests there was no technology+economic component. In fact, I think the tech (optics and clocks) drove it all.
2

