The thing most revealing about Matrox product here might be the SM-640. In 1987 it could push 6,000 shaded polygons per second on a PC, an impressive trick with one awkward dependency: there wasn’t enough software that could use it. The hardware arrived before its ecosystem. Being early sometimes just means paying to educate a market that somebody else eventually inherits. And I had a few Matrix cards, not for gaming, but for Autocad work - back then... That pattern makes Matrox more interesting than a simple tale of a graphics company losing to 3dfx (which I had then for gaming!), ATI and NVIDIA. Again and again, its engineering seems optimised for capabilities that professional users could immediately value: resolution, image quality, multiple displays, frame capture and long-lived compatibility. Consumer 3D was different. Games turned graphics hardware into an ecosystem contest involving APIs, drivers, developer support, release cadence and price. A beautiful framebuffer could suddenly lose because Quake ran better elsewhere. The G200’s extraordinary afterlife is the useful counter-image. A processor that stopped being exciting to gamers became valuable precisely because excitement was irrelevant. Servers need a display controller that works predictably for years, not another benchmark champion. There’s a familiar engineering lesson buried in Matrox’s fifty-year catalogue: technical obsolescence and commercial uselessness are very different clocks. Sometimes yesterday’s GPU has a better career than yesterday’s flagship.

The wonderfully strange detail here is that pictures of the Moon had to travel through several pieces of photographic film before anyone could properly look at them. Film was exposed in lunar orbit, chemically developed inside the spacecraft, scanned into an electrical signal, transmitted to Earth, displayed on a kinescope, photographed onto 35mm film, physically reassembled and photographed again. Digital photography this was not. It’s tempting to see that chain as primitive. I think the opposite is more useful. Each conversion solved a specific constraint using technologies that already worked well enough. Kodak knew film. CBS Laboratories knew scanning. Radio could cross space. Humans could reconstruct the strips on Earth. The result looks absurdly indirect only because later technology collapsed those stages into a sensor, processor and data link. The other striking feature is institutional reuse. SAMOS readout was effectively a failed branch of reconnaissance technology: expensive, awkward and overtaken within its original mission by film-return systems. NASA then changed the problem around it. Suddenly retrieving a capsule from the Moon wasn’t the convenient alternative, and remote readout made rather more sense. There’s a useful corrective here to tidy histories of invention. Technologies don’t necessarily progress by winning their first contest. Sometimes an apparent dead end is simply waiting for a problem with different constraints.

The best image here isn’t a robot dog, an AI musician or even humanoids dancing to G-Dragon. It’s facial recognition next to two-for-one Doritos. Cyberpunk expected technology to announce itself with rain, neon and sinister architecture. Instead, the machinery of the future has been installed between the meal deal and the crisps. That mundanity changes how technological adoption works. We tend to imagine acceptance as a decision: society encounters something novel, debates it, then either welcomes or rejects it. Newman’s collection suggests a less theatrical process. Novelty gets distributed across thousands of tiny encounters until the strange thing becomes furniture. An AI bot joins the meeting. A robot rolls down Gloucester Road. Your glasses might identify a stranger. Nobody convenes a committee on whether reality has crossed into science fiction. His question about writing science fiction is therefore sharper than it first appears. Predicting the gadget may be getting less interesting. The harder job is describing what people become accustomed to, and what that accommodation does to them. The line about adapting to the future in 48 hours feels uncomfortably plausible. Humans are extraordinarily good at normalising changed circumstances. That’s probably why civilisation functions. It may also be why the genuinely weird stuff can arrive without anyone remembering to be astonished.

I’m living through the distinction Weeraman describes with OFE, my Outcome Forward Engineering product. It started as a proof of concept. Then it became an MVP. Now there’s a roadmap, feature requests and pricing. Somewhere along that progression, “does this idea work?” quietly became “what exactly are we selling, to whom, and what must remain dependable when people start relying on it?” That transition is hard, and code generation only touches part of it. The POC was useful precisely because it didn’t have to answer every question. It proved enough to justify the next question. Since then, a lot has changed because real product development keeps introducing information that wasn’t available when the first version was built. Features interact. Users want things you didn’t anticipate. Architecture that was perfectly reasonable for demonstrating an idea starts acquiring consequences. Pricing forces uncomfortable clarity about where the value actually sits. This is where I’d extend Weeraman’s argument. The distance between prototype and product isn’t only an engineering gap. It’s a learning gap. AI can make the artefact appear unusually complete before you’ve accumulated the knowledge that normally accompanies building it. OFE’s POC wasn’t the product. It couldn’t have been, because I hadn’t yet learnt what the product needed to become. That’s the difficult bit I’m working through now.

This feels like the other half of the prototype argument from the previous piece. A POC gives you permission to move quickly because its job is to answer a narrow question. The mistake is carrying that same velocity, and the same tolerance for unresolved assumptions, into every stage that follows. I’ve seen that with OFE. It began as a POC, became an MVP, and now has a roadmap, feature requests and pricing. I’ve also changed its features and direction multiple times. Some of that is normal product discovery. Some of it has required deliberately slowing down and asking whether what I’m building still matches the problem I thought I was solving. The ability to build something quickly can make that pause surprisingly difficult. There’s always another feature you could ship instead. That’s where Graybeard’s distinction between urgency and haste lands for me. Fast prototyping is extraordinarily useful because building can be a form of thinking. But once the prototype starts becoming a product, thinking has to include occasionally dismantling your own assumptions. Otherwise “iteration” becomes a flattering name for repeatedly moving before you know where you’re going. OFE today is quite different from its original POC, and that’s increasingly something I see as evidence of the process working. The prototype proved an idea could exist. Building the product has meant repeatedly stopping long enough to reconsider what it should become.