Gagner n'est pas possible. Vous décidez seulement à quelle vitesse perdre


Quelle est la prochaine étape?

Beaucoup de gens aiment tetris, moi aussi. Je me souviens avoir joué mon ami pour la première fois sur la Nintendo Game Boy. Peut-être que cet air est resté dans votre tête aussi. Tetris n'est pas seulement l'un des meilleurs jeux de tous les temps, mais aussi une grande analogie avec la dette technique. Il fournit une compréhension générale de la dette technique et de son impact.

Je vais vous raconter une histoire d'expérience personnelle sur la façon dont mon équipe a réduit sa dette technique dans une sorte de code de facturation et corrigé en même temps l' erreur d'un million de dollars par an .


Au début, les tâches sont plus simples, avec un faible niveau de difficulté

Dans les éditeurs de logiciels, les chefs de produit / projet, ainsi que les développeurs, déterminent le code qui sera écrit et envoyé aux clients dans la prochaine version. Terminer une ligne dans tetris, c'est comme libérer une fonction.


Les fonctions complexes sont entièrement réalisables avec pratiquement aucune augmentation de la dette technique.

L'émission d'une fonction complexe nécessite l'achèvement de plusieurs lignes .

Souvent, les besoins des entreprises (nouvelles fonctionnalités, nouveaux produits) conduisent à des compromis dans le code (hacks, solutions de contournement), afin de ne pas retarder le délai. Ou les changements dans la stratégie produit sont incompatibles avec la conception précédente, nécessitant des efforts supplémentaires pour migrer les clients ou prendre en charge à la fois la "nouvelle" et l '"ancienne" logique.


Une petite dette technique est normale et gérable.

De tels scénarios créent une dette technique dans le code. Un laissez-passer caché dans Tetris est un devoir technique.

Tout code a un devoir technique. C'est normal. Vous pouvez continuer à jouer avec quelques passes.


Enterré dans la dette technique

Trop de dettes techniques ne permettent pas un délai raisonnable pour libérer une nouvelle fonction ou corriger un bug.

Ce problème ne peut pas être résolu en ajoutant de nouveaux développeurs ou, plus dramatiquement, en remplaçant ceux existants. C'est ce qu'on appelle la dette technique: à un moment donné, elle devra être payée.

Rembourser votre dette technique vous rend compétitif. Cela vous maintient dans le jeu.


Game over

Comme la gestion d'entreprise, dans Tetris, la complexité augmente avec le temps. Les formes bougent plus rapidement et sont plus difficiles à suivre.

Comme en affaires, il est impossible de gagner ici. Il n'y a pas de véritable ligne d'arrivée. La seule question est de savoir combien de temps allez-vous perdre.

Comme pour les entreprises, trop de lacunes dans Tetris entraînent une perte.

Bug d'un million de dollars

Il n'y a pas si longtemps, mon équipe a été chargée de mettre à jour la logique de facturation / facturation dans notre code produit pour prendre en charge de nouveaux plans de tarification, un nouveau processeur de paiement et pour améliorer l'ensemble du processus de facturation dans son ensemble. Certains détails étaient encore en cours de clarification, nous avons donc utilisé ce temps pour approfondir le code existant afin de donner des estimations plus précises des changements à venir.

La tâche principale de ce code était de parcourir les comptes de tous les clients, de calculer chacun d'eux et d'envoyer des informations à l'API pour la facturation. Le système a été écrit avec beaucoup de soin et de bonnes intentions - pas aussi bâclé qu'inflexible. Fonction monolithique . Pas de tests. Très peu de journaux. Il n'y avait pratiquement aucune documentation. Il y avait une randomisation inexplicable. L'un des fondateurs a écrit le système il y a plus de cinq ans. Depuis lors, les seuls changements ont été apportés par l'un des premiers employés déjà absent de l'entreprise.

Y avait-il un problème? Les factures ont été facturées. L'entreprise a fait de l'argent. Il n'y avait aucun signe de problème. Tout cela parlait contre le refactoring, mais nous savions que de grands changements arrivaient: cette fonction ne pouvait pas être adaptée à nos besoins, et il serait beaucoup plus facile de passer à autre chose si nous simplifions cette partie.

Dans un sprint, nous avons repensé la fonction et ajouté des journaux indispensables. C'est alors que nous avons découvert que nous l'avions réellement réparé. L'un des comptables s'est arrêté à nos bureaux et a demandé pourquoi le nombre de factures sortantes avait augmenté de façon inattendue. L'ancien code est tombé discrètement sur la minuterie - et certains clients n'ont pas été traités. Étrange randomisation? Elle a caché tous les modèles qui pourraient indiquer clairement qu'un client n'a pas reçu de facture. Lorsque nous avons effectué l'évaluation, nous avons calculé les factures manquantes de plus d'un million de dollars par an.

Le paiement n'est pas toujours payant

Bien que l'histoire soit complètement vraie, le remboursement de la dette technique n'a pas toujours un effet aussi dramatique. Nous avons de la chance.


Trouver le bon équilibre de la dette technique

Je voudrais donner des conseils avisés lorsque vous devez rembourser une dette technique. Malheureusement, la réponse est que c'est difficile - et cela revient toujours à l'équilibre . Vous pouvez avoir le code le plus propre et le plus testé au monde, mais pas de clients. Et vice versa, votre entreprise peut travailler avec un code vraiment sale, mais qui plaît aux clients, et l'argent coule comme une rivière.

Je peux seulement dire que les propriétaires de produits et les développeurs doivent comprendre l'essence de la dette technique et qu'elle ne peut pas être évitée pour toujours. Au final, comme à Tetris, ici on ne peut jamais gagner.