Effective Code Reviews
In a mixture of a prepared talk and an open discussion, Frank Sons lead the session of how to make your code reviews more effective. The session was not at all about tools, but about the communication between team members. One big takeaway from this session was that you have to clarify the real goals of your code reviews with the whole team. Exemplary Goals are: Finding defects in the code, improving the code structure or building a shared knowledge of the existing code. Based on these goals, you can build checklists for what a good code review can contain and measure whether you stick to these targets. Also, you can try different formats of code reviews, Frank suggested doing code review meetings with more than two developers where one developer - that did not write the code - presents the code. Additionally, you have to be careful in how you formulate your review. You should never criticize the person who wrote the code, but only the code itself to enable a constructive discussion.
Collaborative Decision Making
Sandro Mancuso hosted a session about his experiences with collaborative decision making. His focus was on technical decisions, which can be of various kinds like architectural topics, integration of new software systems, changes to the release cycle, choosing a programming framework or similar. In general, this is a very difficult task to master in medium to large enterprises.
He described some grown patterns he observed for this task. The most basic approach consists of just reacting on acute problems. Some companies grew more advanced and provided a technical lead per team that is able to enforce and make those decisions. Sandro pointed out, that this may work with a benevolent leader but is lacking the holistic vision for the whole company.
As a solution he introduced the idea of a Technical Committee that may apply to companies that are suited for collaborative working and have a forward-thinking vision. The idea consists of creating a Committee with representatives of all teams to make the final decisions. Any employee may come up with a proposal. Those proposals are public and need to have a defined minimum number of people of the department who must support it. If a proposal has enough backers, it will be dealt with in the recurring meetings of the Technical Committee.
If you want to obtain more details, keep an eye on leanpub where Mancuso will host his book on Technical Committees soon.
Eberhard Wolff presented some demos for microservices in order to describe the challenges and different possible solutions. He described different technology choices & strategies regardings Service Discovery, Routing, Load Balancing and Resilience. Further, he presented synchronous and asynchronous approaches. For example, Netflix uses “Eureka” for Service Discover, Zuul for Routing, Ribbon for Load Balancing and Hystrix for Resilience. The presented example implementation can be found here.
Additionally, he described some alternatives as well, like using consul for service discovery or Kafka as asynchronous message broker. In his Kafka example, there was no need for service discovery and routing, because it was solved by Kafka topics and partitions.
The real highlight
A blog post just mentioning the contents of some sessions does not even come close to why this conference is special. The conference lives from its attendees and the welcoming and friendly atmosphere they are creating. Many attendees had prepared a topic they wanted to present or talk about in the sessions, be it in an open discussion, a prepared talk or in solving coding or architecture katas collaboratively. However, as the conference took place in a hotel where nearly all of the attendees stayed overnight, it was not limited to the session hours, but you could find groups of people discussing, chatting and having fun all the time.