Harel & Papert. (1990). Software Design as a Learning Environment

Harel, I., & Papert, S. (1990). Software design as a learning environment. Interactive learning environments, 1(1), 1-32. https://doi.org/10.1080/1049482900010102

An elementary school math class developed software to teach fractions. One class. In a high-end experimental school with full access to then-new technology. For part of one semester. Some students did the usual fractions classes, some did the “write some software to teach someone something about fractions”. The software-design group spent a few weeks building their software, and showed better comprehension of fractions. Is it because they designed software? Is it because they were part of an experimental group and thus fractions were a special and exciting topic? Something else? Who knows. But the kids made some interesting software and Harel and Papert got another data point for constructionism.

…our special emphasis on project activity which is self-directed by the student within a cultural/social context that offers support and help in particularly unobtrusive ways.

pg. 3:

We saw the physical environment as a very important factor in shaping a learning culture. These open spaces allowed us to bring the technology closer (physically and conceptually) to students and teachers; to integrate the computer activities with the regular classroom activities; and to facilitate movement and action around the computers; to reinforce communication and information-sharing regarding computer-based activities across grade levels and among teachers.

Sounds like the design of the physical space - not a separate computer lab but a giant combined classroom space with about 100 computer stations arranged in a giant circle, with classroom spaces branching off of that (although, that sounds kind of computer-lab-y, despite their claim to the contrary - I’d love to see a diagram of the school’s layout…)

pg. 5:

…the children’s daily activities resulted in 17 different pieces of instructional software about fractions - one product for each child in the experiment - and 17 personal portfolios consisting of the plans and designs they wrote down for each day’s work, and the pieces of Logo code they had programmed, as well as their written reflections at the end of each session on the problems and changes they had dealt with that day.

So. That’s a whole lot more than just learning fractions. A daily journal of learning. Software representations of what they learned. A portfolio. How much of the learning was a result of the portfolio and reflective practice, and how much as a result of designing software? They say that it’s impossible to separate - that it has to be taken as a whole - but it looks like much of the students’ active learning was really just a rigorous reflective practice. Which is awesome and should be adopted by self-motivated learners. But it’s not “write code and you’ll learn better”. (assuming silicon valley would read this article and say “LEARN TO CODE!")

pg. 22:

…we speculate that improvement in performance might be affected by factors related to the affective side of cognition and learning; to the children’s process of personal appropriation of knowledge; to the children’s use of LogoWriter; to the children’s constructivist involvement with the deep structure of fractions knowledge (namely, construction of multiple representations) to the “integrated-learning” principle; to the “learning by teaching” principle; to the power of design as a learning activity.

That’s a whole lot of stuff going on. It looks like writing software was related to a whole string of things that led to or was correlated with deeper engagement with learning.

pg. 22:

Only by considering them together, and by speculating about their interrelations, can we take a step towards understanding the holistic character of Constructionism in general and ISDP in particular.

Can’t isolate factors in describing the effect of learning environments…

pg. 28:

In the designing process, Perkins1 says, the problem’s meaning is not given by the problem itself; rather, the designer imposes his own meanings and defines his own goals before and during the process.

“his”. ugh.

pg. 28:

Schon’s work (1987)2 is also relevant to this theme. He is interested in how different designers (e.g., architects) impose their own meaning on a given open-ended problem, and how they overcome constraints (created by themselves, or given as part of the problem they solve) and take advantage of unexpected outcomes. This interactive process requires high-levels of reflection and develops the ability to “negotiate” with situations in “as needed” and creative ways.

Designers impose meaning on an environment and its users…

pg. 28:

When composing lessons on the computer, the designer combines knowledge of the computer, knowledge of programming, knowledge of computer programs and routines, knowledge of the content, knowledge of communication, human interface, and instructional design. The communication between the software producers and their medium is dynamic. It requires constant goal-defining and redefining, planning and replanning, representing, building and rebuilding, blending, reorganizing, evaluating, modifying, and reflecting in similar senses to that described by Perkins and Schön in their work.

  1. Perkins, D. N. (1987). Knowledge as design: Teaching thinking through content. Teaching thinking skills: Theory and practice, 62-85. ↩︎

  2. Schön, D. A. (1987). Educating the reflective practitioner. ↩︎

See Also