Cookies
Diese Website verwendet Cookies und ähnliche Technologien für Analyse- und Marketingzwecke. Durch Auswahl von Akzeptieren stimmen Sie der Nutzung zu, alternativ können Sie die Nutzung auch ablehnen. Details zur Verwendung Ihrer Daten finden Sie in unseren Datenschutz­hinweisen, dort können Sie Ihre Einstellungen auch jederzeit anpassen.

Engineering

Be more social and become a polyglot - Zweitag @ CraftConf 2017
Minuten Lesezeit
Blog Post - Be more social and become a polyglot - Zweitag @ CraftConf 2017
Jonas Juchim

Wednesday

We arrived on wednesday afternoon and had a bit time for sightseeing. Budapest is a beautiful city with a lot of lovely places and we regret that we did not had more time to enjoy the wonderful landmarks. Late afternoon we took a streetcar ride to Mosaic, a co-working space which hosted one of the many pre-conference meetups. We enjoyed two good talks about microservices and afterwards went to a pre-conference party at Google Ground - a really cozy and interesting beer garden. It included small snacks and free beer for the conference attendees and the opportunity to get in contact with other attendees even before the conference started.

Budapest

Thursday

Thursday morning started with a train ride on a historical train chartered exclusively for conference attendees - the Craft Express - to the extraordinary venue, an old railway museum. It drove slowly, but brought us to our destination safely. After checking in, we explored the environment which featured countless old steam locomotives and many artifacts from the past. At 9 am the actual conference started with a keynote by Dr. Tim Wagner from AWS. To get an impression of the diversity of talks, the schedule is worth a look. After many great talks and lots of good food we made it to the closing keynote from Damian Conway about Fun with Dead Languages - which was at least as funny as the title promised. We called it a day while having a few beers and good discussions at the conference party in the evening, which included a live Jazz-Band and later on a DJ.

Craft Conf

Friday

On friday it was mainly the same procedure as the day before: We arrived at the venue, got some breakfast and shortly after the first talks started. Once again we were pleasantly surprised how many great talks the Craft Conf offered and it was difficult to choose. After an even more tiring - but really fun - day, we enjoyed the closing keynote by Theo Schlossnagle about Better Engineering via Better Discourse. After an exhausting two days of talks, we happily grabbed a few beers at Rizmajer Kézműves Sörház, which was recommended by a local and we can really recommend it too - good tasting beer for less than 1€.

Craft Conf

Favorite Talks

We were astonished how many great talks we had the chance to attend. It is definitely worth watching some of them online - you can find links to all talks at the end of the blogpost. Here is a small selection of our favorite talks:

Tackling Technical Debt at Scale - Yvette Pasqua

Yvette Pasqua, the CTO of Meetup talked about technical debt in large projects that evolved over time and how they tackled it by shifting their work culture and the perception of the problem.

On the one hand the term technical debt has a negative vibe and on the other hand it is difficult to convince non-engineers of the necessity to reduce it without adding features. To emphasize the positive effect of working on technical debt, the team at Meetup replaced the term “Technical Debt Reduction” with a more positive one: Continuous Product Health.

As a next step every member of the team was able to submit issues that they wished to be tackled and improved. This led to a high amount of open issues ranging from small fixes to big refactorings with a high complexity.

In order to reduce technical debt continuously, it was integrated in their six month product planning cycle. During this process the issues were prioritized regarding their improvement of the overall product health. Prioritization factors were based on the Meetup team culture - reliability, simplicity and speed - and the expected business value.

In their first cycle including product health the engineering team focused on small issues which were easy to fix. Hence, at the end of the iteration a lot of issues were closed. But, since all closed issues were rather small, they had little impact on the product health. Thus there was very little recognition outside of the development team.

For the next cycle the team decided to focus only on a few high impact items. This resulted in a significant increase in overall product quality as well as recognition outside of the engineering team.

In conclusion, this talk illustrates how tackling technical debt can become an integral part of the development process as well as company culture.

Building Open Source Communities - Ash Furrow

Building Open Source Communities

Ash Furrow shared his experiences and visions of being an open source maintainer. The first step of creating an open source project is getting some piece of code out there - which he deemed the easiest part.

Subsequently, it is most important to build a community around the project. For an open source project without a community supporting it, the biggest threat is the maintainer himself. For example, if the maintainer loses interest or gets burned out - which can happen really fast in the open source world - the project dies.

Hence, especially in the open source community, programming is mainly a social activity. Ash proposes to create an organization for the project as soon as possible and thereby empower contributors by adding them to the organization very quickly - e.g. after the first merged pull request. Furthermore, he emphasises that it is substantial to make contributing easy and make contributing feel good in order to attract long term contributors. As a maintainer you should always be kind - even if it’s difficult sometimes - and say thank you regularly.

Finally, he concludes that open source is good for everyone - business, developers and customers.

Software (r)Evolution: A Crystal Ball to Prioritize Technical Debt - Adam Tornhill

A key challenge in the process of tackling technical debt within a large project is the prioritization process of different refactoring opportunities. In his talk Adam Tornhill offered some methodologies and techniques to approach this problem in a structured way.

The underlying problem of prioritizing technical debt is the difficulty to quantify the costs of a specific debt. In most cases the costs of technical debt occur as interest over the course of time, in a similar way to financial debt. Hence, it is not self-explanatory which technical debt has the highest cost and therefore should be tackled first.

The main idea behind the methodologies presented by Adam Tornhill is to use already existing metadata from the code base. One example for such metadata is the information regarding the changes and timestamp tracked by a version control system like Git. This information can be used to track down Hotspots - characterized by a high change frequency paired with a high complexity. If a Hotspot is identified, it is possibly a worthy place to start refactoring, since a small improvement might have a huge effect on quality and complexity.

To start with the Hotspot analysis one can track some metrics (number of changes, complexity) on file level, but it is also possible to change the scope to individual functions or code segments. That especially helps to prioritize which part of a large file should be refactored.

In addition to this static analysis, it is possible to supervise the complexity trends over time. This helps to find the right time to start a refactoring, for example if the complexity of a hotspot has significantly increased.

Furthermore, the data tracked by the version control system can be used to determine Temporal Coupling between different higher-level components. Temporal Coupling describes the tendency to always change some components together, which indicates a tight coupling between these components. This may indicate another refactoring possibility to group the components in a different way.

The presented methodologies offer an intuitive way to start prioritizing technical debt with the use of already existing data.

Tech Lead Skills for Developers - Pat Kua

Tech Lead Skills for Developers

Pat Kua shared his insights of being a tech lead at ThoughtWorks. He stated that a tech leads’ goal is to make sure that all team members head in the same direction. Whereas, the intended direction has to generate the most benefit for the customer. In order to achieve this goal, he presented three areas a tech lead should focus on:

  1. Programming: Every tech lead should at least spend 30% of her time programming with the team. Furthermore, it is important to build a team culture where one can admit mistakes and ask for help. The best way to achieve this, is to lead by example and admit your own mistakes to the whole team - everyone makes mistakes. Finally, it is really important to have a technical vision for the project and communicate this vision properly.
  2. People: Everyone has different strengths and weaknesses. It’s important to understand them and integrate them in a way that forms a healthy and effective team - building trust takes times. Another really important responsibility is to grow people by challenging them from time to time. Thereby they get pushed out of their comfort zone and can try something new - Pat said it’s about keeping them in the flow where they perform best without getting bored. Because bored people quit - which sounds very reasonable.
  3. Process: Is it okay to tell people what to do? It depends - as always. He presented the situational leadership model that is divided into four quadrants Direct, Coach, Support, Delegate and can provide some guidance when to apply which leadership style.

Pat finished his talk with one last message: Make time for you. Take your time to try something new - play with technology or free your mind.

Summary

Thank you

If we had to extract the key messages from all the different talks we have seen during the conference, we would boil it down to the following two:

  1. Programming is about the people! Regardless of the environment you are working in or the product you are working on, a huge part of the process involves different people, personalities and skill levels.
  2. Become a Polyglot! It is very important to not focus on a single area of expertise, i.e. a single programming language. Every programming language, every different area of expertise might provide some new insights and learnings that bring you forward. Therefore, give yourself some time to play around with new (and very old!) technologies, experiment with new ideas and keep pushing yourself out of your comfort zone!

Overall the CraftConf was an amazing experience, with a lot of very interesting talks and people. Thus, we are looking forward to CraftConf ‘18.

Here are some useful links:

Du suchst den richtigen Partner für erfolgreiche Projekte?

Lass uns ins Gespräch kommen.