The Unicorn Project

Publié le 07/11/2020

Suite du Phoenix Project dont j'avais parlé précedemment, The Unicorn Project se situe dans la même veine - et dans la même faille temporelle, en fait, puisqu'il s'agit d'une histoire parallèle, se passant au même endroit et en même temps que sa préquelle.

Every company going through a digital transformation needs to make this a must-read for all leaders. -- Courtney Kissler, VP, Global Technology, NIKE Inc.

Dans les points un peu bof (je commence par √ßa, parce qu'il n'y en a pas beaucoup), j'avais l'impression que tous les personnages principaux sont ergod√©pendants et que c'est ce qui leur permet de r√©aliser leurs t√Ęches. Et qu'√† chaque "victoire" ou d√©cision √† prendre, ils finissent tous au pub du coin pour organiser la r√©bellion contre la evil corp qui conduit l'entreprise droit dans le mur. D'un autre c√īt√©, je suppose que d√©crire la journ√©e typique d'un gars qui n'en a rien √† fiche de l'endroit o√Ļ il bosse aurait eu moins de cachet...

Voil√†, c'est fini. On passe aux points plus que plus (les points positifs-√†-mort): l'histoire cible beaucoup plus les pans techniques. Ca y parle de Docker, de container, de bases NoSQL, de mises en cache, de probl√®mes de performances. Dans certains passages, c'est presque plus stressant/prenant que n'importe quel autre thriller. La seule variante est qu'on parle de cycles CPU plut√īt que d'un serial-killer pr√™t √† massacrer une dizaine de coll√©giennes, et qu'on se demande si la ferme va tenir la charge sous l'assaut des utilisateurs. J'en avais les mains moites.

Le livre est en plus bourr√© d'anecdotes, de ressources, d'am√©liorations, et d'id√©aux qui sont bons √† lire (voire, √† suivre). D'histoire, √©galement, notamment o√Ļ on apprend qu'Amazon a d√©pens√© pratiquement un milliard de dollars en six ans pour repenser l'architecture de ses syst√®mes, pour les d√©coupler les uns des autres. En 2013, plus de 136 000 d√©ploiements √©taient effectu√©s chaque jour.

Interesting that these CEOs I mention all have a software background, isn't it ?

Et d'un peu d'humour aussi, quand le barman du pub local vous parle d'isoler les données des titulaires des cartes pour être conformes aux normes PCI.

The Five Ideals

  1. The First Ideal: Locality and Simplicity
  2. The Second Ideal: Focus, Flow and Joy
  3. The Third Ideal: Improvment of Daily Work
  4. The Fourth Ideal: Psychological Safety
  5. The Fifth Ideal: Customer Focus.

R√©sum√©s (tr√®s, tr√®s mal), voici ce que cela donne: se concentrer sur les t√Ęches que l'on r√©alise, en pouvant faire abstraction de toutes les interruptions et des choses non-planifi√©es, permet de les ex√©cuter mieux et plus rapidement que dans n'importe quelles autres conditions (√©crit comme cela, c'est √©vident, mais bon...).

She is able to build things with focus, flow and joy. She had fast-feedback in her work. People were able to do what they wanted without beoing dependent on scores of other people. This is what great architecture enables. [...] In that moment, Maxine decides she must bring this level of productivity that she's helped create for middle-schoolers and her open-source project to the Phoenix Project, even if it means personal suffering in the short term.

Viser une amélioration quotidienne permet également de se sentir mieux, jouer sur la sécurité psychologique (mais les tests unitaires font ça aussi), tout en gardant un oeil sur le client, puisqu'au final, c'est lui le (vrai) chef.

Développements & intégration

Un point qui m'a particulièrement fait sourire concerne l'environnement de travail que Maxine reçoit à son arrivée.

Immediately, she is mystified. She finds links to HR systems, network shares to company resources, links to expense reporting system, payroll, timecard systems, ... She finds Microsoft Word and Excel and the rest of the Office suite.

She frowns. This is fine for someone in finance, she thinks, but not a developer. There are no developer tools or code editor or source control managers installed. Opening a terminal window, she confirms that there aren't any compilers, Docker, Git ... Nothing. Not event Visio or Omnigraffle.

Holy Cow! What do they actually expect new developers to do? Read emails and write memos?

(oui, il y a beaucoup de Holy cows dans le récit)

En bref: normaliser l'environnement de travail. On ne demande pas à ce que tout le monde travaille exactement de la même manière, mais que les outils s'adaptent aux tendances et aux habitudes et que le cadre de travail soit défini.

There are two ways to write code: write code so simple there are obviously no bugs in it, or write code so complexe that there are no obvious bugs in it.

Comme je le disais ci-dessus, il y a plein de bonnes pratiques de développements cachées dans le texte, de la simplification à l'extrême, à l'apologie de la programmation fonctionnelle, aux tests unitaires, à l'intégration continue, aux tests de mises en production... raison pour laquelle je pense qu'il s'adresse plus à un public plus technique.

Et √† propos des syst√®mes de contr√īle de version en g√©n√©ral, et de la frilosit√© √† fusionner du code:

Her best description is having fifty screenwriters simultaneously working on a Hollywood script when they haven't decided who the main characters are, or what the ending will be, or whether it's a gritty, detective story or a bumbling sleuth with a sidekick. They break up the writing responsibilities between all the writers, and each writer works on their part of the script in isolation, typing away in Word for weeks at a time. Then, right before the script needs to be finalized, all fifty writers get together in a room to merge all their work back together into a single story.

... G√©n√©ralement (et bizarrement), √ßa ne se passe pas bien :-D D'o√Ļ le conseil de "cr√©er des petits lots de modifications, o√Ļ chaque d√©veloppeur fusionne ses changements fr√©quemment vers la branche principale. De cette mani√®re, la taille de chaque changement ne peut jamais √™tre trop grande. Ceci cr√©e une fluidit√© dans le flux de travail, sans qu'une perturbation brutale ou catastrophe ne puisse arriver.

Dette technique

There are many definitions [of technical debt], but my favorite is how it was originally defined by Ward Cunningham in 2003. He said, 'technical debt is what you feel the next time you want to make a change'.

There are many things that people call technical debt, but it usually refers to things we need to clean up, or where we need to create or restore simplicity, so that we can quickly, confidently, and safely make changes to the system.

En gros, la dette technique consiste en toutes ces petites choses que l'on laisse derrière soi, et qui doivent être nettoyées ou simplifiées, de manière à pouvoir rapidement, en toute confiance et en toute sécurité, appliquer des changements à un système. On applique le principe du campeur: on laisse l'endroit plus propre qu'il ne l'était en arrivant.

All the tech giants, at some points in their history, have used the feature freeze to massively rearchitect their systems. Consider Microsoft in the early 2000s - that was when computer worms were routinely taking down the internet, most famously CodeRed, Nimda, and of course SQL Slammer, which infected and crashed nearly 100 000 servers around the world in less than ten minutes.

CEO Bill Gates was so concerned that he wrote a famous internal memo to every employee, stating that if a developer has to choose between implementing a feature or improving security, they must choose security, because nothing less than the survival of the company was at stake.

Interestingly, Satya Nadella, CEO of Microsoft, still has a culture that if a developer ever has a choice between working on a feature or developer productivity, they should always choose developer productivity.

Organisation

La toute première partie du livre décrit la manière dont Maxine essaie de construire son environnement de travail, les problèmes qu'elle rencontre, ... Tout ceci touche énormément à la documentation et à la manière dont les employés peuvent retrouver une information qui peut les aider à réaliser leur travail.

A lire entre les lignes, et en plus des cinq idéaux ci-dessus, il y a énormement de messages cachés qui peuvent être extrêmement utiles, pour peu qu'ils soient abordés sous l'angle de la remise en question, et de la question Comment puis-je améliorer mes processus?.

Well, if you put it that way... I'd pay anyone in duffel bags of unmarked bills o get rid of our helpdesk system. Of course, we'll have to get a replacement service, but I'd rather have a vendor managing it anyway.

En clair, il vaut parfois mieux éviter de développer ou maintenir un projet en interne, quand on pourrait le déléguer à un fournisseur externe, qui s'en occupera sans doute mieux. En même temps, la situation décrite ici impliquaient jusqu'à trois fournisseurs qui devaient se coordonner pour n'importe quelle maintenance sur le réseau... Voir le point de Locality and simplicity :-)

Everyone must be responsible for their own safety and the safety of their teammates. If you see something that could hurt someone, you must fix it as quickly as possible.

Et c'est également valable pour l'amélioration au quotidien.

Capability Maturity Model Integration

En parallèle de la lecture du livre, je suis tombé sur un article très intéressant chez Tarek Ziadé: The webapp software development Maturity Model et sur CMMI.

D'apr√®s la d√©finition donn√©e dans le CMMI, la maturit√© d'une organisation est le degr√© auquel celle-ci a d√©ploy√© explicitement et de fa√ßon coh√©rente des processus qui sont document√©s, g√©r√©s, mesur√©s, contr√īl√©s et continuellement am√©lior√©s. (source: Wikip√©dia)

Selon la mod√©lisation CMMI, il y a entre cinq et huit niveaux de maturit√©. Le plus dr√īle √©tant le niveau initial, que l'on peut r√©sumer par "c'est le bordel": pas de standard, rien n'est √©tabli, document√© ou utilis√©. Il n'y a pas de surveillance, pas d'√©valuation de la performance et la communication est absente. Les r√©actions aux incidents se font en mode urgence, sans identification des priorit√©s.

Par soucis de simplification, Tarek propose une modélisation à trois niveaux:

  1. Le premier niveau s'assure que toute personne impliquée dans le développement de logiciels partage la même culture de la qualité et utilise les mêmes outils et standards. Version Control System, bonnes pratiques de développement, style d'écriture du code mis en commun, présence de tests d'intégration et de tests unitaires, et seuil plancher pour la couverture de code.
  2. Le deuxième niveau s'assure de l'automatisation et de l'intégration de chaque modification d'une application. CI/CD, pipelines, peer-reviews, artefacts, ...
  3. Le troisième niveau cible l'amélioration continue, en éliminant miniteusement chaque étape nécessitant une intervention manuelle ou pouvant nécessiter une amélioration. Performances, interventions d'un opérateur, ...

A partir de cet article, il est aussi possible de faire le lien avec ITIL pour les infrastructures et opérations, qui aborde les sujets suivants:

  • Comment organiser un syst√®me d'information ?
  • Comment am√©liorer l'efficacit√© du syst√®me d'information ?
  • Comment r√©duire les risques ?
  • Comment augmenter la qualit√© des services informatiques ?

Ressources (dans le livre)

Et plein d'autres ;-)

Prochaines lectures: Release It (version 2) et The DevOps Handbook.