Monthly Archives: September 2006

Tokyo Day 2

Some more shots from Tokyo mainly from the Imperial Gardens and also some from the 43rd floor of the Federal Government buildings in Shinjuku. Note if you are going to Tokyo you might be tempted to pay to go up the Tokyo Tower to get a view of the city, in my view this is a waste of money. The Federal Government building in Shinjuku has two observation decks that are free to the public and in my opinion give a more interesting view of the city. The Tokyo tower is epically not worth it if your looking for night shots of the city as 1 its not in a very interesting part of the city and 2 the internal lights in the tower really interfere with night time shots. In its favour is that the tower is not surrounded by any other tall buildings and so your view of Tokyo is not obstructed, however this also means that the tower is in a really out of the way part of the city and is not that accessible.

Tokyo Imperial Gardens

Tokyo Day 1

Some of the first shots with my new camera, I wanted to go into the Imperial gardens but they were closed so I took some shots from the outside. Also in this album are some shots from Ginza of the Sony building and then some evening and night time shots from the Tokyo Tower (see my note in the next post about the Tower).

Shinjuku

Tokyo to Shannon

6086 miles

120 minutes queuing

22 inches of legroom

13 hours flying

8 passport checks

4 in-flight movies

3 x-ray machines

2 continents

1 magazine

 

Having to pack several bags of Tokyo duty free that were perfectly ok to bring on board in Narita into a single laptop bag to get through Heathrow security…. Priceless.

ASE2006

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.

%d bloggers like this: