Often, during development, there comes that point where one is fixing an issue in a system and have to go through the same tweak-compile-deploy-test cycle, over and over. Here are the main problems that are introduced with this approach:

• It's not fun: It's frustrating to have to constantly wait for results without a clear idea of whether it will actually be fixed this time.
• It's not productive: You spend a lot of time waiting for results you wouldn't need if you could just analyze the problem better.
• It wears down the hardware: After removing and reinserting the same connectors dozens of times, writing and overwriting the same sections of the ROM chip countless times, and power cycling the system hundreds of times, the hardware's lifespan is reduced significantly, along with one's own patience, and new errors are introduced.
• Fiddling with test hardware isn't fun: The best-case scenario for any embedded setup is to be able to take the development board, plug in all the peripherals and wiring, flash the ROM with the application, and power it up to see it work. Any deviation from this scenario is frustrating and time-consuming.

Avoiding such cycles during development is therefore essential. The question is how we can most effectively get to a point where we can produce code for something such as an 8-bit MCU or a larger 32-bit ARM MCU without ever touching the hardware until the final stages of testing.