GitLab Commit is coming up on August 3-4. Learn how to innovate together using GitLab, the DevOps platform. Register for free: gitlabcommitvirtual2021.com

Unverified Commit 0a4b3dd9 authored by Cyrille Chopelet's avatar Cyrille Chopelet
Browse files

[Blog] Prepare post on technical debt

parent 66474ec1
......@@ -17,7 +17,7 @@ cover:
author: chop
categories: [ software-creation ]
tags: [ architecture, management, sustainable-digital ]
keywords: [ lecture, livre, livres blanc, article, studies, blog, architecture logicielle, écoconception, durable ]
keywords: [ lecture, livre, livres blanc, article, studies, blog, architecture logicielle, qualité, dette technique, software craftsmanship, tdd, écoconception, durable ]
---
La fin de l'année est propice aux bilans.
......
......@@ -17,7 +17,7 @@ cover:
author: chop
categories: [ software-creation ]
tags: [ architecture, management, sustainable-digital ]
keywords: [ reading, book, white paper, article, study, blog, software architecture, ecodesign, sustainable ]
keywords: [ reading, book, white paper, article, study, blog, software architecture, quality, technical debt, software craftsmanship, tdd, ecodesign, sustainable ]
---
The end of the year is a good time for assessments.
......
......@@ -9,7 +9,7 @@ description: |-
author: chop
categories: [ software-creation ]
tags: [ management ]
keywords: [ communication, architecture logicielle, maison, comics ]
keywords: [ communication, architecture logicielle, maison, comics, dette technique ]
---
Il y [une iamge que j'aime beaucoup][metaphor] pour parler du développement logiciel : la construction d'une maison.
......
......@@ -9,7 +9,7 @@ description: |-
author: chop
categories: [ software-creation ]
tags: [ management ]
keywords: [ communication, software architecture, house, comics ]
keywords: [ communication, software architecture, house, comics, technical debt ]
---
There's [an image I like][metaphor] when I speak about software development: the construction of a house.
......
---
date: 2021-03-01T07:00:00+01:00
title: De l'importance de maîtriser sa dette technique
subtitle: Ou la modération en toute chose d'Aristote
slug: importance-maitriser-dette-technique
description: |-
Ne pas négliger la qualité, mais ne pas trop en faire non plus.
Il y a un compromis à trouver, souvent perdu entre la pression des chefs de projet et la vision artistique des leaders techniques.
author: chop
categories: [ software-creation ]
tags: [ management ]
keywords: [ qualité, gestion de projet, dette technique, maison, ux, dx ]
---
Au cours de ma pas si longue carrière, je me suis souvent retrouvé face à un de mes directeurs sur un sujet : la qualité.
Nous sommes tous deux d'avis que c'est nécessaire pour nos projets, mais avons bizarrement une perception différente du seuil à viser.
Quelques réflexions.
<!--more-->
[^fn-love]: Ça ne m'empêche pas de l'adorer, mais ce n'est pas le sujet.
## Parlons un peu de mon cas
Je pense que je ne suis pas le seul, mais je travaille généralement en plusieurs étapes, par itérations, d'une façon assez proche de celle que recommandent les approches Agiles.
Si on découpe très grossièrement ma façon de faire, on obtient deux étapes :
1. Faire un truc qui marche.
2. Améliorer ce truc et en faire une solution qui est « mieux ».
« Mieux » est toujours subjectif.
Mon directeur me connaissait depuis un moment et je pense qu'il croit que, pour moi, ça signifie « plus joli, plus abstrait… »
C'est dans cet esprit qu'il me dit toujours : « Le mieux est l'ennemi du bien, » signifiant par là que ce sera un coût et que je risque d'empirer les choses plutôt que de les améliorer pour aucune valeur perçue par l'utilisateur.
Je ne peux pas le lui reprocher : plus jeune, j'ai pu lui donner des raisons de penser ça.
Aujourd'hui cependant, quand j'arrive à l'étape d'amélioration, je veux avant tout m'assurer que le code sera maintenable dans le futur, ce qui implique des tâches que tout codeur est réputé détester :
- vérifier que le code est correct, nettoyer le code obsolète issu des essais successifs ;
- correctement documenter et commenter tout ce qui pourrait ne pas être évident en première lecture[^fn-doc] ;
- tester tout ce qui doit l'être, avec commentaires et documentation selon le besoin pour les tests également.
Ce dernier point implique un focus sur les spécifications fonctionnelles et non fonctionnelles[^fn-nfr].
Ça pourrait être du bon sens.
Alors, d'où vient notre divergence d'opinions ?
[^fn-doc]: J'ai été de ceux qui pensent que le code est sa propre documentation, mais je sais à présent que quelques commentaires peuvent faire gagner beaucoup de temps à la compréhension d'un algorithme complexe, voire éviter des non-sens.
[^fn-nfr]: Les spécifications non fonctionnelles sont les critères qui permettent de juger du bon fonctionnement du système plutôt que de son bon comportement.
Par exemple, « doit répondre en moins de 500 ms » est une spécification non fonctionnelle.
## Perspectives managériale et technique
Quand vous travaillez dans une ESN[^fn-esn], vous vendez un projet avant qu'il ne commence à un prix que vous estimez.
Tout le jeu consiste à trouver le juste prix, pas trop cher pour que le client vous préfère à la concurrence, pas trop bas parce que la réalisation du projet vous coûte des sous.
Une fois qu'il a été vendu, la deuxième partie du jeu est de s'assurer que les coûts sont inférieurs au prix de vente, ce qui vous permet de dégager quelques bénéfices.
Alors quand un jeune soi-disant expert technique vous dit que la solution fonctionne mais qu'il doit encore travailler dessus, vous avez tendance à penser « Enfer, je pourrais livrer ça et avoir un client content, mais je vais perdre encore un peu d'argent à cause d'un esthète. Si ça fonctionne, arrêtons-nous là ! »
En face, si vous êtes comme moi (le moi d'aujourd'hui, un peu plus posé que le jeune je-sais-tout de l'époque), vous ne pensez pas que ce travail additionnel soit du temps perdu, mais simplement quelque chose que le client attend.
S'assurer que le code est maintenable n'est pas un coût, c'est un investissement.
Imaginons que ce même client revienne quelques années plus tard avec des demandes d'évolution.
Si l'équipe est allée trop vite la première fois, ces changements seront coûteux.
Un développeur mécontent pourrait même dire que les créateurs du truc ont travaillé comme des ***** (je vous laisse choisir le qualificatif utilisé).
Bonjour le ressenti pour le client !
Il a dépensé sans compter et tout ce qu'il en a tiré est ce code pourri.
Le bouche-à-oreille pourrait rapidement abîmer votre image de marque.
Pour résumer, mon directeur se concentre sur la livraison d'un produit conforme en temps et en heure, tandis que je pense également à la maintenance, le débogage, les évolutions qui devront être faits dessus.
En d'autres termes, il pense uniquement à l'expérience utilisateur maintenant tandis que je pense à l'expérience utilisateur maintenant et à l'expérience développeur dans le futur.
[^fn-esn]: Entreprise de services du numérique, une société à laquelle d'autres sociétés font appel pour les aider dans la réalisation de leurs projets informatiques.
## La notion de dette technique
Qu'est-ce que la dette technique ?
C'est ce que vous avez refusé de payer à un instant _t_ et qui revient vous hanter par la suite.
Vous _saviez_ qu'il fallait s'en occuper, mais vous aviez d'autres priorités donc vous l'avez laissé à ce moment.
Les intérêts se sont cumulés : tandis que le temps passait, vous avez ajouté du code et des fonctionnalités par-dessus cette base incorrecte.
Puis, un jour, vous décidez qu'il est temps de corriger ça, soit parce que vous aviez acté que ce serait fait, soit parce que vous _devez_ le faire pour pouvoir faire votre prochaine tâche.
Plus vous avez attendu, plus vous aurez de travail : naturellement, le point de base est toujours là, mais tout ce qui a été construit en l'utilisant comme postulat est potentiellement impacté[^fn-tests].
Voilà de quoi il s'agit quand on parler de maîtriser sa dette technique : s'assurer que, si je dois faire évoluer mon logiciel dans le futur, je pourrai le faire sereinement sans préalablement devoir corriger une grande liste de tickets abandonnés.
Et ce rapide billet n'aborde même pas le coût de suivi et correction des dizaines de bogues que peut entraîner un problème de dette technique.
[^fn-tests]: Si vous êtes dans ce cas, j'espère que vous avez bien mis en place vos tests unitaires.
Cela vous aidera à vous concentrer sur votre travail sans vous inquiéter de potentielles régressions.
## N'allez pas trop loin
La surqualité et la suringénierie sont des réalités.
C'était certainement celles qui inquiétaient mon directeur.
Pour les chefs de projet, je vous recommande d'échanger avec votre équipe pour voir s'il y a une vraie dette technique ou s'ils veulent juste aller plus loin parce que ce serait « mieux ».
Pour les techniciens, gardez en mémoire que vous ne travaillez pas pour la beauté du code.
Vous le faites pour atteindre un but, offrir une fonctionnalité.
Ne créez pas une solution ultra-générique pour gérer un cas unique, ne mettez pas en place un gestionnaire d'add-ons pour un process qui n'en aura jamais besoin…
Ne construisez pas une centrale à charbon pour allumer une ampoule.
Ce sont d'autres formes de dette technique : un code bien si complexe que celles et ceux qui devront le maintenir verseront toujours une petite larme et ne seront jamais à l'aise.
En revanche, si vous avez besoin de faire quelque chose parce que c'est un risque pour le futur, dites-le simplement au chef de projet[^fn-politician].
[^fn-politician]: À de rares occasions, ils peuvent être plus politiciens que chefs de projet.
Déployer de nouvelles fonctionnalités peut leur sembler plus important que de se protéger de risques futurs.
Par le passé, j'ai prévenu le chef de produit de trois risques importants liés à de la dette technique.
Il m'a répondu : « Tu as raison, mais il nous faut des fonctionnalités pour l'instant. »
Moins d'un moins plus tard, un incident critique est survenu, lié à un des risques que j'avais soulignés.
J'ai été fortement tenté de tout laisser brûler.
Heureusement, j'ai pensé en priorité à mes équipiers et aux utilisateurs embêtés.
## Petite illustration
Avant de nous séparer, je voulais revenir à [mon image habituelle][image] : vous construisez une maison.
Vous voyez qu'un tuyau n'est pas comme il devrait, mais vous voulez aller vite et ce sera « suffisant » pour l'instant : l'eau va quand même là où elle devrait.
Puisque c'est « suffisant », vous faites comme si c'était terminé : vous fermez le mur et vous carrelez.
Un jour, vous voudrez ajouter un autre évier, ou simplement répare le tuyau.
Il faut d'abord retirer le carrelage et le plâtre, puis s'occuper du tuyau, avant de tout remettre.
Mais peut-être que modifier ce qui est dans le mur vous oblige à changer le mur lui-même, ce qui peut avoir un impact sur la charpente…
Et on ne parle encore une fois pas des diverses fuites (bogues) que cette non-conformité a générées par sa simple présence et qu'on a épongées du mieux qu'on pouvait en sachant que le tuyau devait être un jour remplacé.
On pourrait en dire bien plus sur la qualité et la dette technique, mais ce billet devait rester court.
Si le sujet vous intéresse, nous pourrons essayer d'aller plus loin à l'avenir.
Le message ici est le suivant : retarder la qualité ou nier son besoin revient à accumuler de la dette technique et ses intérêts, que quelqu'un aura un jour à payer.
{{< figure src="/img/vincentdnl/technical-debt.png"
link="https://vincentdnl.com/drawings/technical-debt"
alt="Un chef de projet insatisfait se plaint qu'il est long d'ajouter une nouvelle fenêtre à une maison bancale."
caption="« Je ne comprends pas pourquoi c’est si long d’ajouter une nouvelle fenêtre. »"
attr="Vincent Déniel (CC BY-NC 4.0)"
attrlink="https://twitter.com/vincentdnl" >}}
[image]: {{< relref path="/blog/2021/02/08-metaphor-development" >}}
---
date: 2021-03-01T07:00:00+01:00
title: Of the Importance of Controlling Your Technical Debt
subtitle: Where Aristotle's Golden Mean is precious
slug: importance-controlling-technical-debt
description: |-
Not neglecting quality, but not overdoing it either…
There's a middle to be found, often lost between the managers' rush and the tech leads' artistic point of view.
author: chop
categories: [ software-creation ]
tags: [ management ]
keywords: [ quality, project management, technical debt, house, ux, dx ]
---
In my not-so-long career, I've often been at odds with one of my directors[^fn-love] about one topic: quality.
We're both of the mind that it's a necessary thing in our projects but, basically, our perception of what's "good enough" is different.
Here are some thoughts.
<!--more-->
[^fn-love]: That doesn't prevent me from loving him, but that's not the point.
## More on My Case
I think I'm not the only one, but I work in several steps.
I iterate, very like the Agile approaches recommend.
Fundamentally, the main steps are the following:
1. Make something that works.
2. Review and enhance the solution so that it's "better."
"Better" is always subjective.
That particular director has known me for a while, and I suppose he thinks that, to me, it means "more beautiful, more abstract…"
That's why he always says, "'Better' is the enemy of 'good,'" meaning that I'll take time tweaking something that works, possibly breaking it, with no added value for the user.
I can't say I blame him: in my youth, he may have been right about me.
Today, though, when I'm in the step of making things "better," I want to ensure the code will be maintainable in the future, and that involves everything that code writers are supposed to hate:
- Make sure the code is correct, remove obsolete code from proof of concept.
- Properly document and comment everything that may not be obvious at first reading[^fn-doc].
- Test everything that should be, with comments and documentation when required, too.
That involves a focus on all requirements, functional as well as non-functional[^fn-nfr].
It seems common sense.
So, where does this divergence in our opinions come from?
[^fn-doc]: I was once of the mind that code was its own documentation, but I now know that some natural language comment can go a long way in saving time understanding that code and even prevent from getting it wrong.
[^fn-nfr]: Non-functional requirements are the criteria that can be used to judge the operation of the system rather than its behavior.
For instance, "should respond in less than 500 ms" is a non-functional requirement.
## Management Versus Technical Perspective
When you're a computer service company, you sell a project before it begins at an estimated price.
The whole game is not to overprice it so that the client will trust you rather than the competition, nor to undersell it because realizing it will cost you.
Once it has been sold, the second part of the game is to make sure that it costs is lower than the price you sold it, ensuring some profit.
So, when a young so-called technical expert tells you it works but he still needs to work on it, you think "Hell, I could give this to the client and have him happy, but I'll lose some more money just because of an esthete. If it works, let's call it a day!"
Then, if you're a guy like me (the today me, a bit humbler than the young know-it-all at the time), you don't perceive this additional work as wasted time, just as something that is expected.
Making sure the code can be maintained is not a cost, it's an investment on the future.
Let's imagine that the same client comes back a few years later with some evolution requests.
If we went too fast the first time, adding those will be costly.
A disgruntled developer could even say that the people who wrote the code the first time did a mess of a work.
How frustrating for the client!
They spared no expense and all they got was this lousy ~~T-shirt~~ codebase.
You may lose your image and your reputation of making quality quite quickly.
To sum up, my director focuses on delivering the product as ordered and in time, while I add to this the fact that people will have to work with it, debug it, make it evolve…
In other words, he thinks about user experience now only while I think about both user experience now and developer experience in the future.
## Here Comes the Technical Debt
What's technical debt?
It's something you refuse to do now to save some time.
Basically, you _know_ you should change it, but you have more urgent tasks, so you let it stay for now.
But interests build up: as the time passes, you add code and features based on your not-so-correct basis.
Then, one day may come when you change it, either because you agreed to do it or because you _must_ do it in order to allow for the next feature you need to add.
What's different is that, instead of changing only the incorrect origin, you also need to update everything that was built on it[^fn-tests].
That's what controlling your technical debt is about: ensuring that, if I have to update my software in the future, I won't have a big backlog to update before that.
Note that this quick post doesn't even start to take into account the cost of fixing bugs related to the technical debt.
[^fn-tests]: If you're in this case, I hope you had everything properly tested.
This'll help you detecting possible regressions.
## Don't Go Over
There are such things as over-quality, over-engineering.
_Those_ were what my director was afraid of.
To managers, I advise you make sure of whether your team tries to avoid technical debt or if they just want to go to far because it'd be "better."
To the technicians, always keep in mind you're not writing code for the beauty of it.
You're doing it to achieve a purpose, to serve a functionality.
Don't build an ultra-generic solution that will handle a single case, don't implement a plugin manager for a process that is straightforward…
Don't build a whole power plant if your goal is to light a bulb.
Those are another form of technical debt: code so complex that nobody will be comfortable maintaining it.
If you need something to be done because it's a risk for the future, just explain that to your manager[^fn-politician].
[^fn-politician]: In very rare occasions, they may be more politicians than project managers.
In those cases, deploying new features might be more important to them than mitigating risks.
Once, I warned about three big risks related to technical debt, my product owner said, "You're right, but we need features right now."
A few weeks later, a critical incident came up on one of the risks I had highlighted.
I was highly tempted to let everything burn.
Fortunately, I remembered my teammates and impeded users, and was more constructive than this.
## Illustrating This
Before parting, let's go back to my [usual image][image]: you're building a house.
You can see that a pipe is not how you expect it to be, but you want to hurry and it'll be "good enough" for now, as water still flows.
"Good enough" when you have to deliver means you make as if it's finished: you put the wall and tiles over your pipe.
One day, you'll want to add another sink, or just fix the pipe you know is not correct.
You first need to remove the tiles and plaster, change your pipe, and then put everything back.
But maybe changing what's in the wall forces you to change the wall itself, which in turn may have an impact on the framework…
That's not taking into account all the leaks (bugs) you've had to put up with, in the meantime, just because the pipe wasn't right in the first place.
There's so much more to be said about quality and technical debt, but this post was supposed to be a short one.
If the topic is of interest, we could go deeper in future posts.
The message here is this: postponing the quality or denying the need for it is building up technical debt and its interests, which someone will have to pay someday.
{{< figure src="/img/vincentdnl/technical-debt.png"
link="https://vincentdnl.com/drawings/technical-debt"
alt="An unsatisfied manager complains that it takes time to add a window to a broken house."
attr="Vincent Déniel (CC BY-NC 4.0)"
attrlink="https://twitter.com/vincentdnl" >}}
[image]: {{< relref path="/blog/2021/02/08-metaphor-development" >}}
......@@ -22,7 +22,7 @@
{{- end -}}
{{- if or (.Get "caption") (.Get "attr") -}}<p>
{{- .Get "caption" | markdownify -}}
{{- with .Get "attrlink" }}<a href="{{ . }}">{{- end -}}
{{- with .Get "attrlink" }} <a href="{{ . }}">{{- end -}}
{{- .Get "attr" | markdownify -}}
{{- if .Get "attrlink" }}</a>{{ end }}</p>
{{- end }}
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment