How a Skiing Accident Put Our Development Practices to the test – enioka
Aller au contenu
How a Skiing Accident Put Our Development Practices to the test
Un seul être vous manque et tout est dépeuplé.
– Lamartine
Disclaimer : This article is a translation of an article originality written in French. So it contains some screenshot with French language in it. You have been warned.
Introduction
At enioka Haute Couture, we build software hand in hand with our clients’ teams. We bring our expertise in application design and in structuring development activities.
As such, it’s quite common in our engagements to set up a team composed of an experienced Tech Lead supervising both the client’s developers and Haute Couture developers.
This organization aims to create applications that are tailored to needs, reliable, and fully mastered by the client. We hand over the keys to the application at the end of the mission, without locking in our clients (see the enioka Haute Couture manifesto).
To achieve this, we advocate for development methods that promote knowledge transfer through written documentation.
You’re probably thinking: « Here we go again, another blog post where the author pats themselves on the back or polishes their company’s image. »
If we believe everything we read on medium.com, everyone writes tests, everyone keeps their documentation up to date!<br>Yet we all know that’s rarely the case. Otherwise, we’d know about it, or at least we’d see it.
Honestly, most of the time, when a project is documented — which isn’t often – we get something like this at best.
So we won’t brag too much, but we did have a rather painful opportunity to put our model on test in a way that was as sudden as it was brutal.
And « Poof » Goes the Tech Lead
In early 2026, we were working on a development mission for a lab management application for one of our clients.
We put together a team consisting of a Tech Lead and a developer from enioka Haute Couture, along with a developer from the client.
After a few workshops with the stakeholders, a design was finalized, the backlog was initiated, and the project kicked off following an agile process.
Sprints came and went, the application’s foundations were in place, and the CI/CD pipeline allowed us to test and deploy the application in the first test environment.
However, the application wasn’t fully defined yet: some features were still being discussed in workshops with the business. Certain tough issues remained and were being addressed iteratively.
Then came the Easter weekend. Everyone headed off for the long weekend, with the promise of returning to work well-rested, on Tuesday.
But when the weekend ended, disaster struck: the Tech Lead didn’t come back.
Accidents happen quickly, and not just when you’re doing risky activities. It can happen on any project, at any time.
Consider how many people on your team go skiing, horseback riding, do DIY projects, or simply drive a car ?<br>Multiply that number by the number of limbs (arms, legs), and you get an idea of the odds of someone just getting hurt !
In our case, our Tech Lead engages in all of these pastimes and still has all four limbs to this day.
One Day to Take Back the Reins
To address this exceptional situation, enioka Haute Couture mobilized to provide a Tech Lead to assume project leadership. Having been notified of the accident during the holidays, the replacement was arranged within the week.
But the new Tech Lead didn’t know the project, hadn’t participated in the workshops, and yet needed to become operational quickly.
Fortunately, good documentation practices had been established from the start of the project. The new Tech Lead, like the rest of the team, had access to multiple levels of documentation to grasp the complexity of the solution being built.
Project Description
This is the first level of information. At enioka Haute Couture, we have an internal wiki where each project is described with:
The mission’s subject, its stakes, and expected outcome.
Identification of project stakeholders, their roles, and contact information.
Communication channels.
Tools provided by the client: email, knowledge base, ticket manager, code repository.
Documentation entry points.
Logbook
A shared logbook, in addition to the one maintained by the Tech Lead, provides the project’s history.
It recalls past and future milestones, as well as significant project events (first delivery, incidents, etc.).
We also keep track of meeting notes.
Architecture Document
During design phases, we create an architecture document that describes how the application works, its integration with external components, and its internal organization.
This is the document the team refers to for understanding the solution.
This document follows the C4 model formalism to describe the solution from the most general...