Scaling up the process
Part 2 of this series suggested ways to start practicing thinking like a programmer. However there is much more to it. Modification and growth is inevitable for most of the programs. If no appropriate thought is given to these possibilities during the development of a program, then there are limitations to the speed of its growth and modifications: The program organization soon goes out of control. For example, one change in desired outcome may require several changes at several places in the program, and not all of them will be obvious at once. It may turn out to be a lot of trial-and-error cycles of effort to find all such places. The advanced techniques of program organization have such concerns as their central theme.
One of the focal points of these techniques can be called separation on concerns: The task that the program is going to perform has some logical division of concepts. Separation of concerns is achieved by physically separating subtasks related to each logically separate concept into different units. This way, whenever a change is needed, it can be quickly figured out what “concepts” in the program need to be modified, and plan the modification accordingly. This significantly reduces the scatter of modifications required to achieve a single change in outcome of the program.
Another focal point is abstraction and generalization: If there are more than one similar but slightly different subtasks that the program needs to perform, is there a way that they can be performed by a single unit (say a function or a set of functions) inside the program, under slightly different inputs? The motivation: if we understand a group of tasks as similar, then by writing a single unit to handle them, we are reducing the source of errors to that unit. So when a modification is required, or somebody needs to understand that group of subtasks, the number of changes or readings that are required are restricted to that particular unit, not a few almost identical copies of it. Abstraction and generalization also makes parts of the program reusable in future programs.
These can also be described as efforts to increase the human readability of a program. If a program needs to be modified, usually by somebody else, or even ourselves may be six months after writing it, then it must first be understood. It stands a fair chance of being understood when it is written to be read by humans.
Although there is a lot of terminology and buzzwords around, the progression of techniques through structured programming, modular programming, and object oriented programming on the one hand, and functional programming (my favorite) on the other, are essentially in such directions as above. Further, they are not replacements of a good understanding of behaviour of programs; they only help us in creating big programs provided we understand small ones well.