It is complex, not simple, programs that get the programmer to thinking about program design because only after experiencing one or two complex programs, can you know the value of keeping things simple.
The only effective way to keep things simple is to keep them small. The human mind seems able to rub no more than seven (or so) thoughts together at the same time before it starts making serious mistakes.
The way to keep things simple and small when they aren't is to create abstractions which hide details. Abstractions are represented by modules, objects, or procedures in your source code. They hide details and reduce the number of things you must think about at any one time.
At least, that's the way I thought about abtstractions fifteen years ago when I wrote a research paper and a book on the subject. My concern then was with finding the right abstractions. At the same time, I taught a series of software enginering classes in which my students found satisfactory abstractions.
These students were given a project too large to accomplish singly and then they were forced to work in groups that submitted a design to me before any code was written.
Each team would test its design by walking through the way it would work on some real data. They would sit in a circle and pretend they were the software in the process of doing its job. Data and commands would be passed verballyfrom student te student as each explained what her part of the software would do.
The process worked very well for the size of projects I gave to my students. And as a bonus, it showed my students the advantages of carefully planned abstractions.
About half of those students were profesional programmers studying in the evening for a M.S. degree. Usually one of these would come up to me at the end of the semester and say something like “When over half our alloted time had past and we hadn't yet started to code, I thought the project was doomed. But when it came time to put the modules together, they fit and we more than made up for lost time.”
What those projects didn't do was teach the real value of abstraction. The real value of abstraction is that it provides a language for communication and thought. If your abstractions can do that effectively then it doesn't matter so much if they are the right abstractions.
When you tell somebody where to meet you, you can do so the really hard way by giving them the longititude and latitude of where you are going to be, you can do so the moderately difficult way by describing to them every step of the way to the meeting place, or you can mention mention a known building and say “by the front door”. How hard you have to work depends on the abstractions you have in common.
Likewise, how hard you have to work when solving a programming problem depends on the relevant abstractions you have to work with.
Abstractions can be noun phrases like “building”, modifiers like “large” and verb phrases like “look for”. Abstractions plus grammar equal language.
When building computer software you are much better off if you have a relevant language to think and code in. Such a language may let you talk about patient records rather than patient names and medical procedures. It may let some of you send bills to insurers and others of you set up the way such bills are sent.
I now believe that a good designer comes close to creating an ad-hoc language and that the most effective way to use her is to ask her to take the extra step and create that language.
When a designer creates an ad-hoc language, she not only creates something that keeps the overall logic of a program short and simple—she creates something she that will be reused.
But there is another advantage because designs tend to be improved over time whereas designs tend to be thrown away. Given this fact, it's obvious which will approach give you a greater return for your designer's time in the long run.
Before we had extensible object-oriented languages, it was rather difficult for a designer to make her design into a language. Now, it isn't as difficult but it does require that she have a few more tricks in her mental toolbox than was required of my software engineering students all those years ago.