Note de lecture : Joel on Software, par Joel Spolsky

Note : 8 ; Inclassable, instructif et passionnant.

Aussi surprenant que cela puisse paraitre, ce livre est simplement la compilation des « posts » de Joel Spolsky sur son blog « Joel on Software ». Les textes n’en ont pas été retouchés, ni rallongés pas plus qu’ils n’ont été agrémentés. Ils ont simplement été mis en page, rassemblés en un livre avec table des matières, index, couverture, relire et tout et tout.

Donc ce que vous pouvez acheter sous forme de livre, vous pouvez le lire gratuitement sur le net ! Le livre, justement, couvre 45 posts regroupés en 4 parties (la 5ème est consacrée aux annexes). Les posts sont ainsi regroupés de manière thématique et la taille de ces parties est en conséquence inégale. La première partie va aussi s’avérer la plus longue. Elle regroupe 19 posts et cible les pratiques de développement (au sens large). 3 sujets ont attisé ma curiosité ici. La série de 4 posts sur les spécifications, d’abord. Elles contiennent les germes de la définition du PO mais révèlent aussi un point de vue pour moi dépasser : écrire pour limiter la communication entre les intervenants, et gagner en efficacité ! Le second sujet a trait au craftsmanship. Il est la prémices du mouvement du même nom, même si l’auteur ignore encore (ou volontairement ?) la culture agile naissante. Le troisième sujet est marginal et évoque le « biculturalisme » chez Microsoft. Un sujet qui explique bien des choses sur la société.

La seconde partie est consacrée à la gestion des développeurs et est riche de 9 posts. Le plus célèbre, et très souvent référencé encore aujourd’hui est « The Law of Leaky Abstraction ». Cette loi stipule qu’une abstraction de haut niveau, destinée à masquer une réalité de plus bas niveau, montrera des failles ou des faiblesses dans certaines conditions. Le corolaire de cette loi est qu’on ne peut se contenter de connaitre cette abstraction de haut niveau, mais qu’il est nécessaire de connaitre voir de maitriser le niveau sous-jacent, car il expliquera certains comportements de cette « abstraction qui fuit ». Je conseille aussi deux posts consacrés au recrutement et à la rémunération. Vous n’êtes pas obligés d’être d’accord avec l’auteur, mais au moins donnent-ils à réfléchir.

Lire la suite

Note de lecture : Operations Anti-Patterns, par Jeffrey D. Smith

Note : 3 ; Verbeux et ennuyeux

La juxtaposition de « patterns » (ou anti-patterns) et devops avait tout pour attiser ma curiosité, bien que j’avoue avoir quelque peu foncé en aveugle sur ce livre. Comme nous le verrons, cela ne fut pas une très bonne idée car le texte prétend parfois avoir inventé l’eau chaude…

Avec 290 pages structurées en 12 chapitres, ce volume se situe dans la moyenne, la taille des chapitres aussi et ceux-ci ne sont pas trop longs. Le livre s’ouvre sur un premier chapitre « what is devops » plutôt sympathique à lire qui évoque le CAMS (culture, automation, metrics et sharing) comme les piliers du devops. C’est original par rapport à mes autres lectures, mais l’éclairage en vaut un autre. Le second chapitre est plus représentatif des chapitres suivants, c’est-à-dire un thème accompagné de patterns et d’anti-patterns. Ici il est question de « paternalisme ». Derrière cela il faut voir le mode guichet et les délais que cela occasionne. La solution promue est évidemment l’automatisation embarquant les vérifications automatisant « l’approbation ». Rien de bien nouveau.

Le thème du 3ème chapitre est la cécité opérationnelle : c’est-à-dire qu’opération et développement vivent chacun dans leur silo et que le développement ignore tout du comportement du produit en production. La solution est ici, cher captain obvious, les métriques et les logs ! Le développement part un peu dans tous les sens et reste hélas assez superficiel. Le chapitre 4 s’intitule « des données plutôt que de l’information ». Ce chapitre se démarque un peu des précédents en ne suivant pas la recette désormais habituelle. Il s’inscrit plutôt dans la continuité du chapitre 3 en évoquant la présentation des données de monitoring. C’est un peu inutile ou plutôt mieux traité ailleurs.

Lire la suite