A Method for Program Design
IT, Høgskolen i Østfold
IT, Høgskolen i Østfold
Program design
>The philosophy
All non-trivial development projects that I have been part of, or know of, has involved participants with different backgrounds. They have represented different skills and "schools" within the programming domain and they have represented different perspectives within the application area. In projects for pedagogical design, the pedagogical experience of the participants has played a major role.
The general problem has on all occasions been to find effective means to communicate ideas and proposed solutions. Language is power, and the party that controls the description usually controls the process, and the result. This does not always end up with the best solution for the user. The history of computing does indeed demonstrate that the ideas of the computer professionals, who has dominated the design process, not always match the needs and views of the users.
It has been important to find ways to express ideas and proposals in a way that can be intuitively understood and shared. This supports a broad and substantive participation, a shared responsibility for the result and it supports the creative aspects of design.
A consequence of this approach is a demand for simplicity. Lack of precision will in some cases be the cost. In my opinion this is a fair trade-off in important phases of a design process.
The approach has a pedagogical background and it is in all respects empirical. It has been gradually developed, rethought and adjusted during a great number of projects with educational or instructional computer programs as objective. This means that the tools have been discussed and tested with respect to the pedagogical views and opinions of a lot of teachers with experiences ranging from kindergartens to universities. The products and prototypes have been tested on a great number of students of all ages.
This process has made it clear that the method cannot be pedagogically neutral. The method takes a stand for an open experimenting pedagogy and some of the main tools involved reflect this. This approach is in general terms in accordance with the dominating pedagogical tradition of the Nordic countries where the method has been developed.
The approach takes a radical stand for a design process that starts and ends with the program as a communicating device. In stead of considering the "GUI" (Graphical User Interface) as something you add at a late state of the process, we start there, and adds the contents and the data models late in the process. In fact we don't bother about this at all in this article.
The balance between creativity and formalism is critical in software design. Most design traditions does not have any explicit tools for the creative part of the design process. It seems to be a rather general opinion that creativity is an uncontrolled mental process that is substantiated either as unplanned brainstorming sessions or incidental inspiration.
My experience is that creativity is hard work and that the need for tools for thought and communication are essential during the creative parts of a design process.
Even if the empirical background is within a pedagogical setting, it is becoming increasingly clear that the approach is applicable in program design in general. The main reason for this is that pedagogical thinking is an essential part of almost all program design. The program must communicate an understandable model of data and the problem solving method it supports. The analogy between experimenting to learn and experimenting to do is evident. The designs that supports these two perspectives have much in common, and I will expect, and certainly hope, that pedagogical reasoning will find a broader platform in program design in the future.
