A very interesting article about dealing with problems at work.

It also reminded me about :
https://dilbert.com/strip/2016-03-30
https://dilbert.com/strip/2020-01-29

'BUY' ALMOST ALWAYS BEATS 'BUILD' : If you can avoid building something, you should. Code is the most expensive way to solve a problem that isn’t addressing a core area of your business.

MAKE DEPLOYS EASY : Deploying should be a frequent and unexciting activity. Engineers should be able to deploy with minimal manual steps and it should be easy to see if the deploy is successful. (...) It’s not a coincidence that two of the four key metrics that the book focuses on are directly related to this (Deploy Frequency, Change Lead Time). Shipping is your company’s heartbeat.

TRUST THE PEOPLE CLOSEST TO THE KNIVES : The people who work with a system are the ones who understand it best. (...) They should, therefore, be the primary stakeholders responsible for prioritizing technical work.

BORING TECHNOLOGY IS GREAT : (...) you want a wide area of expertise for routine operations and when shit goes sideways (...). Very few organizations have the bandwidth to debug unique problems. (...) Using boring technology means you can lean on a large community of users. Shit on it all you want, but there are very few PHP issues that someone else hasn’t already encountered.

Plein de bons conseils, malheureusement souvent mis en pratique :-/

L'ensemble de l'article est aussi vrai que drôle.
Mention spéciale à cette phrase qui a un petit goût de "j'ai-déjà-vu-ça-quelque-part" :

Dans le désordre tu peux obliger tout le monde à travailler minimum 60 H par semaine. Quand les gens n’auront plus de vie personnelle, c’est avec plaisir non dissimulé qu’ils vont chier à l’intérieur de ton projet.

La vérité dans tout ça, c'est que les gens ne savent pas ce qu'ils veulent jusqu'à ce qu'on leur propose.

L'unique façon de vérifier que son idée est bonne, c'est vendre.

Les gens arrêtent de mentir quand on leur demande de l'argent.

Pour ça, la stratégie consiste à créer du contenu tout en donnant la possibilité d'acheter notre produit.

Il existe un terme populaire dans le monde des startups qui résume bien cette stratégie : "Fake it until make it".

Les différents types de spécifications :

- la spécification exhaustive : claire, concise, illustrée d'exemples (autant que nécessaire) et de schémas explicatifs, elle précise tout ce qui est attendu de manière non équivoque. Chaque information y est indiquée une (et une seule) fois, et peut être retrouvée très facilement via l'organisation logique du document et le sommaire clair. Les mentions "TBD" et "TODO" en sont absentes. Cerise sur le sundae : elle a même une table d'acronymes grâce à laquelle il devient évident que le "PTDR ne peut pas être XPT à cause du DDIG". Elle a, de plus, le bon goût d'être à jour par rapport à ce que veut réellement le client.
NB : de même que les fées, korrigans et autres elfes, la spéc exhaustive est un artefact qui n'existe que dans votre imagination.


- la spéc "Post-it" : elle a le mérite d'être courte (c'est le seul !). Pour le reste, il va falloir deviner ou bien entrer dans le ping-pong de l'enfer avec le client et lui tirer les vers du nez pour avoir une idée de ce qu'il attend de nous --tout en déplorant notre manque d'autonomie (voir "spéc en chapelet"). Rencontrée en moyenne dans UN projet sur UN.


- la spéc "en chapelet" : ce type de spéc connaît de nombreuses variantes. Elles sont toutes caractérisées par une succession de micro-suspenses (maîtrisés ou pas), permettant, à chaque itération de "gagner" une nouvelle information permettant aux développeurs de faire leur travail.

- variante : spéc "en chapelet typée ping-pong" (ou "chapelet - jeu de piste") : c'est un peu comme une enquête policière, où chaque indice conduit au suivant, et où chaque question engendre une nouvelle question (dont la réponse est évidente pour celui qui aurait dû vous la donner). C'est une succession de mails en question / réponse, entrecoupés de temps d'attente improductifs, puisque les informations requises sont dans la tête du client, qui n'a "pas qu'ça à faire de répondre à vos mails" étant donné qu'il passe 95% de son temps en réunion.

- variante : spéc "en chapelet typée boule de neige" (ou "chapelet - réaction en chaîne") : le flou grandit à chaque itération et chaque réponse appelle 2 nouvelles questions. Auxquelles on aura peut-être une réponse, mais pas garanti. Explosion du niveau de stress des dév et du délai de livraison.

- variante : spéc "en chapelet aux amEndes" : la spéc est mise à jour plusieurs fois pendant le projet alors qu'on n'a posé aucune question.
NB1 : ce type de fonctionnement est typique des procédés "Agile", où l'on se doit d'être ouvert au changement. Si une nouvelle version de la spéc ajoute de nouvelles fonctionnalités sans remettre en question TOUT ce qui a été fait jusqu'ici, il est possible qu'on soit effectivement dans le cas d'un projet Agile. Dans ce cas, la spéc "en chapelet aux amEndes Agile" n'est pas un motif valable de sévices tels que :
- fouettage avec un câble Wi-Fi
- arrachage d'oeil avec une touillette à café en plastique
- mort par décès
- chanson de "la Reine des neiges"
- Windows Millenium
NB2 : il est fréquent que les clients croivent (croillent ?) être "Agile" alors qu'en pratique ils ont juste envoyé 27 brouillons successifs et contradictoires de leur spécification. La spéc "en chapelet aux amEndes multi-révisée" autorise les sévices décrits ci-dessus (homologation par l'ONU en cours).


NB1 : bien que la spéc en chapelet valorise le client (puisque sans lui le projet n'avance pas), au-delà d'un certain nombre d'allers-retours, le client s'irrite de nos questions incessantes, met en doute notre compétence (ce qui renforce la bonne ambiance générale de l'équipe en plus de faire avancer le schmilblick), et on finit _vraiment_ par se demander si on serait pas "un peu c*n sur les bords". Il faut savoir que, de même que la gravité cause la chute de pommes sur la tête de scientifiques Britanniques, la spéc en chapelet cause l'enlisement de la tâche qu'elle décrit et l'explosion du délai de livraison (c'est une loi physique, faut faire avec).

NB2 : Conformément à la loi de Murphy (et son corollaire sur les processus mal emmanchés), les spécs de type « Post-It » accouchent généralement de spécs « en chapelet ». Une estimation honnête de la date de réalisation est donc « un jour ou l’autre ».


- la spéc "OCB" : variante de la spéc "Post-it" en plus court. Mêmes effets.


- la spéc orale : "Comment ça, y'a pas de spéc ? M'enfin, le café que je t'ai offert il y a 3 semaines pour parler du projet, c'était ça, la spéc ! Je pensais avoir été clair. Donc, si je comprends bien, t'as rien noté ? Put**n, t'es vraiment un boulet !!!"
NB : à ce point, l'envie de meurtre (ou de crevage d'yeux avec une touillette à café en plastique) est naturelle mais déconseillée à cause de complications administratives de type "prison". Étant donné que "les paroles s'envolent", la spéc orale est comme la cuiller dans Matrix : elle n'existe pas ;-). Pas plus que la demande ou le ticket décrivant la tâche à réaliser puisque c'est là que devrait se trouver la spéc. Pas de date de début à ce point non plus, donc les compteurs de délai et de "ce-sera-en-prod-quand?" restent bloqués à zéro. Je conseille donc une attitude non-violente de type "C'est vous qui voyez !" (cf "Le train pour Pau" de Chevallier et Laspalès)

"Cleaner" does not mean "more efficient" : have a look at the urban planner's dream pizza to get the idea (well, read the article too ;-)

Scott’s Law: never put order in a system before you understand the structure underneath its (apparent) chaos.

I having the feeling that some projects at my current company have secret constraints like this book had ;-)

Good advice (and common sense) about writing efficient + useful emails.

IMHO, the best email (like the best comment in programming) is the one you need not writing. Instead use other dedicated tools : question code in GitLab (or equivalent), ask for clarification in issue trackers, and don't use emails for instant messaging. Also avoid "Ok, thx" in "Reply to all" ;-)

NB : I'm not a big fan of emails anyway. Most of the time, information is missing, people are forgotten in the recipients list, and any communication that could be done easily gets complicated by the misuse of email.

In fact, the overall health of the code base probably has a bigger effect on developer productivity than all developers' skills combined.

But even more important than technical issues are things that promote healthy team dynamics. These include things like blameless postmortems, openness to ideas from everyone, permission to try new things even if they may fail, stern weeding out of jerk behaviour and, ultimately, trust.