Thanks a lot, Grischa, for this excellent report. Much of what is documented reflects my own experiences in teaching modeling to undergraduates at the U. of Sydney. (I wish I had your report available at the time, it would have helped a great deal.)
One sentence in the report struck me in particular:
"we often noticed that especially
students who really enjoy programming have a hard time to see the benefits
of modelling in general"
This too reflected my experience, not just in teaching but in industrial practice. Based on that I have come up with a putative theory that there is an important distinction between what I would call "designers" ("architects"?) and "programmers". It is my belief that the distinction has to do with what motivates individuals. Both groups are problem solvers by nature and both require intelligence and skill. However, I find that designers are more interested in solving the application problem whereas the programmers are more interested in solving the problem of programming. Like craftsmen who take pride in their mastery of the complex skills required by their craft, they are often content to implement designs conceived by others. This is not to say that they are not creative, but the type of design challenges that they most enjoy solving is how to translate a concept into a computer-based implementation.
This is not a particularly precise classification and there are indeed many people who belong equally to both categories. However, in my 40-odd years of industrial experience I have found that there are many, many more "programmers" than there are "designers". The latter are distinguished by a reduced focus on (and level of emotional attachment) to implementation technologies -- although a good designer must be fully aware of what available technologies have to offer. This gives them the freedom to choose the technology that is most suitable for a given task. Programmers, on the other hand, tend to use the technology that they have mastered as their starting point, which can be constraining in many cases, not only in terms of technology but also in terms of scope.
But, I am not a cognitive psychologist or a social anthropologist (or whatever the right skill is) to claim that this designer-programmer theory of mine is based on proper scientific principles. (Worse yet, as holds for any attempt to categorize people, it has a whiff of political incorrectness about it.) It would be nice, therefore, if we could take advantage of studies such as yours to investigate more deeply whether such a theory makes sense or not. In essence, it would be a study of the psychology of software engineering. I think that this is very important for us to understand; I have seen too many software engineering projects fail because the task of system design was left to programmers. Perhaps by investigating students and their skills, attitudes, and results, we may be able to gain some key scientifically-founded insights into this issue. It may even prove to be that this is merely an issue of training rather than aptitude. In that case, we could adjust our curricula accordingly.
If you are anyone else is interested in undertaking such a study, I would very much like to participate.
Cheers... Bran Selic
