Case study

tuOtempO: lean refactoring guided by Architectural Clash

tuOtempO refactoring

tuOtempO is the first CRM to manage both patients and bookings of visits and examinations for healthcare companies.
One of the fronts on which we are collaborating is the refactoring of the frontend part of their application.
We believe that refactoring without a plan and especially without a shared vision is doomed to fail. This is why we decided to start this process with an Architectural Clash, in order to understand the strategic impact of the technological decisions we make in our daily work.

Architectural Clash

The Architectural Clash is a two-day format divided into three main phases: information gathering, micro-experiments and the definition of a refactoring plan. Because of this nature, we have proposed it to tuOtempO.

As mentioned, the first phase is used to gather information about the project and the context in which it lives. An important feature of this phase is the presence of technicians and decision makers.
This approach allows us to make explicit the connection between technological and business choices, because we believe that creating alignment between business goals and technical choices is fundamental to start a refactoring process in a healthy way.
In case of a refactoring, we usually approach this phase by trying to extrapolate the strengths and weaknesses of the code base from several points of view. The refactoring that we will do must resolve the reported problems while keeping the strengths intact.

The second part is the actual clash. The problems that emerged during the first phase are addressed with one-hour micro-experiments. These experiments are taken over by teams that form independently around the topic. Each slot is made up of 45 minutes in which the team puts its hands into the code and tries to solve the problem, and 15 minutes at the end which are used to draw conclusions and present them to the other team members.

In the last part of the workshop, all the teams come together to define a refactoring plan. The experiments are not about solving the problems that were extrapolated during the first phase, but about learning and finding roadblocks. This information is sorted to create a refactoring roadmap. In this case, we drew actions from our experiments and placed them on a Change Options Canvas to help understand the relationship between cost and value of each action. This allowed the tuOtempO team to prioritise the various activities and start the refactoring process.

Flowing proposed the Architectural Clash after analysing the complexity of our objectives and perceiving vagueness in the roadmap we had developed up to that point. The nature of the format reflects its title, as it is spread over 2 days with an enormous level of attention and constant awareness of the issues involved, and requires a great deal of energy because it tends to smooth out any obstacles on the way to drawing up an action plan that is as effective and appropriate as possible. The important thing is that Flowing himself is responsible for a good part of this energy effort, and at the end of the two days he leaves with the result of having put us in a position to clarify and prioritize our goals and even draw up a well-balanced plan of action, certainly not definitive, but that allowed us to start working concretely, directing us in the main technological choices.

Emanuele Luchetti, CTO @tuOtempO