Lyon Craft 2024: feedback about 7 conferences

Lyon Craft: What is it?

Lyon Craft was the ideal event for sharing and exchanging ideas and experiences around software craftsmanship.

The event was organised by key figures from the Craft community, including Colin Damon from Ideme, just as the XCRAFT event a few months prior. For anyone interested in or curious about Craft, this was the perfect place to be,The choice of conferences is vast, and you will surely find one that you like.

On April 8th at L’Embarcadère, attendees had access to multiple conference rooms, where they could listen to lectures, participate in group workshops, and engage in live coding sessions.

What is Software Craftsmanship?

Software Craftsmanship represents a mindset and approach that emphasises the quality of both the product and the code. It encompasses multiple aspects, including high-quality design and well-being at work. The conferences on that day highlighted these essential elements.

Conference Highlights

Grégory, a Back-End Analyst Developer at Extia Lyon, attended Lyon Craft in April 2024 and shared his overall feedback. The conference offered a diverse range of topics, including Hexagonal Architecture, Software Crafting, Trunk-Based Development, and Biomimicry.

Hexagonal architecture by Julien Lenormand

This conference was perfect for anyone who wanted to understand how a design approach, called hexagonal architecture, can positively transform a project. Watch the video here.

In the session, we explored hexagonal architecture through a live coding workshop. Step by step, we integrated this architectural pattern into the project. For example, we had to retrieve data from a live bucket to check the status of Pull Requests (PRs), which are branches of code that need to be reviewed and merged into the main project.

The initial version focused on basic needs:

1. A global view of all PRs (Pull Requests) for all users.
2. A specific view of PRs for individual users by applying filters to the data.
3. A combination of both: filtered and unfiltered content.

Later versions went beyond these basic requirements. 4.The goal was to make the product "field-tested" by ensuring it could handle real-world scenarios.

We added functions to load test files, generate new visuals, and test the interface contracts…

The final version, developed with the collaboration of public feedback, embodies the core principles of hexagonal architecture.

Keep Calm with Léa Coston & Matthieu Sauboua-Beneluz

This conference was for you if you wanted to explore different perspectives and learn simple techniques to make your code clearer and more reliable. Find the video here.

During the Advent of Code, a coding event held in December leading up to Christmas, Léa faced a challenge with one of the exercises. She struggled to write the necessary code to solve the puzzle and reached out to Matthieu, who specialises in Software Crafting. Here are some highlights from the conference.

When we try to solve a problem, like creating a function or an algorithm to meet a specific need, we often invest a lot of effort. However, several factors can make it harder to concentrate:

• Cognitive load: this refers to the mental effort required for the task or influenced by the surrounding environment.
• Working memory: we can only hold a limited number of items in our minds at once.
• Lack of feedback: this can lead to difficulties in self-assessment and reflection.

How can we simplify life?

• Use clear, descriptive names for variables and functions: avoid vague terms like "the thing" and instead use specific, meaningful names that reflect their purpose, such as dashboard, range section, subchains, building, or telecom operator. This makes your code easier to understand and maintain.

• Isolate and test complex code: If a part of your code is difficult to understand, break it down into smaller parts and test each one individually. If something isn't working correctly, don't ignore the issue just because the rest of the code seems to be running fine. Address the problem directly.

• Clarify intentions early: simplify your code by breaking it into well-named functions, each handling a single task. Clearly define what each function is supposed to do and how it contributes to the overall goal of the program or algorithm. This helps others (and yourself) understand the purpose behind your code.

Trunk-Based development with Romain Koenig

This conference was for anyone looking to understand why projects benefit from simpler functions and smaller changes. These practices lead to better team responsiveness, greater satisfaction, and increased trust among stakeholders. Find the video here.

The goals: merge shorter pull requests (PRs) rather than maintaining long-lived branches that are hard to integrate when they eventually become ready.

What happens if PRs are too long?

• Developer burnout: long PRs are hard to maintain, challenging to share, and sap motivation.
• Stress during production (Go-Live): large stacks of code increase the chances of errors.
• PRs become difficult to work on: long pauses for the original authors, or when new team members take over, make it hard to manage.

The solution:

• Short-Lived Feature Branches: use branches with short life cycles to keep development quick and focused.
• Functional Splitting: prioritise essential features, eliminate Nice To Have that don't add immediate value.
• Technical Splitting: break commits into smaller, independent units to avoid dependencies.

Main principles:

• Feature Flags: push new features to production but keep them disabled by default. They can be activated later without a full production release (Go-Live).
• A/B Testing:test different versions of a feature with user groups (example Gmail features), then compare results and make data-driven decisions.
• Special Flags: (example Black Friday mode):temporarily enable features for high-traffic events and return to normal once the event is over.

In this setup, any structural change is tracked by an ADR (Architectural Decision Record), which is included in a PR that must be approved by the team. Ironically, the first PR to require trunk-based development was too long and had to be cancelled! However, a more focused second version was accepted.

Let's talk! With Houleymatou Baldé & Colin Damon

This conference was perfect for anyone who never had thoughts about becoming a speaker or felt they had nothing valuable to share (spoiler: you do!). Watch the replay here.

This wasn’t a typical technical discussion, it was more like a live theatre performance.

The topic? Colin, the organiser of LyonCraft and Xcraft, was trying to convince Houleymatou, co-founder of Yeeso and non-technique, to speak at LyonCraft 2024.

Throughout the conversation, Houleymatou voiced all the reasons why she felt that she wasn’t qualified to speak, while Colin addressed each concern and encouraged her with confidence.

Tips for giving a speech at a conference

• Start with something simple: for example, explain how to determine a leap year (bissextile year).
• Leverage skills you already have: if you can draw, incorporate sketches into your talk.
• Engage the audience: show your involvement by asking questions or encouraging participation (example: raise hands).
• Use free speech if it’s your strength: speak naturally and let your personality shine.
• Sing if you can, don’t be shy!

Houleymatou demonstrated these ideas by giving a talk on-two topics at once: explaining how to model a leap year kata while simultaneously performing the talk, alongside Colin.

You don’t have to be an expert to give a talk. Spending just a couple of hours learning about a subject often gives you more knowledge than most people. This makes you a valuable resource for others who are curious or have questions.

How to approach a technical topic without being too technical:

• Focus on the human side or the context: make the subject relatable and easier to understand.
• Invite a technical expert: If necessary, bring someone more technical to handle the in-depth details, like Colin and Houleymatou did.

Domain-Driven Design (DDD) and Product: pillars of a craft transformation with Damien Carbonelli

This conference was for those interested in how large-scale monolithic projects can transition into a domain-driven architecture through craft principles. Watch the replay here.

In an TSO (Electricity Transmission System) project focussing on energy inquiry monitoring, the LinkySup system handles millions of requests daily. The current system is highly complex, with specialised teams that are dependent on each other and lack autonomy. This structure needed to evolve.

Deconstruct, factorise, anticipate, and take a step back. The monolithic domain system was broken down into several smaller sub-domains to reduce its complexity. The goal was to align with the XLR8 (accelerate) principle: leveraging the company’s existing strengths to increase her global value. More details here.

The project consists of 22 modules (domains): by focussing first on the less-used modules, two benefits emerged:

• Improved clarity and maintainability of the application.
• Increased visibility and usage of previously undervalued parts of the system.

They implemented Living Documentation, that wasautomatically updated with each release (Go-Live). This makes it easier to track differences between versions and quickly identify issues when they arise.

By applying these principles, developers became more engaged and proactive. Bugs are detected and resolved faster, with fewer long-term impacts.

An architecture to test Front-End by Alexia Souvane

This conference was for you if you thought that testing only applies to back-end apps, or if you believed that front-end testing only worked with Selenium. Watch the replay here.

Why testing the code matters:

The test pyramid is typically shown with minimal end-to-end (E2E) testing, since it's costly to implement. E2E tests focus on securing critical processes of an application. Beyond that, unit testing (UT) focuses on testing isolated parts of the application to ensure they function correctly. These tests are less expensive and run more frequently.

This approach works well for the back-end, but what about testing the front-end? Specifically, how do we test user interfaces and displays?

For front-end testing, the goal is to verify behaviour, not how it's implemented.

The process involves:

• Launching a front-end test with an initial setup.
• Triggering an action.
• Checking if the system ends up in the correct state.

Therefore you need to:

• Isolate the code unit that updates the data to ensure it can be tested independently.
• Avoid coupling business logic with the front-end framework, which can make it difficult to test parts independently.
• Enhance cohesion: ensure all elements within the same module work towards the same goal.

For more details on coupling and cohesion.

Biomimicry at the Dev’s rescue with Christophe Breheret-Girardin

This conference was perfect if you wanted to to explore new possibilities and expand your mindset. Find the replay here.

The conference dealt with a variety of topics, and here are some of the highlights:

A lot can be achieved by continuous effort and learning from nature.

To understand biomimicry, let’s start with various examples. The Shinkansen (Japan’s ultra-rapid train) was inspired by the kingfisher bird, which can dive into water without causing much disturbance. This design allowed the train to move faster with less energy by reducing air resistance. The same principle was applied to solar panels : they adjust to maximise sun exposure throughout the day, and were directly inspired by sunflowers and their ability to follow the sun. While these examples aren’t directly related to tech, they illustrate how natural principles can influence innovation in various fields, including technology. That’s what we’ll try to understand.

The strangler fig tree

Much like how a strangler fig tree overtakes its host in order to develop, this approach follows a gradual concept, where parts of the application are transformed step by step until the new components fully replace the old ones. This is achieved by using techniques like front walls, double writing, and extensive use of feature flags to push new features into production but only activate them when needed.

The immortal medusa

The immortal medusa enters a dormant state to later revive, resembling the app's repeating cycle of evolution, redesign, and reboot. To break free from this endless loop of rework, it’s essential to invest in quality from the very beginning.

The watermelon test

Consider a watermelon: on the outside, it appears green, but you can't tell how ripe or ready it is just by looking. This can be compared to writing superficial tests in pursuit of high KPIs. The tests may look successful on the surface, but they fail to assess critical functions. For example, fully testing a calculator's functionality while neglecting to check division by zero.

The diversity of the meadow

Imagine a meadow, a vast ecosystem made up of various plants and trees, each with a specific role or cycle that helps sustain the environment. The same principle applies to your app: don’t implement unnecessary methods or functions, just as grass doesn’t need to have a scent. Every feature should have a purpose that contributes to the overall ecosystem of the app.

Don’t imitate for the sake of imitating

Don’t adopt new technologies just for the look of being cutting-edge. Instead, choose proven, reliable technologies. Avoid falling into the trap of "sheep wars" by selecting tools based on hype rather than value.

Many other conferences were held that day, so feel free to scroll through the playlist and find something that piques your curiosity. If a title sounds familiar, take a look, you might discover something new.

For more informations:

Sources: Playlist of the main auditorium (Hall) Playlist of the Pause & Play room A thread on LinkedIn

Other examples: Staying Zen while coding Feedback from UnConf, the next day of LyonCraft. The UnConf allows us to debrief the conferences of the past day and create unusual workshop events.

  This article was written by Gregory, Back-End developer at Extia.