This past week I was attending ASE 2006in Tokyo and presenting a paper at the KSCD 06 workshop on Knowledge Collaboration in Software Development. The workshop brought together researchers from several backgrounds that have an interest in how knowledge about software systems gets transferred between individual developers and organisations, the impact and costs of knowledge transfer on an organisation, existing practices for knowledge transfer and new techniques and technologies that can be applied to the problem.
Due to the scope of the problem being discussed it was really interesting to see how researchers from different research backgrounds choose to approach the problem’s description. While the social and collaborative software guys described the problem in terms of a group of actors, shared knowledge, workspaces and communications channels, the software understanding people (me included) were more focused on the individual software engineer’s role in the communication and transfer of knowledge.
While each group have models that explain the particular scope they are interested in, apparent from the discussion was that these models are currently not explicitly interlinked. Investigation of this boundary between individual and group understanding behaviour will I suggest be a potentially signification aspect of future research in the knowledge collaboration field.
Also of interest were the different artefacts and techniques used to both study and attack the knowledge collaboration problem. During the discussion two main approaches were identified; explicitly eliciting information from engineers that relates to the knowledge collaboration problem and derive information from artefacts that are created as a normal part of the software engineers work practices.
While the latter approach from a engineering perspective seems a little lightweight and unsatisfying in that, you attempt to study and solve the problem relying only on what artefacts already exist rather than creating new artefacts that explicitly elicit all the required information to study and solve the problem, it is likely the most tractable.
When it comes to the introduction of any new software engineering practice or tool, its success is directly related to a mostly informal cost benefit analysis performed by the software engineers that will implement the practice or use the tool. If engineers cannot see the benefit in using the newest silver bullet it simply will not get used, that is, of course unless its mandated by the organisation a situation which will likely engender dislike in the engineers forced to use something they cannot see any benefit in. Timothey Lethbridge and some of his students in the late 90’s did some work on tool adoption in software engineering organisations and to my knowledge this research remains the state of the art.
My opinion (based solely on informal observation) is that unless someone is liable to suffer serious consequences for not doing something then they are not likely to do it unless they really see a personal benefit in doing so. This model tends to explain the run away success of things like j-unit, automated refactoring and eclipse. In very few organisations did these technologies and techniques get mandated by organisations for use by their engineers, rather the engineers just started using the techniques (in some cases almost subversively) because they in their own informal cost benefit analysis saw the great benefit to their work. They then did a remarkable thing; they went and re-sold these ideas within their organisations. Sure none of these ideas were very new they had been knocking around for quite a while and yes there were some very big names publishing books on these topics but fundamentally in my experience the current and on-going success of these techniques relies on individual engineers finding and pushing their organisations to adopt them.
In terms of this analysis if we are to solve the knowledge collaboration problem then we will need to either; create technologies and techniques that can pass the informal cost benefit analysis of software engineers or make somebody within a project or organisation professionally responsible for “implementing” knowledge collaboration. Ideally we would like software engineers to see the benefit in facilitating knowledge transfer, however just like other specialisations within software engineering (testing, design, architecture, maintenance, etc) the time might have come to bite the bullet and start allocating resources and budgets. Ultimately if something doesn’t have a budget, it doesn’t exist.