An old mentor once said "Don't solve things in software that should be solved in hardware."
Unfortunately, adding a clock to the thermal element was a software solution masquerading as a hardware solution. If you have a piece of your system that can start a fire, you need to be sensing temperature, somehow. Sensing anything else is daring reality to get creative with your abstraction model.
> An old mentor once said "Don't solve things in software that should be solved in hardware."
Not if, as the post explains, using software saves 1/3 of the cost. As Hertzfeld said, Woz did something very similar with the Disk II: Buy the mechanism, and create an in-house controller that controls the mechanism more efficiently at lower cost.
Really, the lesson goes back further than that. Woz has talked about how when he showed Jobs the Breakout clone he wrote for the Apple II, and they saw how easy it was to modify the Integer BASIC code to change the game's behavior, they realized how important software would be to the world.
Woz is one of the greatest engineers of the 20th century, and the Apple II demonstrates his talent. But his brilliance at simplifying things always straddles the line between optimized and overoptimized. The Disk II might be his greatest feat at doing more with less, while the video circuitry falls just into overoptimization, given the color fringing, NTSC dependence for color, and lack of lowercase. Integer BASIC is somewhere in the middle; great performance (especially given (or maybe because) Woz knew nothing about mainstream BASIC), but the code is so tightly written that it was easier for Apple to license Microsoft BASIC than to add floating-point code to Woz's work.
Good reminder to monitor for the actual problem, and not a proxy, if you can.
Printer heads being on for 10ms isn't a problem, overheating is. Might have been cost-prohibitive or too complex to add in a thermometer and use that to shut down in addition to the 10ms test, but in a perfect world..
In real world, you have inexpensive to get metrics that act as proxy for the real problem that would be pretty complex or intrusive to measure. "Your pulse is elevated" message may be a warning to decide, if you have enough context and agency, what would be your next steps (or stop completely).
We have to take compromises between what we can do and measure and what would be the perfect policy. In this case you had as much as 2kb for the binary code and limited electronics, I'd say it was a fair enough compromise.
Maybe a second kind of (cheap enough in both electronics and intrusiveness) measurement could had added complementary reassessment that it could had been the right move. In modern systems we have multiple easy/cheap enough to get proxy metrics for a lot of decisions, sometimes we just take isolated ones to signal a potential problem, but in some cases that could be improved taking more into account.
Unfortunately, adding a clock to the thermal element was a software solution masquerading as a hardware solution. If you have a piece of your system that can start a fire, you need to be sensing temperature, somehow. Sensing anything else is daring reality to get creative with your abstraction model.