- Separate out delay.c and delay_main.c (as in Project 1) until near the end
when ready to submit. This will keep the menu and user-interaction-related
garbage out of the way of the REAL code.

- Write the menu portion first and test the bejeezus out of it.

- Write the loading routine.

- Write the traversal algorithm itself.

- Write automated test sets, such as:
  - Memory leaktester: performs a LOT of loads and saves and whatnot, and we see
whether it is gorging itself on memory somehow (maybe run it through Valgrind?
I've never used it before.)
  - Validators for the program output against all of the sample inputs.
  - Fuzzer to spit out utterly random input files to smoke out weird errors
    (can these be validated somehow as well?)

- Write a "stupid" version of the program that we KNOW works (though perhaps
very slowly), and then check the results from, say, the fuzzer against that.

- When optimizing, TEST the optimization against the "unoptimized" version for
several inputs, and see which is faster. What actually turns out to be fastest
is often surprising.

- Do a code-standard run-through.