The belief that complex systems require armies of designers and programmers is wrong. A system that is not understood in its entirety, or at least to a significant degree of detail by a single individual, should probably not be built.
But active programming consists of the design of new programs, rather than contemplation of old programs.
Indeed, the woes of Software Engineering are not due to lack of tools, or proper management, but largely due to lack of sufficient technical competence.
Usually its users discover sooner or later that their program does not deliver all the desired results, or worse, that the results requested were not the ones really needed.
The idea that one might derive satisfaction from his or her successful work, because that work is ingenious, beautiful, or just pleasing, has become ridiculed.
Software development is technical activity conducted by human beings.
The possible solutions to a given problem emerge as the leaves of a tree, each node representing a point of deliberation and decision.
Many people tend to look at programming styles and languages like religions: if you belong to one, you cannot belong to others. But this analogy is another fallacy.
Clearly, programming courses should teach methods of design and construction, and the selected examples should be such that a gradual development can be nicely demonstrated.
Go To statement considered harmful.
My being a teacher had a decisive influence on making language and systems as simple as possible so that in my teaching, I could concentrate on the essential issues of programming rather than on details of language and notation.
Program construction consists of a sequence of refinement steps.
I have never designed a language for its own sake.
My duty as a teacher is to train, educate future programmers.
Programs should be written and polished until they acquire publication quality.
Nevertheless, I consider OOP as an aspect of programming in the large; that is, as an aspect that logically follows programming in the small and requires sound knowledge of procedural programming.
Reliable and transparent programs are usually not in the interest of the designer.
Experience shows that the success of a programming course critically depends on the choice of these examples.
I am convinced that there is a need for high quality software, and the time will come when it will be recognized that it is worth investing effort in its development and in using a careful, structured approach based on safe, structured languages.
It is evidently necessary to generate and test candidates for solutions in some systematic manner.
During the process of stepwise refinement, a notation which is natural to the problem in hand should be used as long as possible.