Developer Summit 2012 in Kansai

The DeveloperSummit was a free one day conference (in Japanese) for developers held in Kobe, Japan.  It is nice to see more of these events taking place in Kansai rather than just in Tokyo. This event was very popular with several of the sessions being completely full.

The keynote presentation was from Oikawa Takuya, one of the Japanese developers on the Google Chrome team. The main theme was the changes in project management style required when developing for “the cloud.” Out is the old style product lifecycle with releases every few years and in is the “versionless” development with very frequent or “continuous” releases.  Also, the use of open source and the challenges that brings to development when contributions from many people must be integrated. This was an interesting presentation giving some insight into the how Google develops some of its software and Chrome in particular.

The first presentation on the “Agile” track was from a Microsoft evangelist entitled “Continuous value delivery to the next decade.”  This presentation also discussed the differences between waterfall and agile development and how development is done at Microsoft. However, the whole presentation seemed like an advert for TFS. The main point seemed to be the advantages of using a single tool for project management, bug tracking version control etc rather than several different tools. And Microsoft just happens to have such a tool. This seemed to me like agile for those who want to say they are doing agile but don’t want to change too much. The process seemed to be more like a series of mini-waterfalls backed up by comprehensive tools.

Following the Google and Microsoft promotions we had an advertising spot for JIRA (the bug tracking system from Atlassian) given by Suzuki Yusuke, an engineer from Growth xPartners which seems to be an Atlassian partner in Japan. This was less a less subtle promotion since the presenter even included a price list for JIRA in one of the slides. After yet another description of waterfall and agile processes (the third so far) the presenter stressed the importance of collaboration and communication in Agile development.  I would not argue with that, but I am sure that there is more to communication than a bug tracking system. The middle part of the presentation described how “Agile is implemented in the bug tracking system.” The idea seems to be to use JIRA to hold the list of tasks to be done and to act as the communication medium for the team.

We use JIRA as a bug tracking system and it seems to be one of the best bug trackers available. However, I often see it as blocking rather than enabling communication. Instead of direct communication between individuals, communication is via comments on an issue. This leads to misunderstandings and delays. Also because it is so easy to create an issue the “backlog” quickly becomes an unmanageable black hole into which requests and improvement suggestions are sent to be forgotten.

I suppose that not surprisingly, from a company selling the bug tracker there was no suggestion that the use of a bug tracker is itself actually a symptom of a bigger problem.  A truly agile team would probably have no use for a bug tracker.

The presentation that I was most looking forward to was that by Wachi Yukei on “The evolution of test driven development.” He is one of the translators of “GrowingObject Oriented Software Guided by Tests”, the Japanese version of which was just released on the same day as the developer summit. This presentation gave an overview of GOOS. The description of Mocks was fairly hard to follow and my Japanese colleagues who were not familiar with mocks did not seem to understand it at all.  Actually the biggest problem seemed to be the direct transliteration of English expressions into Japanese, such as “walking skeleton.” This is not a problem for me as an English speaker – in fact it makes it easier – but makes it hard for non-English speakers to understand. However, the presentation did include a lot of good stuff from GOOS such as the need for end-to-end tests and thin slices of functionality. I am not quite sure on the relevance of the photo of David Cameron.

Many of the presentations are on SlideShare (in Japanese)

Continuous value delivery to the next decade:

http://www.slideshare.net/tomohn/a1-continuous-value-delivery-to-the-next-decade

Collaboration in enterprise development – how to connect the development team with customers using JIRA

http://www.slideshare.net/yusuke/2012a2

The evolution of test driven development

http://www.slideshare.net/digitalsoul0124/ss-14351848

Visual Studio 2012 breaks VS2010

StackOverflow just rescued me again from yet another Microsoft problem. It seems if you try to install Visual Studio 2012 when you already have a Visual Studio 2010 installation then the 2010 installation gets broken.

Fortunately MS have released a SP to 2010 which fixes the problem. But it should not happen in the first place. Unless you do everything on a virtual machine when you try a new program like VS2012 you will want to keep your existing environment working. Did they not test installing VS2012 onto a machine with VS2010? I can't believe that they did not, which means that they must not care about breaking existing environments.  There was no warning message that it would happen and the Update for 2010 was only available after installing 2012.

The knowledge jigsaw

Most of my colleagues don’t  read books.  They are software developers in desparate need of improving their skills yet they try to get by with muddling through with what they already know or relying on the boss to provide the information they need. This has puzzled and frustrated me for some time. If they were using some other means to learn – blogs, personal contacts, seminars then I could understand but they don’t do that either. Yet when I talk to them they all profess to wanting to improve their skills and knowledge.

One common aspect that came up in conversations is that they seem to expect a book to be both directly relevant to them and to answer whatever specific problem they are having at the moment.  Of course, this is rarely the case. When they read one book, do not understand the context and can’t apply whatever the book describes directly they dismiss it as not relevant and a waste of time. This then puts them off technical books in general.

To try and explain why they should read I now use the metaphor of a jigsaw puzzle. Reading an article or book is like picking up a single piece of the puzzle. Sometimes you  can see something recognizable on the piece and see how it fits. More often the picture on the piece only makes sense when it is seen in the context of the surrounding pieces.

To understand most technical books you need to understand the context. You get the context through experience and through reading widely.