AFTER a top-down design is developed, it's now time to implement each of the modules in the top-down design.
The process we're aiming for is to translate each module in the top-down design to a subprogram, an independent module within the larger program.
A subprogram is a module of code that is separated out from other code and made to operate independently.
Never think of a subprogram as part of another program. Every subprogram should be designed and implemented as a completely independent module that can be used in any program without being modified.
If we run into trouble, we can go back and improve the top-down design. This is common, since the implementation phase will often reveal things that we didn't foresee.
We want subprograms to be small, since the time it takes to debug a block of code is not proportional to the number of lines of code.
Debugging effort grows much faster than the numbers of lines as the size of the module increases. Hence, doubling the size of the module more than doubles the debugging effort. This is generally intuitive. Do you think it would be easier to write five 20-line programs, or one 100-line program?
The exact relationship between debugging effort and module size is next to impossible to determine exactly, and in fact varies depending on the project. However, generally speaking, it would be a concave-up increasing function. Suppose, for simplicity, that the relationship is parabolic:
debug time = K2 * size2
Here, K2 is another unknown constant that reflects the difficulty of debugging the code. The debug time for 1000 lines of code as one large module would be:
debug time = K2 * 10002 = 1,000,000 * K2
Now suppose we could break the project into 10 independent modules of 100 lines each. The total amount of code is the same, but is the debug time the same?
debug time = 10 * K * 1002 = 10 * K * 10,000 = 100,000 * K
By breaking program into 10 independent modules, we have reduced the debug time by a factor of 10!
This is what the use of subprograms does for us. No one on Earth is smart enough to comprehend a 100,000-line program as one large module, yet individual programmers often write programs much larger than this. The key is to break it into many smaller, independent modules during the design stage, and then coding and testing each module as a small, separate, independent program.
Writing a 100,000-line program will take a long time, even if it is broken into 2,000 subprograms averaging 50 lines each. Implementing 2,000 50-line subprograms is a lot of work, but it's only a matter of time before you get it done. If anyone tried to tackle this as one single 100,000-line module, progress would stall quickly, and it would never get done.