For two reasons I was recently very pleased to discover the brilliant Epistemological Pluralism, an article by Sherry Turkle and Seymour Papert (what a team!) from 1994. Firstly, they add weight to my use of 'hard' and 'soft' in reference to technologies, with a slightly different application but very similar intent and meaning - this will definitely make an appearance in my writings on the subject. Secondly, and more relevant to my current needs, the article is a spirited defence of how and why I write software and helps to make sense of the methods I am using during my sabbatical to perform research.

Turkle & Papert's main point is a little tangential to the value I got out of the article, that there are gendered tendencies in software building: the dominant 'male' model of hierarchically organized, structured, hard engineering, and the generally denigrated 'female' (and, in the opinion of the originator of the term in this kind of context, Levi-Strauss, more primitive) soft, exploratory model of bricolage - treating programming languages almost as sculpture, chipping away at the overall shape from the bottom up and assembling bits and pieces until it comes out right. Turkle & Papert provide some fairly compelling evidence that the harder engineering tendency is much stronger in male students while the softer bricolage tendency is much stronger in female students. This is unfortunate and perhaps accounts for some of the extreme gender bias in the programming community. The bricolage approach is thoroughly discouraged and indeed denigrated by most teachers of programming and, as Turkle & Papert observe, those who adopt it are made to feel a little ashamed, not quite capable, not quite grown up. Small surprise, then, that women tend to be dissuaded from joining the programming community, especially via an academic route. This is a highly gendered and, if (as they and I assert) it is not defensible, it is a rather unsavoury attitude. Turkle & Papert point out that the bricolage approach, while (I think very arguably) unsuited to large team development and generally not leading to what is conventionally seen as efficient code, allows developers to create narratives and expressive structures that creatively reflect their world view and that can have great validity and value. For instance, they give the example of a kid who wanted to program the drawing of a skeleton who, rather than designing an efficient set of loops and procedures (which he knew how to do perfectly well) deliberately chose to write steps in long form, because it more effectively expressed his understanding of the skeleton - "It makes you decide how to divide up the body, and perhaps you would change your mind about what goes together with what. Like, I would rather think about the two hands together instead of each hand with the arms." It is a different way of programming, using it as what Papert has called a mind tool, but it is not necessarily worse than the hard engineering approach, at least in some settings. Harder to maintain in some ways, sure, and possibly not what you would want to have controlling your life support system or managing the engine of your car, but more expressive, more creative and, to my mind, more interesting across a wider range of applications. This is not just about the end product: there is immense value in the sense-making process of building software. It is a way of thinking, exploring a problem space, discovering new ways of seeing and being, communicating with others. And it can lead to different kinds of end product.

The reason for my scepticism about bricolage being unsuitable for large team development is that the object oriented approach, mentioned by Turkle & Papert but relatively novel and not too widely used at the time, has developed and matured considerably since 1994. It has gone in two directions, one towards engineering, with contracts and formal unit tests embedded in and surrounding objects to ensure their clean and bug-free (ish) operation, the other towards much looser components and services that break a lot of the 'rules', mixing procedural and functional designs with purer object-oriented ones. I am a fan of the latter, favouring languages like PHP and JavaScript that are inherently messy, fallible and ad hoc in design over those that demand a more rigorous and hard approach, because they make it easier to play, to tinker, to make leaps of the imagination.  Neither is the is the be-all and end-all of programming. On the whole (with exceptions) I would prefer to travel across a bridge designed by an engineer rather than assembled by a bricoleur. On the other hand (with exceptions) I think I would mostly prefer clothes designed by bricoleurs than those designed by engineers. Ideally the right kinds of people should be involved at the right level at the right time in the right place whatever the design and, for the most part, a hybrid approach is desirable.

Significantly, the bricolage approach fits well with a component- and service- driven architecture of the sort found in Elgg, the PHP-based framework behind the Landing. The Landing has been shaped, nudged and cajoled into its current form through assembly of many pieces, some of which we have made, many of which we have re-used. It is not designed like a bridge. It is a patchwork, a bricolage sewn together from pieces. It is a good thing that some of the most crucial of these come mostly from people who build software following an engineering tradition. It is likely to remain standing because its foundations and skeleton are strong in the right places, but it has a lot of flexibility because it is, in its very bones, built for bricolage. Elgg is not a social networking system like Wordpress, nor a content management system like Drupal. It is a very tiny core framework that does almost nothing in itself apart from offering a scaffold for plugins. I'm increasingly thinking that the bundle of plugins it comes with might be a mistake because nearly everyone installs them and so people tend to think of Elgg as this set of plugins (plus customizations) rather than the incredibly flexible tight core itself. I know we did. It's the easy way to start - with things like blogs, groups, wikis, bookmarks, messaging and other basic tools ready to go out of the box, each a bundled plugin. Unfortunately this creates a massive set of path dependencies that tend to drive Elgg development in a particular set of directions. Among these is the crippling tendency to think in terms of tools (blogs, wikis, groups, bookmarks, etc) rather than what we actually want to do (create, share, communicate, connect, organize, etc). In effect, we inadvertently hardened a model of social software as a toolset into the Landing that, had we started in a different place, we almost certainly would have avoided. Now, with many tens of thousands of posts as well as habits and mental models people have developed about the site, it is hard to turn that around.  So, what can be done about it? Basically, tinkering. Bricolage. During my sabbatical I have been playing with a set of ideas and sculpting what we already have, trying to find ways to nudge the Landing in directions that, had we known what we know now, we would have gone in the first place. It's a slow process, one that demands that we keep what we already have and build on it and around it. And it is a process that is firmly embedded in the software community, the one that tends to lead to creeping featurism. Indeed, as Brian Arthur demonstrates rather wonderfully in his book 'The nature of technology' it is how all technology evolves. On the one hand, features are cool and there can never be too many of them - nearly all software is frustrating when you reach its limits. On the other, creeping features tend, most of the time, to result in something bloated, ugly, buggy and unusable. Among the tasks I have set myself is to try to find a way around this tension.

I was reading the article by Turkle & Papert because I am trying to develop a research methodology based around exploration of the adjacent possible through programming. This is not exactly design-based research in its traditional sense - it is more bricolage-based research. The idea emerges from my thoughts on soft and hard technologies, the way that technologies evolve and the nature of invention and innovation. Specifically, I am intrigued by the nature of bricolage as a process of exploring and shifting the adjacent possible. Design-based research is always an adventure into the unknown but bricolage-based research has some very distinctive features compared with its close cousin, at least in how it is popularly imagined - in real life I think all invention and design has elements of bricolage. Bricolage-based research is always bounded, grounded in what we already know and have already created, always a process of assembly and connection rather than intentional creation in a supposed vacuum and, above all,  the objects that we create play a massive guiding role in determining their own evolution as we create them. As we build we not only enter the adjacent possible but we build path dependencies and foundations that change what we thereafter create. This is a research process: by it's nature, it is a process of discovering something new. It is not creation out of nothing, not even creation out of what we have pre-formed in our heads. It is an intricate dance between what we know, what we aspire to, the objects and technologies we are able to assemble, and those objects we assemble themselves. A theory of design that ignores the designed object and its prior components makes no sense at all. We must see them as active players in the process, perhaps more important than our own thinking processes that led to them. They are thought made concrete and, once created, they fight to stay alive (and usually win).

Action research, design-based research (DBR), soft systems methodology (SSM) and other related methodologies provide a good foundation for thinking about this as a research process and point in something like the right direction, but don't quite capture the complex iterative and embodied nature of creation itself, as opposed to iterative evaluations we make of our creations. They suggest how we should methodically create new things and learn from each cycle of creation, but have relatively little to say about the nature of that creation process itself (though SSM is further down the path and more open to such things). So I spent some while investigating research methodologies used in the creative arts and crafts, which seemed archetypally the kind of thing I was looking for. This was extremely interesting but, again, did not quite get at what I wanted because the focus was on creative process as an object of study, sometimes with created artefacts acting as research outputs in and of themselves, as expressions of individual creativity (or, as some authors would have it, jealousy). It's fascinating and relevant, but I am interested in artefacts that do something, not that are something: not in proving that they do something better, not in evaluating their effectiveness, but as steps on the journey into the unknown that reveal more of the path. As Turkle & Papert put it (their italics) "The computer is an expressive medium that different people can make their own in their own way." but, as they also acknowledge, it is also a tool that makes things happen. Most of the programs I am interested in creating, the Landing being a prime example, are deferred systems, as Patel puts it. That is, they are full of latent possibilities that open opportunities to design other things (groups, content, social networks, etc) and are thus incomplete, waiting for a human or humans to complete them complete-able in myriad ways.  I am interested in capturing that process and making it into something that can claim academic rigour of some kind. Definitely not science, definitely not art, probably not social science - something else. I've been a little drawn to variants of Actor Network Theory and associated methodologies for creating rich pictures of the complexity of socio-technological systems that recognizes the significance of created objects but, again, this is mostly beyond the process, a means of understanding the effects of the process and the interplay of things within a system, not a means of understanding the process itself. Activity Theory pays more heed to the process and includes designed objects in the ways it models systems, but at such an abstract level it has little value here.

In broad terms, I am trying to model the process as an interplay between the hard and the soft. Hard technologies have orchestration embedded in them and play a strongly deterministic role, demanding that we follow or automating processes within them. Soft technologies are those that we orchestrate as we use, create and assemble other technologies. They are creative, flexible, indeterminate, ever shifting. The more parcellated and assemblable are the hard technologies we use, the more they can be a part of softer technologies but, as they become ever softer, they become ever more difficult to assemble. This tension is played out every time we engage in software design. We harden things in code, or make use of libraries, functions and processes hardened into code, and then need to tinker as bricoleurs to soften them again as they suggest or demand new possibilities. When we run into obstacles, it is largely because we have hit something hard that needs to be softened before it becomes hard again, in a never ending cycle of dialogue between the designed object and the designer.

If this all sounds very fuzzy it is because it is. I do not have a good vocabulary to describe this yet and am not even sure what it will look like when I find it. It is a little too easy to be pulled in conventional directions - this could easily become a bit of philosophy or even psychology, but I don't think that is what I want. What I am seeking is both a way to legitimize tinkering as a valid research method and a methodology that allows us to extract more meaning from the process so that it can be usefully understood and perhaps reused by others. More usefully, I want to uncover ways that we might use bricolage more effectively, to build systems that are malleable and supportive of creativity but that are, at the same time, efficient, usable and reliable.