[rayval]

Ideally, you should not be in this situation where you have to compile large amounts of code to go through the code-test-debug cycle.

Even in a large project, there should be subysystems that a developer owns and works on that can be partitioned or isolated from the rest, and execute within a test harness on a dev machine -- a harness that feeds the subsystem inputs and records outputs.

Successful projects either begin with or evolve to a state where they have the architecture, the toolset, the process and the culture to allow devs to enjoy a fast code/debug cycle.

[Andrew-Dufresne]

Besides subsystems, tools like make and nmake utility can also reduce the compile time.

Make figures out automatically which files it needs to update, based on which source files have changed. It also automatically determines the proper order for updating files, in case one non-source file depends on another non-source file. As a result, if you change a few source files and then run Make, it does not need to recompile all of your program. It updates only those non-source files that depend directly or indirectly on the source files that you changed.

[voxcogitatio]

Yes, but large projects often need to use recursive makefiles, which are notoriously flaky at detecting what has changed (if anything).

[drothlis]

No project needs to use recursive make.

"Recursive make considered harmful": http://miller.emu.id.au/pmiller/books/rmch/