Software Engineering Camp 2016

A few days have passed since last weekend’s Software Engineering Camp and I had some time to collect thoughts and reflect. I looked up when I first heard about this event and I traced it back to end of July:

Ever since then, I was looking forward to it. I visited many other events and meetups in the meantime, ranging from the local monthly Softwerkskammer and Java Usergroup gatherings to Devops Camp in Nuremberg and Socrates Day in Linz, both in October. I only moved to Nuremberg a little more than a year ago but I already got to know many interesting people, so I was looking forward to see a lot of them during the weekend. Also, I was eager to meet new people, be it local or from further away.

Friday – Welcome party

I met up with a few former colleagues to go to the welcome party on friday evening. Shortly before, the SWE Camp organizers had annouced some special guests for the conference with Susumu Sasabe flying in all the way from Japan. The evening started with some mingling followed by a short introduction round, before @laulowen, a former Methodpark employee now working at Google London delivered an impressive PechaKucha presentation about her experiences with working on a huge codebase among thousands of colleagues. Afterwards, there was a short lightning talk by the folks of, who presented their platform for distributed applications. Susumu Sasabe then shared some of his experiences from a life in engineering. The rest of the evening was a perfect combination of table soccer, video games, drinks and music.

Saturday – Day One

The next day started at 9am with breakfast and shortly after, the organizers set the stage and explained the bar camp format. Again, we introduced ourselves before we went on to session planning. Since I had been following the development of JUnit 5 over the last months I had prepared a session about it. In the end, there were so many interesting topics on the wall, that it was hard to choose which to attend.

Psychology in software engineering

I decided to start the day with a non-technical topic and went to Psychology in software engineering offered by @nullpluseins. We got to choose from a number of different topics that he had prepared and decided to talk about two of them.

The first one dealt with the topic of Burnout. What are the reasons for it, what are the consequences, and what can be done about it. Burnout is the same as depression, but society tends to attribute both terms differently: If you are burnt-out, you’ve been busy, if you suffer from depression, you are weak. There are signs that indicate trouble and oftentimes we can’t see those for ourselves. So what can we do if we notice them with our coworkers and we don’t know each other very well? @nullpluseins had different suggestions: You could talk to someone whose relationship might be better suited (indirect approach), or just carefully make an offer to talk: most people will not be offended if you take interest in them. Personally, I think it would have great to take this one step further an talk about preventative measures teams can take, but time was short, so we moved on to the next topic.
Which was about different bases of power in companies. It’s obvious that many power structures work top-down. Top-Down sources can be grouped in a few different areas. Some found on rewards or punishment, others on expertise or identification. But there’s also power sources that work bottom-up and approaches from some work better than others. For example, research has shown that appealing to rational arguments or cosying-up is more effective than threats, or teaming-up with colleagues.
Since there were some more interesting topics that were introduced very shortly in the beginning of the session, on Sunday there was a second part of this session and participants got to hear more about those.

Property based testing

My second choice was Property based testing by @scheibenkaes. After a very short introduction to Clojure, the programming language used in the presentation, we learned about the benefits offered by this technique: Tradiditonal testing is example-based and while it helps you to think about your code, it leaves many things untested. As an engineer, you’re responsible to find the boundaries for your tests and this can be difficult. With property based testing you identify properties of your test subject that you want to test and then have it run with lots of different generated input. @scheibenkaes explained a simple example where he identified some of the properties of the mathematical add operation: Commutativity, Associativity and Identity. Tests are written specifically for these properties. While the existing example-based tests missed a – deliberate – error, the property based tests quickly highlighted the problem. There’s libraries for many different platforms and I plan to look at junit-quickcheck, soon.

Architecture and new features of JUnit 5

After lunch, my JUnit 5 session was up and unfortunatly I missed @jerady‘s session on MQTT for that reason. I’m not very used to speaking at events but the vibe at the camp made it incredibly easy to activly participate.
So what’s JUnit 5 in a gist? I think it’s not only about a new programming model for tests, instead it’s about a new testing platform. By focusing on modularity and extensibility  JUnit 5 will take the position of previous JUnit version as the central testing platform on the JVM.


It achieves this by providing a JUnit Platform module, which is responsible for the discovery and launching of tests, and the concept of test engines, that can provide different programming models.
If you want to know more you can look at my slides or check out some of these videos [1] [2] or online resources [3][4].

Experiences with cloud infrastructures

Next up was an open session in which @jerady wanted to talk about the experiences with different cloud platforms. While providers like Azure, Google Cloud and Bluemix were mentioned, it turned out that unsurprisingly most of the practical experience was with Amazon Webservices. One question was: how do you manage cost? And is it possible to design your usage in a way to avoid provider lock-in? @jerady explained how his project team set up a fast-data processing platform built for a @codecentric automotive client. Based on the SMACK stack they built a platform that allows them to efficiently utililze resources. Thanks to automation everyone on the team was able to spin-up a running system easily. Although it was a very interesting session, I missed experiences with other platforms. Next year, hopefully we can bring some Google cloud from an upcoming client project to the mix.

Domain Driven Design

I especially looked forward to the remaining two session from 4pm to 6pm. After a very short introduction to the topic of DDD, @drechsler went into details on some of the building blocks of DDD: Entities, ValueObjects, Microtypes and Specifications. What purpose do these patterns solve and how do you apply them?  Although I had read some literature before, I learned a lot here.

After the first session some new participants joined while some left which was actually quite benefitial, since it brought a new dynamic into the room. We discussed how you can introduce DDD into projects, the need for culture change and previous experiences. The biggest outcome of this session only became clear on Sunday, when one participant announced his plans to start a DDD Meetup group in Nuremberg. This is great news and I’m looking forward to the first meeting. Keep your eyes open!

After a long day of sessions now it was time for dinner. While there were nice vegetarian options, the main attraction was the suckling pig, of course. This provided a good baseline for the rest of the evening again with drinks, music, great conversations and video games.

Sunday – Day Two

Sunday began a bit slower than the previous day and some people already had to leave the camp on Saturday evening, still you  felt the same energy from the first minute. After breakfast we planned the sessions for the coming hours and again it was becoming clear that no matter where you went, you would miss out on many other sessions.

Discussion about Microservices

Since during day one there were some sessions where the term Microservices came up I initiated an open session to talk about our understanding of the term and our existing experiences. I started the session by sharing my personal experiences from a project that I worked on in Berlin, but soon others joined in and a lively discussion started. In the end, the main takeaway was that it’s not about technology but about organisation. There’s no big benefit in cutting up your applications into seperate services if you still have one big team working on everything at once. We also discussed some technical topics, for example: “How should services communicate?” or “Should microservices contain their own UI?”. While I don’t think that the session added anything particularly new added to existing discussions, I think it was great to talk about it. Often times it feels that many companies in Nuremberg use quite an old fashioned tech-stack and this showed me that there is interest for these topics in the region.

Experiences with Legacy Code

My former colleague @mrtn_rdl, @FrankPrechtel and myself had teamed up in the morning for one more open session in order to talk about our experiences with legacy code. The session resonated very good with the rest of the camp goers and lots of people joined us. We discussed what makes it hard to work in legacy contexts and agreed on some common things: Often there’s no or bad documentation and you have hidden and unmanaged dependencies in the code. Sometimes it seemed that we arrived at to easy solutions, though. For example, I don’t think that a major contributing factor are junior developers. Instead, legacy code is produced by all of us and while juniors may lack experience to tackle some problems efficiently, I think that the same is valid for developers who have longer work experience.
So what can we do? To address the problem of unmanaged dependencies, it’s important to have a proper tool box. Two books that were mentioned where “Working Effectivly with Legacy Code” by Michael Feathers and “Refactoring” by Martin Fowler. Both provide concrete examples for specific problems that we can directly apply.
With regards to the documentation topic we agreed, that you shouldn’t have to much of it in the first place and you should document at the right level. The best documentation comes as tests and is part of the codebase. It can’t be outdated as the build will break if it doesn’t fit the implementation. Consistent and meaningful naming is also something that helps.
While some concrete techniques like Pair Programming and Code Reviews were mentioned to help improve projects we also stressed that the values of Software Craftsmanship are especially import in this context as you can’t improve a situation without a clear vision of how you want things to be.

No excuse for for not doing TDD even at the smallest target

After lunch, I decided to listen to Klaus sharing his story about developing for very small embedded devices with C. Most of what people talk about in the context of testing is aimed at large enterprisey systems, so it was very interesting to hear how different everything works there. The basic setup works by being able to switch build and test targets between your local machine and a the target device. This way you get some fast feedback locally and are still able to test device specific funtionality.
@embeddedjourneyman later joined in and showed a similar but more object oriented approach to the same problem. Both of them claimed that what they were doing was actually quite easy, but everyone was quite impressed with their work.



Sunday didn’t run as long as Saturday and so it was already time for the closing retrospective. Everybody was very happy and energized and the camp organizers got a lot of appreciation for making this weekend possible. They announced that there will be a new edition of SWE camp in 2017 and I think everyone who attended already looks forward to that. Here’s some more photos from the weekend. Also, make sure to check out the reviews of @stesie23 and @mrtn_rdl.
For me, SWE camp was a great way to bring together the tech community in Nuremberg and you can see that it’s not only appealing locally as many people came to town for the weekend. I’m hoping that some of the energy also trickles back into the regular community events. Hope to see many of you there and at the latest for SWE camp 2017!

One thought on “Software Engineering Camp 2016

  1. Good to see you enjoyed it as much as I did! Well written post that captured the event perfectly. And thanks for pointing out stesie23’s review as well – had not seen that yet 😉

Leave a Reply

Your email address will not be published. Required fields are marked *