Or alternatively run the algorithm through an emulator that does the same thing.
However, the attacks all rely on reducing noise by combining measurements. Introducing sufficiently-long random delays or sufficiently-big variations in clock speed can make it harder to combine measurements, and can thus stop such attacks. Unfortunately, making trace alignment hard is not so much a provably-correct fix as a contest between the hardware designer's ability to be really annoying and the attacker's intuition (to find usable synchronization points) and sheer persistence.
(If you want to rely on such things, you really need to get a top-notch hardware attack lab such as Riscure to look at your countermeasures; you really want to test against an experienced attacker's intuition.)
The power of averaging is such that these extra security added by these types of countermeasure can rapidly drop to zero. Despite this there are some use cases and deployment environments in which this might still be worth doing.
Ultimately the game for people deploying SCA-resistant hardware is effectively to fix a period of time in which a single key is used, and add sufficient countermeasures to ensure that the attacker can't get the key within that period. 'Perfect' security isn't a strict requirement at all, nor is it possible to achieve.
The only 'provably secure' (e.g., on paper (+)) countermeasure you can apply to these symmetric schemes is something typically called masking. You can view masking as using secret sharing techniques to split up all intermediate computation into independent operations. To defeat masking an attacker needs to be able to re-combine the data dependent information leakage associated with all the split components. This is always a possibility.
Thus it becomes a risk/cost tradeoff. The more you mask, the more secure you become, but at a cost of speed/area/power draw.
(+) It's decidedly non-trivial to implement a masking scheme such that you get the theoretical security. This is an active research area.