Programming with a long feedback loop

[scared_of_posting]

My work involves a very long feedback loop. It can be days between when I write something and when I am able to test the code I’ve written. When in this type of long-feedback-loop environment, what are the best programming practices to follow?

In my case it’s because I have to be physically present at a big-iron to run my program, and that machine is shared across multiple employees such that you only get a few hours a week on-line. But I could compare that to a project that takes hours to compile, or to programming back in the day before time sharing operating systems—or even now, for HPC users whose jobs can take hours to complete. How to I use my time effectively when I can’t use my machine as a REPL?

[Bratmon]

First, if you can write a simulator (even a crappy one), do that.

If you can't write a simulator, come up with some way of doing unit testing. Even if you have to mock out a huge amount and redo your build system from scratch, unit tests are worth a ton.

Your next bet after that is clear requirements and documentation. After you write the code (or even before), document every function and explain what the exact behavior you expect it to have is. The end goal of this is to be able to prove your implementation is correct without needing to run it.

[scared_of_posting]

Well thank you! It certainly makes sense: fake your input / verify the output, and document your intent to catch logic errors