- Success and Failure of Projects and Strategies
- Core Competencies
- Education
- The Need for Understanding: Abstraction, Precision, Explicitness
- Abstraction: The Way to Put Management in Control
- Basic Structuring Constructs
- Business Rules: Precision vs. Handwaving
- Tacit Assumptions and "Evident Truths"
- Specifying Problems and Solutions
- Where to Start and Why: Business Domains
This chapter is from the book
This chapter is from the book
This chapter is from the book
Education
The approach to education in computing science and information management should be the same as in other areas of human endeavor. Unfortunately, this often has not been the case: tools and "skills" have been taught rather than concepts, resulting in a training, rather than an educational, process. The problem was recognized and articulated long ago: "...it is clearly wrong to teach undergraduates the state of the art; one should teach them things which will still be valid in 20 years time: the fundamental concepts and underlying principles. Anything else is dishonest." (Strachey, [SE1970]). David Parnas at the International Conference on Software Engineering in 2001 proposed a 30-year test: the material to be taught to students ought to have been valid 30 years ago and ought to be valid 30 years from now. We will leave it to the readers to determine whether the material taught to them—or by them—could pass this test.
On a more general note, the same approach should be used at the earlier stages of education. The Spectator expressed quite emphatically [H2001] that "[n]o one who leaves education now will find themselves with the scaffolding of understanding which would enable them to acquire another language with less effort; not many, it seems, are able to write their own language in any manner other than warbling their native woodnotes wild. Without that knowledge, which once was systematic and not anecdotal, which was abstract and not what our educators so fatuously call 'practical,' children are crippled. An education that drills children in the structure of a language will produce adults who are able to teach themselves how to send emails in an hour, or to speak an unfamiliar language in three months.8 One that aims only to teach them to learn how to surf the Web is going to produce an ignorant underclass." Observe the explicit use of abstraction in this excerpt.
Consider in this context the two prerequisites of a good programmer formulated by Dijkstra decades ago: first, an exceptionally good mastery of one's native language; and second, mathematical maturity (which is not the same as specific knowledge). Clearly, the same prerequisites apply to a good modeler and to a successful decision maker. And when you educate, "you have to teach a grasp of method, a sense of quality and style. Sometimes you are successful." (Dijkstra, [SE1970]). As Dijkstra observed many times, developing the intellectual discipline to keep things sufficiently simple in the environment of unlimited technological opportunities is a formidable educational challenge. Presumably, the technological specifics should be abstracted out, while the underlying concepts should be made explicit and taught.
The educational and training concerns should be clearly separated: in many situations, the teaching of computing science or the teaching of modeling have emphasized training (the idiosyncrasies of the currently fashionable tools and buzzwords) rather than education (concepts and approaches). This results in failure of projects, in human frustration, and in continuous search for and reliance on various miraculous "breakthroughs."
This book emphasizes the educational concerns.