Avez-vous déjà entendu parler d'une équipe de développement logiciel qui n'aurait pas à faire face à une dette technique?

Moi non plus. De plus:

Les ingénieurs consacrent environ un tiers de leur temps à l'endettement technique, ce qui réduit le moral des équipes et coûte aux entreprises environ 85 milliards de dollars par an.

Stripe d'étude

Pensez-y. C'est 85 milliards de dollars.

Un tiers du temps que les développeurs consacrent à la dette technique. Cela remplit les développeurs d'horreur. En fait, c'est la pire partie de leur travail - et le fait que le reste de l'entreprise ne sympathise souvent pas avec eux ajoute de l'huile sur le feu. Il n'y a personne à blâmer, mais la dette technique est universellement sous-estimée. À cause de cela, les éditeurs de logiciels deviennent lentement raides, jusqu'à ce qu'ils perdent la capacité de croître, ce qui ne nécessite pas des mois et des années pour réécrire leurs applications à partir de zéro ... et une telle période sur le marché aujourd'hui est une éternité.

La dette technique est un phénomène courant, non? Nous commençons à écrire du code, la dette technique s'accumule et boom , cela devient soudain trop. Notre base de code est embourbée dedans, et nous arrivons à la faillite technique. Par conséquent, nous nous battons avec lui. Nous supportons une douloureuse nécessité et payons une partie de la dette. Parfois, nous parvenons à le faire, parfois non. C'est l'essence même du développement logiciel. Nous avons donc tout arrangé.

Mais devrait-il en être ainsi? Y a-t-il des lois fondamentales du développement logiciel qui en sont responsables? Et, dans l'affirmative, pouvons-nous utiliser ces lois à notre avantage? La dette technique est courante, mais elle ne devrait pas être une faillite technique.

Tournons-nous vers divers domaines scientifiques pour obtenir quelques conseils, car les lois de la thermodynamique peuvent nous donner des idées clés pour comprendre pourquoi la dette technique est inévitable.

Les macro-tendances rendent la dette technique inévitable

La première loi de la thermodynamique

Également connue sous le nom de loi de conservation de l'énergie ; prétend:

L'énergie totale du système fermé reste constante; Ils disent que cela persiste dans le temps.

En d'autres termes, l'énergie ne peut pas être créée ou détruite, mais elle peut passer d'une forme à une autre.

Si sans difficultés inutiles, considérons notre base de code comme un système fermé . Nous rejetons les dépendances externes et tout ce qui vit en dehors de notre base de code. Dans ces conditions, il y a un nombre inchangé de développeurs, le développement de fonctionnalités à un rythme constamment élevé - la quantité d'entropie (une mesure du désordre et de l'aléatoire dans le système ) dans notre base de code reste constante.

Nos développeurs ne peuvent pas devenir des surhommes en une nuit, nous ne pouvons donc pas augmenter leur efficacité s'ils donnent déjà le meilleur. Mais nous pouvons embaucher plus de développeurs, ce qui augmente l'énergie dans notre système. C’est pourquoi la loi de Brooks est vraie: «Si un projet ne respecte pas les délais, ajouter plus de main-d’œuvre le retardera encore plus» - car il augmente l’énergie, ou le chaos, dans un système où le chaos est déjà grand.

Les éditeurs de logiciels à croissance rapide sont constamment aux prises avec ce pouvoir. Ils lèvent un cycle d'investissement, doublent la taille de l'équipe de développement aussi vite que le marché du travail le leur permet, et ensuite ils doivent faire face à un grand bond en «énergie» dans leur base de code. Cela dépasse souvent les capacités de l'entreprise et peut entraîner une forte augmentation de la dette technique si des contre-mesures urgentes ne sont pas prises.

Mais attendez un instant. Pourquoi cela conduit-il à une augmentation de la dette technique?

La deuxième loi de la thermodynamique

L'encombrement dans un système fermé ne peut pas diminuer; il ne peut que rester inchangé ou augmenter.

En fait, les systèmes fermés entrent dans un état de plus grand désordre de manière naturelle. Ce «désordre» - que nous avons appelé plus haut «énergie» ou «chaos» - est appelé entropie. Ivar Jacobson et ses collègues ont étudié le phénomène d'entropie dans les bases de code et introduit le terme entropie de logiciels . Lorsque vous modifiez la base de code, son entropie augmente. Cet élargissement du chaos est à l'origine de l'endettement technique.

Revenons à notre société de logiciels à croissance rapide, dont la clientèle continue de croître et le marché est en croissance. Leur équipe de développement en pleine croissance propose des fonctionnalités jour et nuit pour suivre le rythme de la croissance. Si vous ne faites rien, la base de code ne fera que devenir plus confuse. La pression monte.

Je considère la dette technique comme une entropie dans la base de code. Je ne pense pas qu'il disparaîtra jamais, le combat avec lui sera constant.

Ron Pragides , vice-président de l'ingénierie chez Carta

Lors de la planification de chaque sprint, notre entreprise doit faire un choix: y a-t-il quelque chose que vous devez faire pour limiter la complexité croissante ou vaut-il le temps de développer et de fournir de nouvelles fonctionnalités?

La troisième et dernière loi de la thermodynamique précise pourquoi ce dilemme ne correspond même pas étroitement à l'état réel des choses.

Troisième loi de la thermodynamique

L'entropie du système atteint une valeur constante lorsque la température est zéro absolu.

Cela semble compliqué, mais en réalité, c'est assez simple dans son essence, et bien que les lois de la thermodynamique aient des conséquences de grande portée (et parfois simplement écrasantes), leurs principes fondamentaux sont faciles à comprendre. Par exemple, lorsque l'eau prend la forme de vapeur, ses molécules sont «libres» de se déplacer de manière complètement chaotique. L'entropie est partout. Cependant, lorsque l'eau gèle, ses molécules sont «enfermées» et restent en place (plus ou moins). L'entropie diminue et atteint une valeur constante.

Alors, que pouvons-nous faire pour contrôler l'entropie logicielle?

Eh bien, nous pourrions arrêter de développer un nouveau code. Pour cette raison, certaines équipes aiment «geler» le code afin de tester minutieusement leur système avant de le diffuser aux clients. Si la base de code ne change plus, l'entropie n'augmente pas, le chaos aussi, il n'y a plus de conséquences imprévues et la dette technique n'augmente pas.

Cependant, il est impossible de conserver le code figé pour toujours - nous avons besoin de nouvelles fonctionnalités. Donc, la seule option qui nous reste est de refactoriser.

Le processus de refactorisation de code peut aider à éliminer progressivement l'entropie logicielle.
Wikipédia

Une extension gratuite pour VSCode pour vous aider avec cela . Commencez maintenant avant que les choses ne deviennent incontrôlables!

Réduire l'entropie logicielle n'est pas facile

Jusqu'ici tout va bien. En fait, tout cela ressemble à une déclaration de l'évidence; quiconque a entendu quoi que ce soit sur le développement de logiciels connaît tout cela, du moins intuitivement.

Pourquoi la dette technique nous prend-elle encore par surprise?

En effet, même si nous savons qu'il est nécessaire de refactoriser le code pour réduire la confusion, il existe encore une myriade d'autres forces qui prévalent sur nous qui nous empêchent d'allouer le temps et les ressources nécessaires pour effectuer le refactoring correctement et souvent assez. Cela signifie que dans notre base de données et dans toutes les autres, l'entropie des logiciels est en constante augmentation.

Nous connaissons tous la loi de Moore, mais pensez à la version de Bill Gates de la loi de Wirth :

La vitesse du logiciel diminue de moitié tous les ans et demi.
Portes Bill

Je suis convaincu que l'entropie croissante de nos bases de code est le principal moteur de ce modèle.

Le taux de croissance de l'entropie logicielle est directement lié aux taux de croissance de facteurs tels que la technologie, les marchés de logiciels, les éditeurs de logiciels et la littératie en écriture de code - et chacun d'eux se développe sacrément vite.

Source: L'avenir émergent

Imaginez la pression que ces attentes exercent sur les équipes de développement logiciel. Ce sont là de graves tendances mondiales, et elles peuvent être ressenties comme écrasantes par un groupe relativement restreint de personnes. C'est presque comme leur demander de surmonter la gravité et de décoller en agitant les bras.

Images réelles d'une équipe de développeurs luttant contre la dette technique

Dans le prochain article, nous examinerons les microtendances qui nous poussent constamment à la faillite technique, ainsi que la manière dont les éditeurs de logiciels à croissance rapide peuvent les combattre. Reste avec nous!