Measure Why the Uv Erase Limitation Mattered for Debug Cycles
# Measure Why the UV-Erase Limitation Mattered for Debug Cycles
## 6. In-System Reprogramming Was Impossible, and That Cost Real Time
The commercial significance of the UV-erase procedure was not that it was slow in the abstract — it was that it made in-system reprogramming categorically impossible, and that constraint fell directly on the most iterative part of hardware product development: firmware debugging. A team bringing up embedded control code, early BIOS routines, or instrument firmware on an EPROM-based system could not patch a single instruction and re-test in place. Every debug iteration meant physically pulling the part, running the full UV cycle, reprogramming, and reinserting it, even to test a one-byte change. Teams working through many debug cycles per day felt this directly: each UV-lamp run bounded how many fix-and-retest iterations an engineer could complete in a shift, and multiple EPROM parts or a spare programmed set were often kept in rotation specifically so one could be erasing while another was already back in the system, trading hardware cost for engineer time.