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 #
- The First Ideal: Locality and Simplicity
- The Second Ideal: Focus, Flow and Joy
- The Third Ideal: Improvment of Daily Work
- The Fourth Ideal: Psychological Safety
- 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:
- 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.
- 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, …
- 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) #
- Open Source is the Best Insurance for the Future: Eddie Satterly Talks About IAG
- What people think programming is vs. how it actually is
- The PMO is Dead, Long Live the PMO - Jon Smart, Barclays - We are living a turning point, avec une série d’anti-patterns en termes de production.
- How Your Systems Keep Running Day After Day - John Allspaw - All work is contextual
Et plein d’autres ;-)
Prochaines lectures: Release It (version 2) et The DevOps Handbook.