On Friday, 17 October, it was that time of the year again. I had skipped the event for the last two years, this year I wanted to spend three exciting and inspiring days in Leipzig at the Developer Open Space 2014. Unfortunately, I was not able to attend Friday’s workshops. After nearly six hours travelling by car combined with a busy workday before, I fell into my hotel bed pretty much immediately and pretty much exhausted. But the following Saturday, I was up early as a bird and ready to attend the session planning.
Torsten Weber, co-organizer of the Open Space, pointed out in advance that there would be many newcomers this year. I was hoping this might bring new ideas and a breeze of fresh air. Others feared that old topics might come up again. Although that did not seem to be an issue, the session planning was a bit chewy this year.
Altogether, mainly subjects from the field of development were presented. Creative techniques, Docker as well as rights and obligations of freelancers where some of the topics. Technical issues such as wearables and smarthome, sensors for autonomous robots and kinect 2.0 were also represented. Development itself was a subject in the introduction of Angular JS, Haskell or the Rails Disco. I myself held a session presenting XamlBoard – Centigrade’s tool for managing Xaml resources. A complete overview of all topics can be found here.
Since my last visit the .NET Open Space war renamed Developer Open Space to take into account the variety of topics besides .NET. The aim of a technology-independent “Unconference” was definitely achieved this year: A little shy and aware of the crowd, a guy came forward and revealed himself as a Java developer. He was accepted into the family – unlike Frank, who asked for help with WCF performance problems and raised a big laugh. Nevertheless, Frank’s problem was discussed in an own session. The following sections show my impressions of the sessions I visited.
Switching from TFS to Git
The first session “Switching from TFS to Git” started with the usual delay. Thomas spoke about the problems with using TFS and his wish to switch to Git. The major part of his team, however, seems to be satisfied with the current situation and he only got one ally. He asked for tips how he could at least convince his team to have a look at the alternative. Personally, I found it shocking to hear that some developers still wait for up to three months before checking in because they fear conflicts. Thomas got the feedback to replace the access to the source code control through Git-TF or git-tfs at first and try to build up a community that can implement their workflow more efficient.
Scrum: From the group to the team
During the session planning, Ralph pointed out his problems in forming a team from a group and his wish for exchanging experiences. In Ralph’s team, internal as well as communicative and helpful external employees are working together. But despite developing side by side, no cooperation was taking place. One explanation given for the situation was subgroups preparing tasks together with external employees but without letting the whole team know. As a result, they gathered the domain knowledge that the others relied on. It became clear that the group used Scrum-But instead of Scrum, which means leaving out important parts of the process: Grooming would be sufficient, sprint planning would become unnecessary. Since the goals were achieved somehow, nothing escalated and there was no obvious need for action. But there was no joint commitment, either.
Among other things, the community suggested to design stories as puncture and present the result as a team, focusing on pair programming und using Coding Dojos.
Negotiating and de-escalating
Lars started his session by indicating that we are constantly negotiating in our lives. Even the simple question “What are we doing this afternoon?” can lead to a negotiation with your partner. Here, it is important to look for win-win situations. The following attitude can be very counterproductive: “If we do not go to the movies, I have absolutely no desire in doing anything,”. It does not address the position of the negotiating partner. In these situations it may help to seperate people from their interests. Also, one should focus on people’s interests, and not on their current positions. If possible, appropriate choices should first be developed to facilitate the search for compromises. A good compromise includes maintaining the good relationship and letting both sides win. Dirty Tricks need to be addressed immediately during the negotiations. The parties should also not be put under pressure, and interrupt the proceedings if necessary. Dodge incoming personal attacks, and most importantly: Always acknowledge and carefully watch the opposite position. Unfortunately, time went by quickly while discussing the Getting To Yes (“the Harvard concept” in German) and de-escalating came up short.
Creative techniques
After a brief introduction by Lars, Torsten presented some creative techniques. Among others, these include brainstorming where it is important to first throw everything in the room and then filter the results. Sometimes the headstand method can help by simply reversing the question. Thus, the question “Which cool feature can we implement?” might be changed into “Do we really need so many functions?”. Based on such examples, Torsten described successful teams, where three roles can normally be found: (a) a creator who loves to try new things and is always up-to-date regarding the newest technology. (b) An owner who guides the zest and the information overload of the creator and restrains technology diversity. And (c) a broker who knows what information can be found where.
Heterogeneous Computing
Unfortunately, I misunderstood Mathias‘ abstract. I hoped for a session with language diversity in the foreground. But Mathias was more interested in the splitting of tasks to different hardware. For example, sorting on a GPU needs another procedure than on a CPU. Grid Computing also was a topic. Mathias searched for a method to spread mathematical operations in a network, possibly with load balancing. Following the Law of two feet of the Open Space, I left the session early.
XamlBoard
As a result of the technology independent concept of the Open Space, there weren’t as many WPF developers as in the years before. Nevertheless, I could get some of them to listen to my session and to attend my presentation of the XamlBoard. The main goal of our application is to improve the workflow when dealing with XAML files. The common tools, such as Expression Blend or Visual Studio, are well suited for editing purposes. What is missing however, is an overview of all available resources. That’s when XamlBoard leverages its strength to live preview all XAML elements. ‘Live’ not only refers to the fact that all controls were created directly from the resource dictionary, but also that you can interact with them. More information can be stored in attached metadata, such as keywords, to enhance searching or a detailed description where the resource should be placed. An additional highlight is the possibility to create your own templates to configure the view of each resource, or the linking interaction with Visual Studio right from XamlBoard. An internal version even added an export of images to use them in non-WPF projects.
Paket
My personal highlight of this Open Space was Paket. Steffen and Alex introduced their package manager with the rather unremarkable name Paket. The disadvantages of NuGet are at hand: there is too much information within the packages.config, as well as the versions being too explicit. Especially directory names typically lead to merging conflicts. Alex and Steffen try to avoid all those shortcomings. For this purpose, they store package dependencies at solution level. All calculated dependencies are stored in a second file. This technique should be well known to Ruby developers: it is the same proceeding of Gem.
Apart from NuGet package sources, even GitHub projects can be declared as dependency. Constraints can be specified in more detail this way.
Conversion of a project from NuGet to Paket is done via command line parameter. So there is nothing standing in the way for a changeover.
C++ 11/14
Using Qt Creator, Andreas demonstrated a number of innovations of C++ 11 and 14 and gave some general tips. E.g. the main function does not need a return statement, endl automatically flushes the output (that’s why you should use “\n” instead – or not, depending on what you want to achieve). The regular expressions in std::regex have defaults now. Linq expressions have found their way into the compiler and can be used with std::find. auto declares types of variables or return values implicitly. Linq and auto combined, lead to anonymous functions. And much much more… some of this information is already known from other sources.
It was new to me that compiler messages should become more comprehensible. An additional commitment is to clean up the code. An example is the new concept of a module: a class is implemented in its .cpp file, and an export generates automatically its .h file. However, this is just a proposal so far.
FAKE
Marcel and Max started the session but felt rather relieved when Steffen – the author of FAKE – joined. Using ProjectScaffold he explained the basic concepts and ideas behind FAKE. ProjectScaffold should allow the scaffolding of a new project the same way as Ruby does. FAKE itself replaces the mass of XML files – which MSBuild normally lets you generate – by a functional approach. The project created by scaffolding already contains the creation of a NuGet package, updating of GitHub pages by OktoKit, automatically generated documentation, tagging of the current state in the source control, deployment of all binaries and so forth. DotCover can be added as a target the same way. This lead to a short discussion if this is desirable at all. By using the .yml files that were also generated, the build script can be used right away on a build server. By using the according Plugin (thank you, Stephan!) can this be done even on a TFS.
War of the worlds – Docu vs Development
Anne and Kate tried to bait listeners for their talk with provocative questions about how to improve the collaboration between developers and editors/documenters. All their arguments were plausible. Not only while documenting we should put ourselves in the situation of the users: what do they need to know? What do they want to start with? That one thing, that I’m still doing wrong myself: developers often leave out the obvious. That’s how they force editors to follow up, or to translate answers. A common release note is “we have optimized”. This leads to the question: why? Were you bored? There should be a hint, what this optimization was good for. When documenting, developers should ask their selves: What is it? What is it good for? How do I configure it? This way, an editor has a good starting point to look for missing things or what can be improved from the grammatical point of view.
The conclusion of this session was that editors and programmers both have their own “super powers”. But only by combining both super powers the best result for the customer can be achieved.
Conclusion
It’s a long way from Saarbrücken to Leipzig, but the Open Space is worth the travel. It does not only consist in the sessions you can visit – it is much more. Between the sessions, during the breaks or over lunch, you can get lots of new insights and ideas. Traditionally, the exchange of ideas is continued in the Joseph-Pub in the evening. It depends on you how long you stay. And that’s why some people continue Open Space through the night and until late into the next day – occasionally only arriving back in time for their own sessions. On Sunday, the event gradually fades out. Some groups go on discussing until dawn. In the weeks following, you will try to process the experiences. To finally look forward to the next time…
