LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestras Condiciones de uso y nuestra Política de privacidad para más información.
LinkedIn emplea cookies para mejorar la funcionalidad y el rendimiento de nuestro sitio web, así como para ofrecer publicidad relevante. Si continúas navegando por ese sitio web, aceptas el uso de cookies. Consulta nuestra Política de privacidad y nuestras Condiciones de uso para más información.
James O. Coplien
19 Nov 2014
Architecture and the Child
Time to Play
The intersection of childlike creativity and business imperatives in software
design offers insights into the mental processes of design. Design is most
popularly discussed as a handmaiden of method and its academic
trappings. Modern design philosophy as we ﬁnd in object-orientation and
the agile movement call us to re-explore whether method cuts off
exploration of key aspects of design. Games superﬁcially offer a more
lighthearted alternative but under closer examination we ﬁnd them to be
thinly disguised methods with a somewhat predetermined outcome and
largely predetermined process. Unlike problems in formal logic, design
never has a single, right outcome, and there is no “best architecture.” Child-
like play seems to offer a better match to the processes necessary to design
complex systems, though there may be a constructive tension between
games and play in any given design effort. We ﬁnd that powerful metaphors
from developmental childhood psychology, from the principles of
architecture of the built world, and from ancient Greek culture inform the
Architecture is traditionally about form. In the architecture of the built world, Vitruvius
tells us that architecture has three goals: ﬁrmitas, or structural integrity; utilitas, or usefulness;
and venustas, or delight. These ideas are equally appropriate to software architecture, and
particularly to those software systems that serve human beings. We ﬁnd the most obvious
human-computer links in interactive software as opposed to, say, ballistic missile control
software. Even so, the architectural metaphor entered software much earlier when Fred
Brooks mused it might be a good metaphor for what we do in software. He tried out the idea
on Jerry Weinberg, who concurred .
Architecture has long been held as a staple of sound software practice — at least, until
the 1990s. Agile tended to disdain architecture as make-work. One phenomenon I observed
was the rise of consultants in the object-oriented days — consultants who knew computing
ARCHITECTURE AND THE CHILD WITHIN !1
technology well but who did not bring deep business experience with them to an engagement.
This perspective grew rapidly with the advent of agile software development. It is likely that
they overplayed the Toyota Production System notion that process trumps product. Product
focus migrated from business planning to the developers, and agile became the revenge of the
Object-orientation is a paradigm for designing systems — for producing architecture.
The agile discipline arose out of the object-oriented community and its belief that individuals
who managed their own encapsulated objects could magically make changes locally: a boon
to rapid feature introduction. Object orientation ﬁrmly took root in the technological
advances that supported graphical user interfaces (both Model-View-Controller and objects
came from Xerox PARC in the 1970s and 1980s), so object orientation tended to appear in
systems more closely tied to the human user than one ﬁnds in, say, industrial control software.
The anthropomorphic design metaphor took strong root in object-orientation; agile would be
about individuals and interactions. It took many years for real-world experience to align the
idealism with reality but many of the early myths and unsubstantiated practices persist today.
It is nonetheless at least instructive and perhaps crucial that we revisit the original foundations
that history has obscured.
Object-orientation enjoyed even more explicit roots in the realm of psychology. Alan
Kay, who coined the term “object-oriented,” was seeking a way to help children learn as an
alternative to the programmed learning approaches of the Skinner school. His vision was to
build a machine dunned “The Dynabook” which would extend children's' senses (or, more so,
ARCHITECTURE AND THE CHILD WITHIN !2
mental function) into the world around and beyond themselves, to enable learning by
exploration. The children would themselves program the machine to carry out experiments,
in a simple language that today we recognise as Smalltalk.
Kay did experiments with children on the early Xerox Dove, Dolphin and Dorado
machines. These machines were built around what was, for the time, an exquisite graphical
display. Doug McIlroy would add his contribution of multi-window systems — which he felt
necessary to represent the many contexts that a child would manage in parallel — and the
mouse — which allowed the user to kinaesthetically switch between contexts.
Childhood Development and Play
It is from this early work of Kay that we take our cue for play in design. in Kay’s world,
children created software worlds on the strengths of their imagination and their tendency to
not ﬁlter out ideas that adults had learned, through experience, to ignore. In the nurture-
versus-nature debate Kay’s work stood more ﬁrmly on nurture than nature. The approaches
of the Skinner school would program children to elicit socially conforming behaviours, much
as one can train a rat to run a maze, whereas Kay wanted children to discover and model
their environment on their own and construct their own models of their reality. Kay wanted
these models to live in the computer as reﬂections of the originals in the child’s mind, and he
called the instances objects. Kay writes:
ARCHITECTURE AND THE CHILD WITHIN !3
We feel that a child is a "verb" rather than a "noun", an actor rather than an object;
he is not a scaled-up pigeon or rat; he is trying to acquire a model of his surrounding
environment in order to deal with it; his theories are "practical" notions of how to get
from idea A to idea B rather than "consistent" branches of formal logic, etc. We
would like to hook into his current modes of thought in order to inﬂuence him rather
than just trying to replace his model with one of our own. 
We can summarise Kay’s work as striving to match children’s mental models with the
world around them. The most fundamental primitives of human mental models appear to be
at least in part learned rather than innate, and it may be that studying these phenomena in
children removes cultural biases learned later in life from social convention and method.
These models include basic models even of geometry. Vosniadou  has outlined such
general patterns of development. From early on children learn to distinguish living from non-
living objects (“Spelke objects”); this becomes an intriguing observation in light of
Alexander’s notion of “living architectures.” This mental model facility is available from
about three months. We tend to learn gravity between 6 and 8 months, and gravity appears to
be important for the development of an understanding of symmetry. Even symmetry is
learned: early blind people, though they have excellent memories, do not develop the same
notions of vertical symmetry as sighted individuals . Cause-and-effect slowly emerges
between 6 and 12 months. We hold these mental models and can process them in our mind’s
eye to predict and to aid analysis. They are fundamental to architecture.
The childhood psychologist Piaget focused primarily on higher-level mental models than
those relating only to physics. Kay took inspiration from Piaget  and his theory that
children modelled their world as operational models. Kay again:
Two of Piaget's fundamental notions are attractive from a computer scientist's point
of view. The ﬁrst is that knowledge, particularly in the young child, is retained as a
series of operational models, each of which is somewhat ad hoc and need not be
logically consistent with the others. (They are essentially algorithms and strategies
rather than logical axioms, predicates and theorems.) 
The notion of “ad hoc”-ness and the apathy about logical consistency bode well for
play. Papert was another spokesperson for work in this area, and the source of the famous
quote: “Should the computer program the kid, or should the kid program the computer?” 
He would famously invent the programming language Logo which children could
conveniently use to control “turtles” that held pens and walked according to scripting
provided by the child.
ARCHITECTURE AND THE CHILD WITHIN !4
Kay almost certainly was inspired by Simula-67, which was arguably the ﬁrst object-
oriented programming language. Simula-67 enabled the programmer to model and
simulate the dynamics of real-world phenomenon: a world of operational models. Simula
used classes as its primary units of construction, but the intended execution model was that of
tasks. Simula could nonetheless be used as Algol with abstract data types, at the option of the
programmer — there was nothing to force or even encourage the expression of operational
models in the code.
Piaget felt that operational models were naturally acquired at the earliest stages of
childhood development, whereas logic and declarative learning developed only in later
months. This may suggest that perhaps the essential human being is closer to these
operational models than to the usual trappings of contemporary (both in Kay’s time and
today) software development: method, standards, and formalism. Play was central to Piaget’s
theories, and he held it to be fundamental tools for assimilation and for adapting to new
environments and situations .
Later research would undermine some of Piaget’s fundamental theses. For example,
Weist  found that children develop their declarative memories at about the same time as
they develop operational memories. And Samarapungaven et al. found that children have a
need for “empirical and logical consistency” in the development of their world-models (e.g.,
for the cosmos in which they live) . However, these ﬁndings do not seriously diminish the
importance of operational modelling, and many of Piaget’s notions in that area still provide a
basis for design.
Research has also borne out the stunning degree to which basic design concepts are
more shaped by humans' developmental environments than by base human nature. Weist 
and others  found that the way children conceptualise the workings of their world is,
somewhat unsurprisingly, shaped by the myths of their upbringing. In particular, even
language itself interacts deeply with cognitive development. Basic notions of geometry that
we ﬁnd as in and on, or up and down, in English, may depend on the orientation of the speaker
in some cultures and on dead reckoning in others. Concepts of up and down may not be
developed enough to apply in novel situations until about age three . Language may
shape whether one views form for its own sake or in terms of properties of its environment.
Spatial inﬂexions, such as exist in Finnish, give Finnish children an advantage over Polish and
English children in geometric reasoning or memory. Geometry is the oracle of form, and
ARCHITECTURE AND THE CHILD WITHIN !5
form is the oracle of architecture, so this sensitivity to language looms large in the
I bring up this research because of its support for the argument that nurture trumps
nature. While most of these facilities are developed in early childhood, later learning can re-
wire them. So a learned method, or the application of a set of rules that might be formalised
as a game, of course also strongly shape design behaviour. But more importantly, they shape
perception itself. To consider an extreme example, David Week related a story from a visit to
one of the Sepik tribes of New Guinea. The houses were arranged around a central clearing
that was roughly circular and distinctly open. He inquired of the inhabitants about the
purpose of the open space. The quizzically responded, “What open space?”
The software design ﬁeld is no stranger to the need for accommodating a foreign
conceptual framework of form, as we ﬁnd in much-celebrated problem to shift to new ideas
from the early days of object orientation, when it was called a paradigm shift. Procedural
programmers had difﬁculty even conceptualising objects, let alone understand them. There is
plenty of evidence that goes against the oft-heard argument (of that era) that objects are
“natural” to human perception. Even if that might be true for infants, it’s certainly not true
for the adults who had had that perspective trained out of them.
The beginning of the end
From early on, object-oriented programming languages would converge on the class
rather than the object as the way the programmers (rather than users) represented their
mental models. What apparently started as an experiment (we actually ﬁnd the notion of
“class” mentioned in Kay’s earliest work ) eventually became de rigueur.. Programming
languages took classes as their primary coding technique, and classes came to represent the
primary structural organising principles. Object-oriented programming gave way to class-
oriented programming. Proponents of earlier design methods, such as structured analysis and
design, came to view classes as better than the data structures of their own methods, but
improved by the incorporation of methods that turned them into “smart data.” But these
data were still there to passively do the bidding of some higher-level controller, and the notion
of operational models gave way to a less powerful master-slave worldview. Particularly with
the advent of C++, object-oriented programming became a way to assemble abstract data
types rather than as a way to playfully explore and model the surrounding world. It was an
almost infantile return to “Spelke objects” that were a shadow of the operational models of
the more developed human.
ARCHITECTURE AND THE CHILD WITHIN !6
Abstract data types were simple and small enough to support formal reasoning, and the
notions of design and formal method began to creep into object orientation and displace the
original notions of playful exploration. The methodologies created in the 1960s to elicit the
expected social behaviours in companies like IBM — to reduce product risk — took over.
Children and Design: Broader Musings
Considerations of the value of play go deeply into the nature-versus-nurture debate.
The tentative stance I adopt here is that most design regimens are learned rather than innate.
This is particularly true in contemporary software. In fact, the term design almost always
connotes higher learning and even academic accomplishment: hacking is viewed as the
antithesis of design. Such learning provides a foundation not for exploration but for the
creation of form and artefacts, a perspective perhaps based on the perspective that informed
or educated design is more efﬁcient than exploration.
However, the beneﬁts that modern software construction has gained from the so-called
“agile movement” cast doubt on up-front design. The issue is further complicated by a failure
to distinguish between analysis and design activities, particularly in the realm of method. The
very fact that the term “object-oriented analysis” has gained even the slightest credibility
stands testimony to the confusion: analysis is about understanding the natural form of a
system whereas object-orientation is about creating forms that obey the rules of a game we
call “ﬁnd the objects.” Object-oriented analysis of fast ﬁnite Fourier transforms is certainly
possible but is unlikely to be instructive. In his address to the 2014 Rakuten technology
conference Yukihiro Matsumoto  suggested that we put strict professionalism aside and
that we intend patiently look to the work of amateurs, immersed in their work environments,
to guide the development of programming languages as he developed Ruby. All of these point
to a more child-like approach to design than design formalists might be comfortable with.
This perspective isn’t limited to software, and in fact may be less present in software
than in more vernacular ﬁelds. In The Timeless Way of Building , Christopher Alexander
alludes to childhood or to children at least 57 times. We ﬁnd him saying the likes of these (all
But though this method is precise, it cannot be used mechanically. [27, Chapter 1]
The fact is, that even when we have seen deep into the processes by which it is possible
to make a building or a town alive, in the end, it turns out that this knowledge only
brings us back to that part of ourselves which is forgotten. [ibid.]
ARCHITECTURE AND THE CHILD WITHIN !7
Although the process is precise, and can be deﬁned in exact scientiﬁc terms, ﬁnally it
becomes valuable, not so much because it shows us things which we don’t know, but
instead, because it shows us what we know already, only daren’t admit because it
seems so childish, and so primitive. [ibid.]
Indeed it turns out, in the end, that what this method does is simply free us from all
And in later traditional societies there are bricklayers, carpenters, plumbers—but
everyone still knows how to design. For example, in Japan, even ﬁfty years ago, every
child learned how to lay out a house, just as children learn football or tennis today.
People laid out their houses for themselves, and then asked the local carpenter to build
it for them. [op. cit., Chapter 13]
A child who helps to shape his room will also help to generate the larger patterns for
the stairway and the common space outside his room. [op. cit., Chapter 18]
The prismatic buildings of our own time, the buildings built with the simple geometry
of cubes, and circles, spheres, and spirals, and rectangles; this geometry is the ridive
order, created by the childish search for order. [op. cit., Chapter 26]
There has always been something so fundamental about architecture that it can be tied
even to the mental models of a given culture’s children and to a playful design approach.
Over time, architecture has unfortunately been assigned to adult concerns. The question is:
Can we resurrect some of the child-like thought processes and, if so, might they bode well for
designs that more fully harmonise with the world around them, and achieve Kay’s vision?
Play and Time
It’s clear that play has a time element. Curiously enough, Alexander describes
architecture as being about “what happens there” in a way that is difﬁcult to separate from
Piaget’s notion of operational models. These are the models that Kay also took to reach out
to children (or, more properly, to allow them to connect with the computer). Method, games,
and play usually have some notion of time progression, in increasing measure, in that order.
Quality gates are one example. More from Alexander:
And ﬁnally, of course, I want to paint a picture which allows me to understand the
patterns of events which keep on happening in the thing whose structure I seek. In
other words, I hope to ﬁnd a picture, or a structure, which will, in some rather obvious
and simple sense, account for the outward properties, for the pattern of events of the
thing which I am studying. [27, Ch. 5]
Kay sees role differentiation over time as essential to an engaged mental process in a
child. His worldview, built on Piaget’s operational models, is as much or more about the form
ARCHITECTURE AND THE CHILD WITHIN !8
of time than the form of matter. Childhood activity unfolds as a sequence of role changes
over time. Kay writes:
A number of the principles which led to Moore’s “talking typewriter” are worth
examination. He feels that it is not so much that children lack a long attention span,
but that they have difﬁculty remaining in the same role with respect to an idea or
activity. The role of “patient listener” to an idea can quickly lead to boredom and lack
of attention, unless either roles can also be assumed such as “active agent”, “judge” or
“game player”, etc. An environment which allows many perspectives to be taken is
very much in tune with the differentiating, abstracting and integrative activities of the
Architecture is about patterns in the broad sense: notions that recur in the form of a
building or in the buildings of a given culture. Alexander talks about patterns of events. Hall
 describes a study that examined the frames of a movie of children on a playground. He
measured ﬁne motor movements in the children in the ﬁlm and found that they all
synchronised to the same rhythm. Curiously, they all followed the rhythm of a girl skipping
This notion of time often goes unheeded in software architecture. A crucial question
lurks: what is the form of time? Of function? Western culture tends to separate time and
space, whereas eastern culture ties these terms together more closely. Time is 時間 in Japanese,
where 間 is a word denoting space or “measurement between,” in the sense of interval.
DCI  is a design paradigm that embraces the form of function as a ﬁrst-class design
concern without sacriﬁcing either object identity or classiﬁcation of domain entities. This is
closer to Kay’s original notion of objects and operational models than we ﬁnd in the much
more class-oriented practices of the past 30 years in software practice. Its focus on
behavioural “Contexts” ties into the playful exploration of behaviour (e.g., with CRC cards)
and ﬁts well Kay’s notion of dynamic role-playing by an object. There is a pattern of role
sequencing in time which lends itself well to expression in code.
Method, Games and Play
To consider how we can harness the powerful aspects of child’s orientation to the world
around them to design, we might be well-informed by the characterisation of childhood
activities. I’d like to entertain the difference between games and play as a potentially useful
scimitar that may differentiate learned adult behaviours from what may be more “innate”
ARCHITECTURE AND THE CHILD WITHIN !9
Before proceeding to talk about games and play, I want brieﬂy to introduce a third and
more vulgar form of constrained interaction popular in design circles, which is method. Much
of the postmodern design world abhors the notion of method: one ﬁnds agilists excoriating
methodologists, and the very founder of patterns emphasises that patterns cannot be a matter
No one will become a better designer by... following any method blindly…
Poincaré once said: ‘Sociologists discuss sociological methods; physicists discuss
physics.’ I love this statement. Study of method by itself is always barren, and people
who have treated [Notes on Synthesis] as if it were a book about ‘design method’ have
almost always missed the point of the diagrams, and their great importance, because
they have been obsessed with the details of the method I propose for getting an the
diagrams [i.e., patterns]. 
Software architecture today is saddled with method. There has been widespread interest
in more game-oriented and playful approaches to software architecture in the post-modern
software movements of patterns and agile development, and I will review some of those later
in the paper. Games are very much in fashion right now in the “soft” side of software, and it’s
encouraging to see software starting to rise above method. I believe that play is the next level
of advancement into the rich territories of the mind.
At even lower levels we ﬁnd automation and a desire to relieve humans not only of the
tedium within design, but to treat design itself as tedium from which we should remove
human involvement. Such approaches are beyond the scope of what will be discussed here, as
I feel we lie squarely in creative territory not yet able to be displaced by automation.
Automation is a vulgarisation of intellectual endeavour borne out of micromanagement of
ARCHITECTURE AND THE CHILD WITHIN !10
the economic theory of value, ignoring other traditional values including those relating to
human sense and human scale, and casuistic theories of value . It is nonetheless
instructive to view method as automation’s cousin and to consider all the liabilities that come
There is an interesting potential mapping of this taxonomy onto Snowden’s
Cyneﬁn  system for characterising complexity. Automation can apply well only to simple
and complicated systems. Method is most likely to be used to apply to complicated systems,
but it falls short of truly meeting the needs of complex systems. Games are difﬁcult to
distinguish from method in this regard.
The term game is one of the most difﬁcult terms to properly deﬁne, not only in English,
but in most natural languages. The dictionary gives us a bit of help in saying “a form of
competitive activity or sport played according to rules” . Carse  uses the term ﬁnite games
as a more precise designation of the vernacular English game. His deﬁnition comprises crisp
characteristics such as voluntary participation, voluntary adherence to a pre-agreed ﬁnite set
of rules, time-boxing, the emergence of a winner and others, and the presence of an
audience that gives value to the winner’s success. Generally, games strive to achieve some
explicit goal under arbitrary constraints and rules of interaction. We will better deﬁne “play”
in a bit, but the main distinction between play and games lies in an internal versus external
focus, respectively. Play is intrinsically motivated while games strive towards some goal, and
play is less constrained by externally imposed rules than are games.
Even though games and methods are closely related, games can rise to handle complex
systems if one admits the ability to change the rules of a game: an inﬁnite game instead of a
ﬁnite game. Play can in fact rise to characterise chaotic systems. The mapping isn’t perfect for
a variety of detailed reasons but there is general conceptual alignment across these two
models. Carse’s use of the term inﬁnite game is closer to the word play as I use it in this paper,
and almost all play is more closely related to inﬁnite games than to ﬁnite games.. Inﬁnite
games have rules that initially constrain play, but also have rules for changing the rules. Those
familiar with the comic strip Calvin and Hobbes (Steen og Stoffer in Danish) will recognise
Calvinball as a kind of inﬁnite game. As the name implies, the goal of the game is to keep
playing the game: there are no termination criteria short of, perhaps, the death of all players.
Carse ultimately embraces the extreme of complete engagement, with no separate audience,
with the ominous pronouncement that “there is only one inﬁnite game” in which we are all
ARCHITECTURE AND THE CHILD WITHIN !11
Ancient Greek Play
We can go travel back in time to ancient Greece to gain insight into the difference
between games and play. Greek society had labourers — farmers, construction workers, and
service staff — at one end of society, and the intellectuals at the other end. Those who did
not work had leisure time to think great thoughts and, in a socially responsible way, carry on
the dialogue that would chart society’s direction. This might happen in the town’s exedra,
where people gathered to exchange news or to have exactly such discussions. The Greek word
for leisure is scholē from which we derive the English word school. “Scholē” infers neither work
nor play. What one did at school was paideia (from pais, “child”): in English, intellectual
nurture and accomplishment, or learning. On the other hand, the workers needed only a
break, a relief, and an occasional distraction from their work to keep them refreshed. For this
the Greeks used the word paizein (whose root is also pais), which is tantamount to our word
play. So, in short:
Aristotle thought of education as completely separate from play, arguing that
education is a way to spend leisure-time edifyingly, whereas play is nothing more than
a break from work: “We should ask what activity real leisure (scholē) consists of. It’s
certainly not playing. That would mean play was the be-all and end-all of life, which is
out of the question. The fact is that play relates to work more than to leisure: the
worker needs a break, and play is about taking a break from work, while leisure is the
antithesis of work and exertion.” 
We ﬁnd this perspective has been ﬁnely honed in modern times. Many high arts are
elevated forms of basic survival needs: food becomes haut cuisine, clothing becomes haut couture,
and shelter becomes architecture. As late as 1938 Johan Huizinga proposed that high culture
is the result of play . Freud wrote that creative writing “is as same as the child at
play” ; we can argue that creative writing and architecture have mach in common. We
certainly ﬁnd that we cannot separate culture from the Greek notion of play.
ARCHITECTURE AND THE CHILD WITHIN !12
Table 1 (adapted from ) summarises differences between games and play, and we will
use this characterisation of play as our foundation throughout this article. If we look at
contemporary system architecture practice we ﬁnd that it closely matches the game metaphor.
It measures its success against its ability to achieve some business goal. Most architecture
efforts are strapped with design rules. Architecture is usually carried out on the designer’s turf
with a disproportionate focus on the technology decisions and engineering tradeoffs and
much less on true engagement with the end user mental model. Engaging the actual users of
the system in its construction is a practice so rare that it is distinguished with the categorising
label Participative Design, and in recent years there have been strong aspirations even to
reduce or remove human decisions which are instead taken over by design tools. Such tools of
course also deliver rules and constraints that further push design out of the realm of play into
games, and even deeper into method.
The notion of “carrying out a game as though the activity were real” bears some
thought. Play is often a simulation of some real-world situation: a dynamic enactment that
responds to the emergent states and insights that surface during the activity. Roles are one
common tool of play: a child will adopt a role, or a persona representing a role, in the play. It
is this role normalisation, rather than any use case, that gives play its structure. Moore’s
rationale for the success of his research is that a child may not give in to boredom with an
activity or concept by shifting from the current one to another during a play session but may
indeed change his or her role. Recalling the Kay quote from above:
A number of the principles which led to Moore’s “talking typewriter” are worth
examination. He feels that it is not so much that children lack a long attention span,
but that they have difﬁculty remaining in the same role with respect to an idea or
activity. The role of “patient listener” to an idea can quickly lead to boredom and lack
Motivated by some extrinsic desideratum Intrinsically motivated
Always seeded with a set of rules. In ﬁnite games the
rules are ﬁxed; in inﬁnite games, they evolve
Relatively free of externally imposed rules
Constrained and delineated consequences and
Carried out as though the activity were real
Focused on an outcome Focuses on the process rather than any product
Players, audience, and referees Dominated by the players
Requires active involvement of the players Requires active involvement of the players
ARCHITECTURE AND THE CHILD WITHIN !13
of attention, unless either roles can also be assumed such as “active agent”, “judge” or
“game player”, etc. An environment which allows many perspectives to be taken is
very much in tune with the differentiating, abstracting and integrative activities of the
Roles are an important component of human mental models that have long been
missing from software design and programming language formalisms. Trygve Reenskaug’s
early work with OORAM  was one of the early efforts to introduce role modelling into the
design vernacular. Today Reenskaug’s thoughts have become reﬁned in a design paradigm
called Data, Context, and Interaction , inspired in large part by the original vision of
object-oriented programming at Xerox PARC.
The notion that games are about process rather than product harks back to Carse’s
notion of inﬁnite games. In software we of course recognise this ﬁrst at the vulgar level of
agile development: that product is never done, but can always evolve in response to feedback
in a complex, dynamic world. We deliver product increments but “the product” can be
delineated as a deﬁnable thing only with respect to a given point in time. Bringing the aspect
of play-fulness into Carse’s perhaps more sobering characterisation of life-as-play offers what
I ﬁnd to be a powerful metaphor for evolving systems.
The Danger of Games in Complex Design Fields
Plato heralded what he believed to an honourable and powerful property of games: that
they exacted conformance to social expectations.
No society has ever really noticed how important play is for social stability. My
proposal is that one should regulate children’s play. Let them always play the same
games, with the same rules and under the same conditions, and have fun playing with
the same toys. That way you’ll ﬁnd that adult behaviour and society itself will be
As it is, games are always being changed and modiﬁed and new ones invented, so that
youngsters never want the same thing two days running. They’ve no ﬁxed standard of
good or bad behaviour, or of dress. They fasten on to anyone who comes up with
some novelty or produces something with different shapes, colours, or whatever. This
poses a threat to social stability, because people who promote this kind of innovation
for children are insidiously changing the character of the young by making them
reject the old and value the new. To promote such expressions and attitudes is a
potential disaster for society. . . . 
So the goal of games in Greek society, according to Plato, was to hijack the nature-
versus-nurture debate and ensure that good Greek children grew up to not challenge the
major mores of society, which those games encoded. Perhaps games like Matador and
Monopoly are the contemporary epitome of Plato’s vision: to program ﬁduciary responsibility
ARCHITECTURE AND THE CHILD WITHIN !14
and a hunger for growth and capitalistic thinking in the cultures where they are played. Most
of us remember our own childhood days or watch our children as we suffer the painful
disappointment of losing in a sports competition; society tells us that this is a learning that
makes us stronger and prepares us for the hardships of life (or for trying to beat the hell out of
our competitors). The structure of Monopoly itself, played seriously, reduces to zero-sum-
game thinking. There is a ﬁxed amount of real estate on the board, and luck and overly
conservative or overly aggressive strategies will inevitably lead to a state of bankruptcy for
successive players, with a winner (or team of colluding winners) emerging at the end.
Such games can work in simple and complicated systems. In a complicated system one
can, in theory, predict the outcome, given the starting state and the rules. Monopoly and
Matador are not strictly just complicated systems in the small because of the rolls of the dice,
but at a practical level statistics win out and one can predict which of two strategies will win
out over the other. The more interesting cases, that supposedly make these games fun, occur
when multiple players use similar strategies and skill gives way to pure chance. Of course, real
life is like this.
However, design is rarely served well if carried out according to the rules of a game at
the principal level of discourse. There is no single “best architecture” and certainly no known
method to achieve it. Worse, even if one could ﬁnd today’s “best architecture” the progress of
human endeavour will leave it behind in a suboptimal state tomorrow. Design does not pit one
player against another any more than it pits the current version of a system against a future
version that suffers the march of time and the changes brought on by world progress, regress,
and randomness. Modern educational systems such as those conceived by Steiner, Waldorf,
and Montessori place much less emphasis on competition or “winning.” In life and in
complex system development, the rules of any given game cannot foresee the emergence that
might arise in the markets or technology.
Safe, Bounded Play
There is probably a fruitful middle ground that we might call bounded play. If play
becomes nothing but random actions, it is likely to expend large amounts of energy with very
low reward. At the extreme, playing can lead one or more players over the cliff, or into the
neighbouring swamp or quicksand, resulting in the ﬁgurative (or, sometimes, literal) death of
one or more players. To keep its playful effectiveness, play must be safe. Boundaries are one
easy way to constrain play to keep it safe.
ARCHITECTURE AND THE CHILD WITHIN !15
The nature of a good boundary is that it interferes with safe, free play as little as
possible, and that it redirects player from unsafe possibilities in a way that removes the very
possibility of casualty from the conscious mind. Good boundaries are either tacit or invisible
and are designed to perpetuate the spirit of play while keeping the participants safe.
Note that boundaries are not designed to take the play in the direction of fruitfulness;
they exist only to block off known unsafe paths. Still, no play can be 100% safe because not
all unsafe paths can be foreseen. Too many constraints turn play into a game, which can
radically limit the exploration space and the opportunity for creativity. Good play offers equal
possibility for inane results as for profound results: we cannot sort these out in advance, and
no game should prejudice the results with pretence of such foresight. See the discussion below
on Weinberg’s VerseWorks as an example of safe play.
There may be a niche for unsafe play in the context of a meta-boundary that provides a
less secure level of safety. This is the realm of architectural research. Even though a given
design paradigm may not work out, the scope of the activity may be constrained to limit the
monetary loss of the scope of failure. Taking more risk, you might allow the enterprise itself
to fail, but at least the owners don’t lose their houses (which is why limited liability
corporations exist). The Transputer architecture comes to mind, or Intel’s iAPX 432. At the
next level of risk you might mortgage your house to bet on some architectural fantasy; but if
you lose your house, at least the government will support you and you won’t lose your life.
Paradigm shifts occur when a tipping point is achieved in the number of people willing to
sufﬁciently advance their risk horizons to the point of broad adoption or a paradigm or
Going in the other direction, the most constrained form of play is a game. The winning
criteria are largely predetermined (e.g., we will be using object-oriented design) but the path
to the game’s end may be left open (we don’t know what objects we will be using). Further
gamiﬁcation may stipulate the use of certain libraries, frameworks, or platforms, further
constraining the outcome of the games and the winners of the game (those who advocate a
given platform). Constrained use of a given framework tightens the rules even further and
starts to reduce design to parameterisation.
Method is the most rudimentary and constrained form of game-like activities and is one
of the most common design milieus in software today. Removing constraints such as metrics
and design quality gates, a design team can graduate from method to something more game-
lie using techniques like CRC cards . We might view CRC cards as a rudimentary form
of safe play; see later in this paper.
ARCHITECTURE AND THE CHILD WITHIN !16
The Payoff of Play
Research has shown that child activities based on play, rather than games, have many of
the properties that we hold dear for design. Dansky and Silverman found that children who
played with objects during a play session produced signiﬁcantly more uses for those objects
than did a control group. , 
It is likely that play increases creativity. There is evidence that when pretend play occurs
in multiple sessions over time, creativity increases.  Research by Kasari, Freeman, and
Paparella bears this out.  Creativity is important in architecture because architecture is in
fact as much the creation of a synthesised reality more than the modelling of any reality. 
Games and Play in Software Today
Game theory has long been used as a tool to predict how people will make decisions and
its use peppers the technical literature to which software designers are exposed. Most such
literature is technical or tied to formal models in ways that are unlikely to serve architecture.
Here, we look at some of the perspectives that have evolved in the postmodern software world
since 1990 that relate to games and play.
We are starting to use Legos® as a tool that enables exploration and expression of
architectural alternatives in software. I have found two interesting learnings in this approach.
ARCHITECTURE AND THE CHILD WITHIN !17
One is the hesitation that people ﬁnd with the use of the tool. When I left boxes of Legos on
tables in a public seminar in Norway, in various stages of unpacking, people didn’t even touch
them without encouragement. In another instance I handed out a single Lego to each
member of an audience at a keynote address in the Netherlands; only a handful of people out
of 200 even tried to put their Lego piece together with that of their neighbour. This may be
an example where play can beneﬁt from facilitation. 
However, when players actually start to engage with the Legos, the results are thought-
provoking. The second major learning is that many teams ﬁnd ways to represent temporal
concerns in their Lego designs: i.e., to support dynamics instead of just statics. Such
behaviours and model-realisation techniques beg additional research.
Cockburn’s Cooperative Play and the Interplay of Games and Play
Alistair Cockburn popularised the notion of “software development as cooperative
gaming,” largely as a counter to software engineering. As early as 2004 he noted that as a
game, software development had become overly constrained. . He starts by taking a tack
that resonates well with game theory and the evaluation of options while considering an
optimal outcome. In his gaming model he focuses on ability, community, communication and
While there are aspects of play in Cockburn’s formulation, it still has many of the
trappings of a game. He writes:
Think of software development as a series of cooperative but resource-limited games of invention and
communication in which people use markers and props to remind, inspire and inform each other in getting
to the next move in the game. The primary goal of each game is the production and deployment of a
software system; the residue of the game is a set of markers to assist the players of the next game. Since the
next game is an alteration of the system or the creation of a neighboring system, each game has as a
secondary goal to create an advantageous position for the next game. Each game is resource-limited, which
means that the primary and secondary goals are in competition for resources. 
The primary focus is on product, though a careful reading of Cockburn shows a latent
honouring of process. Each game produces markers which are additional externally imposed
constraints on the next iteration of the game. It may be that for reasons of efﬁciency and
practicality, the game metaphor may work better in the overall framework of software
production, while play should be relegated to shorter intervals — in the sense that the Greek
workers took short intervals of play in their work.
This interplay of work and play can be tuned in many ways to provide powerful
combinations of creative design. Alternating playful interface design with the application of
ARCHITECTURE AND THE CHILD WITHIN !18
formal end-user productivity studies is likely to lead to a rapid convergence on a human
interface that makes the most people happy.
CRC Cards  are a longstanding object-oriented design technique based on team
role-play. They are a form of constrained, safe play, that explores object-oriented design
techniques. Though they produce a concrete result (candidate objects for a software system)
there are no termination criteria. CRC cards are rarely part of any corporate culture’s formal
design process so the “play” of CRC cards is almost always intrinsically motivated, albeit with
a more distant goal (delivery of the software) in mind.
Hohmann’s Serious Games
Luke Hohmann’s company, formerly called Innovation Games and now called
Conteneo, is founded on the notion that games solve problems through play. Hohmann bases
his game model on a model that aligns play with pleasure (see ﬁgure). (Interestingly, the
common Greek notion, especially as described by Aristotle, is that “play” almost always
meant “non-work”. ) In the work / play quadrant Hohmann believes that one can fuel the
innovative processes of problem-solving. He calls this “serious play,” but in a somewhat
different sense than the Greeks, who viewed public ofﬁce or military participation as an
adopted “play” role with dead serious social and life implications .
However, his notion of play rests squarely within the framework of the deﬁnition of
games as used here. He follows McGonigal’s  characterisation of games according to four
1. The outcome is to reach a stated goal
ARCHITECTURE AND THE CHILD WITHIN !19
Not Work Work
Internal Goals External Goals
2. There are arbitrary constraints
3. There are rules for interaction
4. Participation is voluntary
These perfectly ﬁt the “game” category of Table 1. Hohmann views the game
metaphor as being broadly applicable to any professional endeavour, but it is notably lacking
in the components of play we discussed above. In many respects Hohmann’s worldview is a
reﬂection of the broader agile software development community, with the exception of the
pattern community. Hohmann believes that game playing “gives permission to be fully
creative,” but such hope is at odds with Plato’s admonitions and with the very fact that some
aspects of creativity are blocked by the rules as “unsafe” or “out-of-bounds.” Games at best
support constrained creativity.
Much of Hohmann’s focus lies with gamiﬁcation: a kind of addiction based on associating
pleasure with some guided activity. Hohmann realises his game vision through tools, many of
which (such as “Buy a Feature”) that are often computer-facilitated, that implement ﬁnite
games in the sense deﬁned above. Some of the lower-level games, such as “Speed Boat” and
“Product Box” (which lack constraints and rules for interaction) are in fact not games at all,
even by his own deﬁnition. “Product Box” dilutes the notion of play with a stated objective
and product. While these games in themselves may not constitute play, they may be tools that
can support both game and play situations.
But in the end the goal of most Innovation Games is to exact conformance to some
social expectation, and these tools ﬁt squarely within the Greek formulation of games as
highly controlled tools of left-brain endeavours. It is difﬁcult to envision a framework that ﬁts
within the Innovation Games milieu that could serve the purpose of playful exploration of
George Platts’ PLoP games
George Platts is an art therapy consultant who uses play in professional settings to better
engage the non-analytical right brain in creative, innovative, and divergent thinking. George
had been inventing and using co-operative games in England and the Netherlands as a form
of patterns art and performance art in many many different contexts as early as 1977. He
appeared on the IT scene to do some work for IBM in Bristol in 1985. More to the point of
this article, George is a ﬁxture in the pattern community, with whom he has been working
since May 1993, that comes together to create bodies of literature in the vein of software
architecture and design.
ARCHITECTURE AND THE CHILD WITHIN !20
George calls his tools “games” but they fail to ﬁt the deﬁnition used here in many
respects. Few of them produce winners and losers. What is characteristic of many of George’s
games is their element of continuous engagement. Even in games where players take turns to
enact the “moves” according to some set of rules, the game structure is often set up to engage
all players in each “turn” or “move.” As such, these ﬁnite games give the feeling of inﬁnite
games. The games are hardly about exacting social conformance in Plato’s sense; exactly the
opposite is true.
George has created a culture of play at pattern events. Extrapolating from George’s
inspiration, the 2004 Viking PLoP® conference played a game that started by everyone in the
group thinking of a crisp, rich word in their head. The ﬁrst person in the circle started a story
by creating one sentence using that word. The next person had to continue the story using
their word, and so forth around the circle. The exercise created a story that was edited into a
poem and later published at OOPSLA.  The poem is a vision of computer / human
synthesis as technology might achieve over a protracted course of evolution.
Set-based design is a form of risk management practiced in the Toyota Production
System . It can be viewed as a form of play at the enterprise level. When choosing
between alternative design paths, Toyota charters several teams to pursue each of these paths
far enough to be able to compare the respective results.
This approach is game-like in its pursuit of a goal by several competing players, but is
play-like both in that the players engage as though the play were real, and in that there are no
externally imposed rules on the play itself — only on the production of a result.
Weinberg’s Simulations, and Games within Play
Gerry Weinberg has run a series of group simulations called VerseWorks. These
simulations have been carried out over the years at a series of seminars collectively called
Problem-Solving Leadership or PSL. These simulations start with a make-believe landscape
that includes a market and paying customer, a source of raw materials, a bank, and a set of
ﬁxed processes for procuring raw materials, a value proposition. There are humorous aspects
to the simulation in that the client is also the banker, the property inspector, the owner of the
town, and by happenstance, also the game facilitator.
Some aspects of the overall simulation process can be inferred from such constraints
that are made clear at the outset, but the process is largely free-running. It is a form of
ARCHITECTURE AND THE CHILD WITHIN !21
First, if this is a game, it is a simulation of an inﬁnite game. The game end is deﬁned by
a time box rather than any condition or benchmark.
Second, there is an interesting layering of game and play “layers” in the simulation. At
the lowest level we ﬁnd games with rules for the production of raw materials. At the high end
of the game we ﬁnd rules that constrain the form of the delivered product, and for assessing
the value of the product. A truly chaotic process ensues within these boundary conditions.
As a game, the activity produces product increments. However, the purpose of the
exercise is much more a focus on process than on product, which we noted earlier is a
characteristic of play rather than games. And the activity is carried out as though it is real.
The environment produces stress to that point that it is not uncommon for people to break
down during the exercise, for which reason there are always trained psychological
professionals at hand. Like children’s play at home, it is constructed to be carried out in a
(psychologically) safe environment.
Weinberg ups the ante and confuses the play / game issue in the game debrieﬁng. The
game includes an economic system, whereby the players beneﬁt ﬁnancially from selling their
product to the client. I remember that when I played the game, we ended with a ﬁnancial
deﬁcit and owed the bank money. The players shrugged their shoulders and were resigned to
losing money in what, after all, was just a game. At that point Weinberg raised his eyebrows
and asked, “Oh, was it?” and pulled a thick stack of $100 bills from his pocket. (The tradition
is that teams that earn a proﬁt from the activity donate it to charity.)
I would wager that few players have fully explored the rules for changing the rules of
If further constrained by the desiderata of some market, Weinberg’s PSL game might
be an ideal framework for software architecture. On the other hand, the game could also be
run with a different starting point that entailed the players coming up with the deﬁnition of
the product they aspired to build; that is more in the spirit of the model espoused in
contemporary lean startup thinking. 
Alternating Repetition of Game and Play
As the Greek sophists gained footing from the dialecticians in Greek culture, those who
thought in the same vein as Plato were horriﬁed. Playing with words and concepts of morality
became the core of political endeavour, and the young afﬂuents of the scholē culture turned to
play to advance their careers. Blame was laid at sophistry’s playful feet for numerous social
and military disasters. Yet, in the fourth century BC the military writer Xenophon was able
ARCHITECTURE AND THE CHILD WITHIN !22
more clearly to express a balanced view. In his Symposium he writes, “I believe that it is not
only the serious actions of distinguished men which are of interest, but also those done in
Software tradition has followed the gaming model much more closely than that of play.
While the main purpose of this thought piece is to stimulate thinking about play, there is still a
place for games.
With respect to architecture, the use of a framework is much more game-like than play-
like. If the game is well-designed, and anticipates business needs well, then a game approach
serves the business goals. It is rare that a game designed by one set of people will satisfy the
needs of a separate set of players. So, for example, a group using a framework should have
been the one to have itself built the framework — probably in a play-like setting. The
framework complete, the same players can use it as the basis of a game or even a method for
the generation of product.
Within each episode of product generation, it’s likely that the players will develop
artefacts to plug into the framework. That again may constitute bounded play, with the
bounds set by the framework invariants. There is still free play within the unforeseen business
parameters of the system extension as the players explore the market and engage end users in
the game. Those end users may in turn be constrained by the own rules of their own games,
which themselves become extensions of the current game.
Paul Chisholm describes a process he calls disposable analysis. It starts as a game to
produce an analysis or design document. All players contribute to the document under a
rigorous set of formatting guidelines, perhaps further constrained by business desiderata.
After the game ends (the document is pronounced “done”) the document is discarded and the
players proceed in a playful way with the construction of the system itself. This is a form of
tacitly bounded play that allows the players to adapt or even change the rules, but always in
tune with a conscience that was informed by the joint journey of exploration.
Scrum Knowsy is an iTunes product that is in many ways a traditional game that can
accommodate multiple players and which has rules that produce a ranking of winners..
However, the whole game is ensconced in a context of play. At the base-most level of play,
each player tries to guess the value system of a designated celebrity, and scoring reﬂects the
accuracy of the guesses. The game informs the players of the celebrity’s rationale for their
own value ranking; the player may agree or disagree with such a rationale. At the next level
of the game we ﬁnd that there are multiple celebrities, and that their opinions don’t align.
ARCHITECTURE AND THE CHILD WITHIN !23
The point is that there is no single “winning position,” and that the outcome of a Scrum team
in real life depends on the context of business need and team talent. Given this background,
the players can ascend to a third level of true play, which is the discussion fuelled by both the
information and controversy that arose at the second level.
There is almost always play within games. That is, there are almost always occasions
where the mechanical aspects of the game became almost entirely diminished and aspects of
play take over. In the end there are always enough constraints at the end of the episode to be
able to produce a real product. A project can decrease risk by pulling ramiﬁcation earlier and
earlier in the process, and can increase creativity and innovation by deferring constraints as
long as possible. One powerful way to increase feedback, particularly in complex settings, is to
introduce alternating layers of games and play as found in some of the examples above.
The balance between risk and play and architecture is most strongly modulated by
maturity of the technology, of the market, and of the players. There are no rules or formula
here, but the game / play model serves as a powerful metaphor to unleash creativity and
innovation in a development process.
Play can be bounded in a game-like way by a facilitator. Research has shown that
facilitated play is more skilled than unsupervised play.
The adult trainer followed a child’s lead in the story but also praised the child,
modeled actions, and asked questions. Russ, Moore, and Farber controlled for adult
interaction in the control group as well. This study concluded that the play
interventions effectively improved play skills on the APS. Also — and importantly —
when it came to divergent thinking, the study found play exerted signiﬁcant group
Facilitators can encourage, role-play, and challenge the players to explore otherwise
unexplored areas. They can help the players keep an eye on, for example, both classes and
objects instead of being overly distracted by a single perspective.
Plato formally viewed adult play as childish, and Aristotle established a dichotomy
between play and work that would stand for two millennia. These two perspectives together
don’t bode well for play in professional endeavours. However, Greek theatre likely started with
playful music sung extemporaneously as part of symposia. Theatre would become more
game-like in its performance (while retaining the sense of leisure for the audience) but the
music would give way to another powerful form of play in symposia: word play, puns, and
ARCHITECTURE AND THE CHILD WITHIN !24
playful exploration of morality. Still, Aristophanes (Clouds) viewed comedy as a form of
instruction . And, as Xenophon noted above, there may be a more informed view that
combines play, work, and leisure.
Theatre offers an interesting hybrid between play and game. The intellectual Greek
audiences would certainly have viewed it as an activity of learning (scholē), as Aristotle saw
both tragedy and comedy as commentaries on the human condition. However, there is room
for expression and even improvisation within theatre itself, and such variants are a form of
play. Brenda Laurel’s Computers as Theatre  takes this metaphor into the design world,
where we are challenged to engage end users and apply their mental models in our design
The evolution in Greek culture from playful entertainment to theatre begs the question
of whether games are, by analogy, an evolved form of speciﬁc repetitive play: a cultural
artefact to encode, celebrate and remember key cultural rules. This is a potentially fruitful
area for future exploration and summary. It is likely that playfulness will nonetheless survive as
a cultural artefact in any culture, no matter how mature, perhaps because such is the nature
of homo ludens.
Theatre is also about time, and timing. “間” is a central feature of Japanese kabuki:
immaculately timed pauses that arise for speciﬁc conﬁguration of players on the stage.
Games have a long history in human endeavour, particularly in their role to constrain
behaviour towards an outcome called “winning.” As computing has borrowed from the game
culture we ﬁnd room for a somewhat more playful approach to design. Some games, such as
methods, over-constrain fruitful design paths and stiﬂe creative juices. Yet others, while well-
intentioned, suffer from faults such as ﬁnitude of play (as in big up-front architecture) or
overly constrained outcomes (CRC cards as a design game force one into object-think when
other paradigms may be more suitable). Bounded play offers an opportunity to realise the
kinds of improvements in exploring the problem and design space, in unleashing, creativity
and in multiplying the number of possible ideas. Time elements are crucial to play as well as
to real-life activities, and play appears to excel over game-based approaches in the treatment
of time. DCI as a design regimen formalises this representation of time in its computational
model, in a way that allows children of all ages to play with the temporal notions of system
form. A game-based approach can be interleaved with loosely bounded and explorative play
ARCHITECTURE AND THE CHILD WITHIN !25
to help architecture converge on periodic plateaus that can serve as concrete foundations for
development. It is thus that homo ludens shapes the world.
Many thanks to Alistair Cockburn for comments and suggestions.
 D’Angour, Armand. Plato and Play: Taking Education Seriously in Ancient Greece.
American Journal of Play 5(3), Spring 2013, 293 - 307.
 “Active Gaming: The Future of Play?” American Journal of Play, volume 4, number 4.
 Carse, James. Finite and Inﬁnite Games. Ballantine Books, 1987.
 Kay, Alan C. A Personal Computer for Children of All Ages. Draft hand-dated August
 Reenskaug, Trygve, P. Wold and O. A. Lehne. Working with objects: The OOram
software engineering method. Greenwich: Manning Publications, 1995.
 James O. Coplien and Gertrud Bjørnvig. Lean Architecture for Agile Software
Development. Wiley: 2011.
 Apple Dictionary Version 2.2.1 (156).
 Cockburn, Alistair. The End of Software Engineering and the Start of Economic-
Cooperative Gaming. Computer Science and Information Systems Journal, Comsis Consortium,
University of Belgrade and Montenegro 1(1), February 2004, 1-32.
 Dansky, Jeffrey L. 1980. “Make-Believe: A Mediator of the Relationship between Play and
Associative Fluency.” Child Development 51:576–79.
 Dansky, Jeffrey L., and Irwin William Silverman. 1973. “Effects of Play on Associative
Fluency in Preschool-Aged Children.” Developmental Psychology 9:38–43.
 Russ, Sandra W., and Claire E. Wallace. Pretend Play and Creative Process. American
Journal of Play 6(1), Fall 2013.
 Coplien, James, et al. Breakthrough Ideas (Poem: ``Comfortable as Blue Jeans''). In
James O. Coplien et al., OOPSLA '05: Companion to the 20th annual ACM SIGPLAN
conference on Object-oriented programming, systems, languages, and applications, San
Diego, California, USA. New York: ACM Press, 2005, pp. 76-86.
 Alexander, Christopher. Notes on the Synthesis of Form. Oxford University Press, 1974
(Paperback edition), preface.
ARCHITECTURE AND THE CHILD WITHIN !26
 Kasari, Connie, Stephanny Freeman, and Tanya Paparella. 2006. “Joint Attention and
Symbolic Play in Young Children with Autism: A Randomized Controlled Intervention
Study.” The Journal of Child Psychology and Psychiatry 47:611–20.
 Snowden, D. (2000). "Cyneﬁn, A Sense of Time and Place: an Ecological Approach to
Sense Making and Learning in Formal and Informal Communities" conference
proceedings of KMAC at the University of Aston, July 2000 and Snowden, D. (2000)
"The social ecology of knowledge management". In Knowledge Horizons : The Present
and the Promise of Knowledge Management ed. C Despres & D Chauvel Butterworth
Heinemann October 2000.
 Beck, Kent. A laboratory for teaching object-oriented thinking. SIGPLAN Notices
24(10), October 1989.
 Floyd, Christiane, Heinz Züllighoven et al. Software Development and Reality
Construction. Springer, 1992.
 Ries, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation
to Create Radically Successful Businesses. Crown Business, 2011.
 Laurel, Brenda. Computers as Theatre. Addison-Wesley: 1991.
 Alfred L. Kroeber. Anthropology: Culture Patterns & Processes (1963). New York:
Harcourt, Brace & World.
 Personal interview with Jerry Weinberg, 31 May, 1999.
 Weist, R. M. (2009). Children think and talk about time and space. In P. Łobacz, P.
Nowak, & W. Zabrocki (Eds.) Language, science and culture. Poznań: Wydawnictwo
 Ala Samarapungaven et al. (1996) Mental Models of the Earth, Sun and Moon: Indian
Children’s Cosmologies. Cognitive Development 01/1996.
 Ole-Johan Dahl, Bjørn Myhrhaug and Kristen Nygaard. SIMULA 67: common base
language. Oslo: Norsk Regnesentral, 1968. (Publication S / Norwegian Computing
Center; 2) Rev. 1970: Common base language (Publ.; 22).
 Marcus Vitruvius Pollo. The ten books of architecture, trans. Morris Morgan. New York:
Dover, 1960, p. 5.
 Christopher Alexander. The Timeless Way of Building. Oxford University Press, 1979.
 Piaget, J. (1952). The origin of intelligence in children. New York: Norton.
ARCHITECTURE AND THE CHILD WITHIN !27
 Brown, P. (2001). Learning to talk about motion UP and DOWN in Tzeltal: Is there a
language-speciﬁc bias for verb learning? In M. Bowerman & S. C. Levinson (Eds.).
Language acquisition and conceptual development (pp. 512 – 543). Cambridge, UK:
Cambridge University Press.
 Piaget, Jean.  1967. Play, Dreams, and Imitation in Childhood.
 Hall. Dance of Life. Peter Smith Publications, 1996.
 Jeffrey Liker. The Toyota Way: 14 Management Principles from the World's Greatest
Manufacturer. McGraw-Hill, 2004.
 Yukihiro Matsumoto. Lessons Learned from Ruby. Rakuten Technology Conference,
Tokyo, Japan, 25 October 2014.
 Sigmund Freud. “Creative Writers and Day Dreaming”, 1907.
 Stella Vosniadou. Mental Models in Conceptual Development. Model-Based Reasoning
2002, pp 353-368.
 Attention, perception & psychophysics. 2013 Feb;75(2):375-82. doi: 10.3758/
 Johan Huizinga. Homo Ludens (1938). Beacon Press, 1971.
ARCHITECTURE AND THE CHILD WITHIN !28