Note de lecture : Beyond Legacy Code, par David Scott Bernstein

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Beaucoup de verbiage et peu d’illustration

Une nouvelle déconvenue, je dois bien l’avouer. Non pas que le style de l’auteur soit mauvais, il est plutôt tonique avec de bonnes qualités de « story telling ». Non pas qu’il n’ait rien à dire, bien au contraire : il transparait du texte une maîtrise, une compréhension et une solide vision de son sujet. Non, l’auteur échoue à développer convenablement son sujet, à l’appuyer sur de solides exemples. Au lieu de cela, il semble préférer discourir en se servant du texte comme une tribune. Pourtant le contenu est au coin de la rue, il ne demande qu’à se révéler : ce sont les 9 principes qui constituent l’essence de l’ouvrage.

L’ouvrage, justement n’est pas excessivement volumineux, avec ses 230 pages. Mais attention : il s’agit exclusivement de texte ! Il est découpé en 2 parties très inégales, la première servant d’introduction avec 3 chapitres sur 40 pages, la seconde développant les 9 pratiques sur le reste du livre.

La première partie s’ouvre sur le triste constant du code legacy et de ses causes : une industrie d’amateurs comme le dit l’auteur. Rien de vraiment neuf, mais c’est bien écrit et guère ennuyeux. Le second s’attaque sur une douzaine de pages au fameux CHAOS report, mais de façon critique, ce qui est assez original, et pertinent en l’occurrence. Mais c’est aussi pour dire qu’il partage les conclusions, mais pas l’analyse. Enfin cette 1ère partie se referme sur un petit chapitre introductif à la seconde partie (les 9 pratiques) et comme quoi notre focus sur l’agile nous a fait perdre de vue la nécessité de solides pratiques de conception (ou d’ingénierie) qui en forment les fondations. Je suis bien d’accord.

Lire la suite →

Publicités

Note de lecture : How to Make Sense of Any Mess, par Abby Covert

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Puzzle de réflexions à assembler soi-même.

Abby Covert est « information architect ». Cet opuscule a pour but de nous livrer la substantifique moelle de ce que l’auteur considère comme l’essence de l’architecture d’information. Il mérite le qualificatif d’opuscule par sa brièveté : moins de 160 pages de petit format, avec un concept par page (soit environ 1 minute ou 2 de lecture chaque fois). L’ensemble est structuré en 7 parties.

La première d’entre-elle « Identify the mess » occupe 18 pages. Ce chapitre est lui-même un peu le bordel. Abby Covert s’interroge sur la nature de l’information (ni de la data, ni du contenu) et sur la complexité (de l’information, des utilisateurs…). Bref, beaucoup de choses forment le « mess ».

Le second chapitre couvre nos intentions sur 15 pages. Il s’agit presque d’un mini-traité de coaching. L’auteur cherche à nous aider à décrire ce que « bien » veut dire pour nous. Pour enchainer sur le triptyque « Pourquoi » – « quoi » – « comment » connut des lecteurs de Simon Sinek. J’ai toujours du mal à raccrocher cela au sujet du livre.

Lire la suite →

Note de lecture : Scrum, pour une pratique vivante de l’agilité 5ème édition, par Claude Aubry

Le par addinquydans Notes de lecture2 commentaires

Note : 6 ; De nouvelles idées et de nombreux remaniement pour un texte qui continue (hélas) de privilégier les saisons aux itérations courtes et les fonctionnalités regroupant les user stories.

Les éditions du livre de Claude Aubry se suivent et incarnent pour moi le changement dans la continuité. Nous en sommes déjà à la 5ème édition. Je les ai toutes lues, chacune d’entre-elle du début à fin et non pas en diagonale. Car l’auteur se fait un point d’honneur à faire véritablement évoluer son texte à chaque édition et ne se contente pas d’un simple changement cosmétique.

Le livre reste sur une structure de 22 chapitres, mais fait un bond de 294 à 343 pages ! Le premier chapitre compte une quinzaine de pages (contre 14 précédemment). Il fait toujours un bon boulot (en léger progrès même) pour situer Scrum et le mouvement agile. Quelques changements non anodins aujourd’hui, dont l’évocation de la systémique. Le second chapitre traite des sprints et prends 5 pages d’embonpoint. Et l’auteur d’évoquer des « saisons » en lieu et place des releases, en ajoutant des notions de prélude et d’interlude. Tout ceci prend des odeurs de SAFE, et ce ne sont pas de bonnes odeurs pour moi.

Place au chapitre 3 qui a changé de titre et parle de « sublimer l’équipe ». Pas mal de bonnes choses dans ce chapitre qui a pris aussi quelques pages au passage, avec l’ évocation de « The People’s Scrum » et l’heureuse disparition à la référence « Exploring Scrum », mais je trouve la métaphore de la permaculture compliquée et peu convaincante. Des remaniements également au chapitre 4 sur ce chapitre consacré au Product Owner, qui n’était pas mauvais et le reste. Par contre, l’évocation de la permaculture, ce n’est toujours pas ça.

Lire la suite →

Note de lecture : The Tao of Microservices, par Richard Rodger

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 2 ; Une vision “nano composants” bien éloignée de celle de Sam Newman et Martin Fowler…

Certains livres doivent se lire vite, pour que la douleur ne dure pas trop longtemps. Comme pour l’arrachage d’une dent ! Pour commencer, le livre est une tromperie sur la marchandise : point de microservices selon Fowler ou Newman, ici il s’agit d’une architecture crée par l’auteur. Comme elle est différente des autres, il l’appelle « 2.0 », les autres c’est 1.0 ! En fait ce n’est d’ailleurs pas simplement une architecture, mais selon l’auteur la solution ultime et définitive au développement logiciel, sur les plans techniques et organisationnels.

Car sur le plan technique, l’auteur fait la peau à tout ce qui est différent de sa solution au chapitre 1. Selon lui, la conception objet produit de grosses hiérarchies de classes trop couplées et incompréhensibles… libérons-nous de cette escroquerie. L’approche guidée par les tests est un écran de fumée tandis que les approches agiles obligent les équipiers à ce parler pour compenser le couplage de leur conception. Enfin le « don’t repeat yourself » est contre-productif, pour ne pas le qualifier de sabotage. J’en passe encore quelques-uns mais on aura compris l’idée : tout ce que l’auteur n’a pas su faire marcher ne marche pas pour la totalité des mortels. Bien sûr son architecture, à l’image des potions-miracle du far-west, adresse la totalité de ces problèmes sans aucuns inconvénients.

Tout ce bashing couvre une bonne partie du chapitre 1 de ce livre de près de 300 pages qui en compte 9. Mais pas seulement, on en trouve aussi dans les autres chapitres. En fait les différents chapitres tendent à se ressembler pas mal (à l’exception de l’étude de cas du chapitre 9), il n’est donc pas très utile de les passer tous en revue.

Lire la suite →

Note de lecture : Kanban, par David J. Anderson

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Une vue très acérée mais aussi un poil mégalo de Kanban par son créateur.

David Anderson est le créateur du Kanban dans l’IT. Croyez-moi, à la lecture du livre, c’est une information que vous ne pouvez pas rater. Mais au-delà de cet aspect mégalo, il faut aussi admettre que ce texte nous donne l’essence du Kanban, comment David Anderson a repris cette technique industrielle pour en faire un outil d’amélioration dans le cadre IT.

L’ensemble du texte totalise 240 pages structurées en 20 chapitres. Ceux-ci sont rassemblés en 4 parties. La première d’entre-elle sert d’introduction et se contente de deux chapitres sur 20 pages. Elle débute par le « dilemme du manager agile » qui occupe juste 8 pages : c’est la quête de l’auteur pour une approche satisfaisant sa nécessite d’adaptation et sa volonté d’amélioration qui ne trouve pas de réponse dans les méthodologies pré-câblées. Le point de départ sera le « drum-buffer-rope » de Goldratt pour aboutir à Kanban. Le narratif est d’excellente qualité, on y suit bien la démarche de l’auteur. Le second chapitre n’est guère plus long pour nous décrire ce qu’est la méthode Kanban. Comme point de départ, David Anderson nous raconte sa visite dans un parc japonais où on lui avait donné une carte à l’entrée… il comprendra plus tard qu’il s’agissait d’une limite de WIP. De là, l’auteur déclinera les 5 propriétés d’un kanban :

  • Visualiser le flux de travail.
  • Limiter le travail en cours
  • Mesurer et gérer le flux.
  • Rendre les règles explicites.
  • Utiliser le modèle pour reconnaitre les opportunités d’amélioration.

Lire la suite →

Note de lecture : Fire in the Valley 3rd edition, par Michael Swaine & Paul Freiberger

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Les petites et grandes histoires du début de la micro-informatique racontées et témoignées de manière passionnante.

C’est un livre d’histoire. D’histoire contemporaine pour être plus précis, qui couvre essentiellement le début des années 70 jusqu’au début des années 90. Ou devrais-je plutôt appeler cela une épopée : celle de la naissance du micro-ordinateur, jusqu’à sa banalisation qui coïncida avec l’avènement d’Internet et la banalisation des micro-ordinateurs devenus objets de grande consommation.

Ce n’est pas une lecture légère : le livre au format classique des ouvrages d’informatique concède près de 380 pages mais presqu’exclusivement de texte. Ramené au format classique, on est plutôt entre 500 et 600 pages. Fort heureusement, c’est fort bien écrit, les auteurs ont de réels talents de story tellers. Normal me direz-vous, pour des journalistes.

L’ouvrage est organisé en 10 chapitres, qui sont donc chacun assez conséquents. Ils ne suivent pas un ordre strictement chronologique, mais sont plutôt thématiques. Ces thèmes étant quand même séquencés globalement chronologiquement.
Le premier chapitre, déjà est un régal. Il nous emmène sur une trentaine de pages, depuis la machine de Babbage jusqu’au CP/M et aux premiers hacks de Bill Gates. En fait, les 5 dernières pages mangent déjà un peu sur la suite du livre. Je me serais bien arrêté à l’Eniac. Le véritable démarrage de l’épopée est au crédit du chapitre 2 : la naissance, la gloire et la mort de l’Altaïr. Même s’il n’est pas le premier micro-ordinateur (un privilège qui revient au Micral Français). A l’Altaïr succède (ou suit) IMSAI, puis l’auteur se tourne vers les geeks, plus précisément le Homebrew Computer Club, son apôtre de la contre-culture, Lee Felsenstein et ses membres de la première heure tels que Steve Wozniak. Plus que tout autre, c’est lui qui sera à l’origine du foisonnement de hobbist et de petits constructeurs artisanaux en tout genre dans la seconde moitié des années 70.

Lire la suite →

Note de lecture : The Mikado Method, par Ola Ellnestam & Daniel Brolund

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 2 ; Que de remplissage !

Les auteurs ont découvert un bon truc pour refactorer du code legacy. Une technique à la fois simple et pratique, donc réellement bonne. Et ils ont voulu en faire un livre. Seulement voilà, parce qu’elle est simple, cette technique tient en 20 pages, guère plus !

2 parties totalisant 7 chapitres sur 140 pages constituent le corps de l’ouvrage. La première partie « The basics of the Mikado Method » se satisfait de 4 chapitres avec 65 pages environ. On ouvre le bal avec « meet the Mikado method ». En fait, tout est dit, ou presque, dans ce premier chapitre d’une quinzaine de pages. La démarche en fait très simple (c’est sa qualité première) est décortiquée pas à pas. La seule chose qui manque est un exemple. C’est ce que l’on escompte avec le chapitre 2 « hello, Mikado Method ». L’exemple est hélas un peu simpliste, mais la vingtaine de pages illustre un peu tout, y compris le « revert » à l’aide d’un petit exemple en Java. L’utilisation du gestionnaire de version, partie intégrante de l’approche, fait partie du lot. Il y a déjà pas mal de répétitions avec le chapitre précédant, mais cela reste intéressant.

Le chapitre 3, « goals, graphs and guidelines » est là pour nous donner un peu de recul sur ce qu’est un bon objectif de Mikado. C’est très abstrait et ne nous emmène pas très loin. Au chapitre 4, les auteurs explorent des variations de l’approche Mikado avec « Organizing your work ». En l’occurrence ils déclinent l’approche Mikado en isolation, en pair et en équipe. L’aspect « équipe » rappelle un peu le « Mob Programming », mais il ne m’apparait pas évident que la mise en œuvre ait été sérieusement expérimentée… Cela conclut la première partie du livre.

Lire la suite →