The Singularity debate is long on capability and short on maintenance. I know this pattern. I saw it at an air show thirty years ago when I asked a stealth fighter pilot if his aircraft was hard to maintain and he said “You have no idea.” No system escapes the life cycle. It just shifts where the cost and friction eventually show up. This piece examines what the AI acceleration narrative keeps leaving out, and what systems engineers are specifically trained to ask about it.

When Elon Musk floated the idea of putting servers in space, most people either cheered or rolled their eyes. Systems engineers should do neither. They should recognize the pattern: two radically different architectures, the same stakeholder need, and a genuinely interesting trade space worth examining. I dust off a favorite classroom example from the 2007 INCOSE SE Handbook to show why that kind of architectural imagination — disciplined, not fanciful — is exactly what the Handbook has always asked of us. There is also a free Architecture Alternatives Comparison Worksheet at the bottom, if you want a practical tool to do this in your own program before assumptions quietly harden into designs.

When I heard that Scott Adams had died, my mind went straight to a filing cabinet — and a folder of Dilbert cartoons I used to pull into SE training sessions whenever a room full of engineers needed permission to say what everyone was already thinking. Adams gave technical professionals exactly that: a way to laugh at broken systems before getting serious about fixing them. This is a tribute to the man who did it better than anyone, and a harder look at what his later career tells us about the cost of speaking uncomfortable truths.

Boeing’s recent safety issues highlight how small, accepted risks can accumulate into enterprise-level failure. This article explores what Boeing’s experience teaches systems engineers about risk aggregation, tolerance, culture, and governance—and why disciplined, integrated risk management is essential in complex systems.