Note de lecture : Beginning SQL Server 2005 for Developpers, par Robin Dewson
Note: 7 ; LE livre pour bien débuter avec SQL Server 2005
Attaquer une « grosse » base telle que SQL Server 2005 quand on n’a pas l’expérience de tels environnements n’est pas évident. Paramétrage, gestion des bases, exploitation et administration sont autant de sujets à découvrir autant sous l’aspect du « quoi » que sous l’aspect du « comment ». Ce livre répond parfaitement à cet objectif. En tout cas, il a bien marché pour moi. Il fait un tour d’horizon complet de la base de données en introduisant chacune de ses facettes, en expliquant par l’exemple comment faire, aussi bien avec les outils interactifs qu’avec le T-SQL. Bref, on est mieux armé à la sortie, et l’on sait dans quelle direction aller sur chacun des sujets, prêt à approfondir plus avant chaque sujet dont on a le besoin.
Les deux premiers chapitres présentent l’architecture de la base, ses options d’installation et le « management studio » qui est l’outil interactif permettant d’accéder à la plupart des fonctionnalités de la base.
Le chapitre trois nous guide pour ce qui est de la création des bases, les différentes options possibles et donne des clés pour configurer une base optimale en termes de performances.
Le chapitre 4 est consacré à la sécurité et à la gestion des utilisateurs. Il présente clairement les différents modes d’authentification et donne des conseils pragmatiques quand aux configurations à adopter, surtout pour les bases d’exploitation. Un sujet habituellement aride, traité ici avec pragmatisme et intelligence.
Les chapitres 5 et 6 sont dédiés au design des bases : création de tables et d’index. Là encore, on a une information détaillée et précieuse, même si le chapitre 6 ne s’avère pas si clair que ça.
Le chapitre 7 est consacré à l’administration : les procédures de backup et de maintenance. On y trouve juste ce dont on a besoin : Les clés pour assurer la mise en place de procédure de gestion classiques de sauvegarde et de maintenance. Indispensable !
Avec les chapitres 8 à 13, on aborde le gros de la troupe : travailler avec T-SQL. Même si le langage a été abordé avant pour la mise en œuvre des différentes fonctions dans ce langage, c’est de manipulation de données dont il est question ici ! Le chapitre 8 nous donne le bagage de base pour traiter les données : select, update et delete avec les différentes clauses de base. Le chapitre 9 traite d’un sujet plus pointu : les vues. Hélas ce n’est pas le meilleur chapitre du livre. Les procédures stockées (comment y échapper ?) sont couvertes par le chapitre 10. Même s’il manque pas mal de briques pour faire tout ce que l’on souhaiterait, on a de quoi démarrer. Les chapitres 11 et 12 terminent le tour d’horizon du T-SQL d’abord en le balayant en largeur, puis en abordant les aspects moins usités du langage. J’avoue avoir largement décroché au chapitre 12 (et aussi un peu au chapitre 11). Le chapitre 13 clos l’affaire avec les triggers et des conseils fort pertinents quand à leur usage.
Un peu en décalage, le chapitre 14 aborde Reporting Service. Il nous permet de désirer en savoir plus, car le traitement qui en est fait ici est vraiment superficiel.
Bref, voilà un ouvrage qui, en 400 pages, nous permet d’avoir une vue globale de l’outil, et m’a permis de porter mon attention sur ce qui était mal fait ou pas fait sur la façon dont nous l’utilisions. Sous cet angle, il a déjà dix fois justifié son achat, et je sais qu’il continuera encore à me rendre service.
Le problème inhérent aux livres liés à des technologies particulères est qu’il vieillissent à la vitesse de celles-ci. Cet ouvrage a déjà connu deux mises à jour, pour SQL Server 2008 puis SQL Server 2012 (que je n’utilise pas encore). La troisième édition a d’ailleurs enflé jusqu’à 700 pages ! Cela voudra certainement dire une petite mise à jour dans un avenir certainement pas trop lointain.
Référence complète : Beginning SQL Server 2005 for Developpers, from novice to professional – Robin Dewson – Apress 2006 – ISBN : 1-59059-588-2 ; EAN : 978 1 59059 588 6
En finir avec la roadmap !
Je vous l’avez promis il y a peu, voici le premier opus de mon feuilleton “en finir avec…”. Ma victime du jour est la roadmap.
Avant que vous commenciez cette lecture, un mot d’avertissement. J’ai écrit le texte qui suit avec l’intention qu’il soit lu de façon critique. Ne prenez pas ces idées ou ces points de vue pour argent comptant. Utilisez-les comme source de réflexion pour vous forger votre propre réflexion.
C’est bien sûr vrai de tous les textes que l’on peut être amené à lire, mais ça l’est encore plus ici !
La roadmap qu’est-ce que c’est ?
Ce terme est utilisé en informatique de manière assez libérale. Il peut concerne aussi bien un projet, qu’un ensemble de projet, une stratégie business et beaucoup d’autres choses encore. Je vais m’intéresser ici à la roadmap d’une organisation de développement. Elle est souvent relative à un portefeuille de projets, comme on le verra.
Mais au fond, que va-t-on attendre d’une roadmap ? Ou du moins, qu’est-ce que moi, je vais en attendre ?
Principalement une certaine perspective d’avenir, capable de me montrer les orientations des mois à venir. Je suis réaliste, je sais bien que :
- Plus on se projette dans le futur, plus le niveau d’incertitude est élevé. En un an, beaucoup de choses peuvent se passer en terme d’évolution du marché, d’opportunités business, etc… Je considère même que c’est un signe de bonne santé de l’entreprise, du moins tant que l’on ne confond pas évolution de la stratégie et atermoiement.
- Qu’un changement majeur de stratégie (un “pivot” dans le langage Lean Startup) peut totalement remettre en cause cette perspective à un moment donné.
- Qu’il n’est ni utile ni raisonnable de chercher à étoffer cette projection de détails que l’on n’a pas encore et qui seront peut-être obsolètes au moment où l’on traitera le sujet.
Bref, quand on va me parler de roadmap, je vais penser à quelque chose comme cela
En clair : une direction, avec des jalons représentant des niveaux d’accomplissements, mais aussi des dates en dur représentant des contraintes opérationnelles : engagements divers contractualisés, salons, etc…
Le syndrome de la roadmap de projets
Dans les faits, nous allons plutôt devoir composer avec un plan établi sur la base d’une liste de projets priorisés et planifiés en fonction de notre capacité de travail afin d’optimiser celle-ci en l’utilisant au mieux.
Peut-être aurez-vous remarqué le début d’une pointe d’ironie ?
Peut-être aussi, si vous avez suivi des posts et présentations plus anciens que j’ai pu faire, vous dites-vous que j’ai défendu ce même concept de roadmap il n’y a pas si longtemps ? Je l’avoue dès maintenant : mes idées ont sinon changé, du moins pas mal évolué. J’assume.
Le problème avec cette occupation optimisée de la capacité de travail, c’est que la roadmap ressemble désormais à ça:
On peut faire pire. Il y a une variante de la roadmap de projets appelée “roadmap matricielle”. En voici une vue d’artiste (vous remarquerez les “jolies couleurs”, partie intégrante du concept).
La roadmap matricielle présente une certaine élégance et peut donner l’apparence d’une maîtrise plus pointue du sujet. Après tout, il faut être plus intelligent pour appréhender les choses en deux dimensions qu’en une seule, non ? Cela bien établi, on se demande pourquoi personne n’a encore eu l’idée de réaliser des roadmaps tridimensionnelles ! La difficulté de rendre cela sous Powerpoint, j’imagine …
En réalité la roadmap matricielle amplifie les travers de la roadmap de projets :
- Plus d’embouteillage : ce n’est plus une file de projets qui en en attente mais une série de files d’attentes ! L’image du péage de Saint Arnoult s’impose à moi !
- Alignement des ressources avec le plan. Il est bien facile d’ajouter une ligne à une matrice. Mais qu’en est-il des équipes de développement ? La pratique montre qu’elles sont rarement dimensionnées en conséquence. Souvent cela se traduit par du temps partagé de développeurs (un désastre) ou des équipes de développement fractionnées pour atteindre des tailles d’une ou deux personnes pour certaines d’entre-elles…
- Pas de focus stratégique. On attend d’un comité de direction qu’il donne justement une direction ! Que peut-il faire quand il est incapable de mener à bien sa mission première ? Il peut ne pas décider de direction stratégique et clamer que “toutes les directions sont prioritaires”. La roadmap matricielle traduit cela.
Qu’elle soit matricielle ou non, la roadmap a des conséquences dont nous allons nous rendre compte qu’elles sont des effets de bord de son existence même. Ce sont pour la plupart en fait des effets psychologiques.
Conséquences, conséquences
La persistance dans l’action
L’une des vertus de la roadmap est de montrer que derrière le projet en cours, il y a un ou plusieurs projets en attente. En principe c’est un bienfait, ce n’est même pas complètement négatif, même si je vais prétendre l’inverse dans deux secondes.
Mais concentrons-nous sur notre projet en cours.
Etant agile, vous savez que l’intérêt d’un projet ainsi réalisé réside dans le feedback, l’émergence de nouvelles idées porteuses de valeur ou l’abandon d’idées initiales qui finalement n’en ont pas. Dit autrement, on devrait arrêter un projet quand il n’y a plus de valeur business dans les fonctionnalités à venir, par contre on devrait le poursuivre si la valeur de ces fonctionnalités à venir le justifie. Il n’est d’ailleurs pas rare que les fonctionnalités différentiantes arrivent relativement tardivement car on doit au préalable assurer les fonctionnalités de base, comme le montre le modèle de Kano.
Hélas la file d’attente crée une pression psychologique vers l’arrêt du projet, même si les fonctionnalités à venir sont intrinsèquement porteuses de valeur. Il faut certes juger de l’intérêt de poursuivre ou passer à autre chose, mais la roadmap tend à créer un biais dans la décision dans le sens de la tenue du plan.
La rigidification du changement
Une roadmap de projet, c’est un plan. Et créer un plan, ça prend du temps. Combien de temps (en délai) allez-vous prendre pour prioriser avec un comité de direction un portefeuille de 20 ou 30 projets ? Si votre réponse est “1 mois”, je pense que vous vous en tirez bien. Généralement, ce sera plutôt plus.
Maintenant, partons sur l’hypothèse de 2 équipes traitant des projets allant de 6 mois à 1 an, ce qui est compatible avec une roadmap d’une vingtaine de projets soit disons 3 ans de travail. Statistiquement, on va donc se retrouver avec un démarrage de projet tous les 3 à 6 mois. Quelle est la probabilité pour qu’un comité de direction réévalue cette roadmap à chaque début de projet (tous les 3 à 6 mois), avec un délai de réévaluation qui sera de 1 à 2 mois ? En théorie, c’est faisable, dans la pratique c’est au mieux improbable.
On se retrouve ainsi devant l’alternative suivante:
- Pas de réévaluation du portefeuille et on suit le plan sans le remettre en cause, en tout cas pas à chaque début de projet.
- Le bon sens prédomine, et lors du début du projet suivant, on démarre le projet qui parait être le plus important pour la société, qui n’est pas nécessairement celui prévu par la roadmap. Et la roadmap devient gentiment obsolète…
Incapacité à faire face à l’imprévu
L’un des autres effets pervers de la roadmap est l’effet d’encombrement qu’elle donne. En rendant visible (et priorisés) un grand nombre de projets, elle provoque une censure, voir une autocensure par rapport à de nouvelles opportunités business qui demandent un changement radical de direction. La présence même de la roadmap crée un frein psychologique à l’idée d’arrêter là un développement en cours ou de le réorienter.
Une variantes de ceci est la perte d’opportunités pour les équipes de réalisation elles-mêmes : crucifiées à leur roadmap, elles voient les projets d’actualité passer en d’autres mains car “ces pauvres gars sont bien trop occupés, il faut les soulager”. Là encore l’effet d’encombrement se substitue à l’importance business des projets qui émergent.
Quand c’est pas cher, c’est prioritaire
L’analyse et la priorisation d’un portefeuille de projets se font souvent sur la base d’indicateurs associés à ces projets : risque, importance business, coût, etc… En soi cela est une bonne chose même si calibrer l’importance relative de ces indicateurs est à la fois subjectif et délicat. Mais hélas ce processus nous expose lui-même à deux travers:
- Perdre de vue l’axe stratégique que l’on s’est fixé.
- Tomber dans le syndrome de la priorisation par le coût : “ce projet est tout petit, on doit pouvoir le caser avant ce gros”. Une fois tombé dans cette logique, le corollaire est une importance exagérée donnée à la quotation des projets (elle conditionne majoritairement les priorités), donc une logique de coûts préétablis sur les projets fonction des spécifications et par là même une sclérose anticipée du périmètre fonctionnel !
La roadmap de projets, c’est du stock
Quel est l’intérêt avéré d’analyser, évaluer et prioriser une vingtaine de projets lorsqu’au final c’est un et un seul projet qui démarrera au prochain démarrage de projet ?
En fait, il y a bien un intérêt : s’assurer que le bon projet à démarrer est bien celui que l’on a choisi et aucun des 19 autres ! Mais quel est l’intérêt de déterminer que les projets en position 4 et 5 sont correctement priorisés ? Ou même que celui mis en seconde position est le bon ? Le Lean nous apprend deux choses importantes:
- Le stock, c’est du gâchis. Il doit être éliminé.
- Les décisions doivent être différées jusqu’au “dernier moment responsable”. Ce dernier moment responsable, c’est celui où l’on va effectivement démarrer le projet.
Etablir, entretenir, réévaluer de longues listes de projet, c’est indubitablement du stock. Combien de projets de cette liste ne seront même jamais démarrés?
Et la roadmap agile ?
Depuis quelques années est apparu le concept de “roadmap agile”. La littérature sur le sujet n’est pas très abondante non plus, mais elle existe. Vous trouverez d’ailleurs une note de lecture sur un de ces ouvrages sur ce blog.
Quel est le but d’une roadmap agile ? Il reste de gérer et prioriser un portefeuille de projet, mais de manière plus efficace en ne remontant que les informations pertinentes à la priorisation. Donc, on décide plus efficacement sans s’engluer dans une masse d’information et un niveau de détails qui ne sont pas pertinents à ce niveau. On est aussi plus efficace à collecter et analyser l’information en amont. Bref, on se met en condition pour permettre le suivi et l’évolution itérative du portefeuille.
Mais cela reste quand même du stock !
Quelle alternative(s) ?
Analyser un gros portefeuille de projet est-il nécessaire ?
D’un point de vue des équipes de réalisation on a guerre besoin d’avoir une vingtaine de projets priorisés. On a même pas besoin d’avoir une visibilité sur ces vingt projets. On a juste besoin de connaitre le prochain projet. Avoir une idée des un ou deux suivants tels qu’on les imaginent aujourd’hui peut aider à donner de la perspective, pour autant que l’on accepte que la vérité d’aujourd’hui ne sera peut-être pas celle de demain…
D’un point de vue business, c’est un peu différent. Il faut identifier le (ou les quelques) bon(s) projet(s) à réaliser. Mais il n’est pas utile de recenser et surtout analyser tous les projets potentiels de l’entreprise ou du département pour cela. Si la stratégie est clairement identifiée, les quelques projets les plus importants remonteront naturellement. Et il y a de bonnes chances pour que ce soit les bons.
Le problème est la “stratégie clairement identifiée”. Ce n’est pas un boulot si facile que cela, mais c’est celui que l’on attend d’une direction.
Se livrer à une grande foire des projets, pardon à une roadmap des projets est aussi une façon d’abdiquer à l’établissement de cette stratégie.
Alors la roadmap, c’est mal ?
C’est le moment où je ne vais pas répondre à la question. C’est à vous d’y répondre.
La roadmap n’est pas intrinsèquement mauvaise, surtout si on essaie de la mener en agile. La vertu qu’elle doit porter est de donner de la perspective.
On peut aussi avoir une liste des “projets potentiels”, sorte d’aide-mémoire entretenu au fil du temps et de discussions informelles. Je le fais. Et cela m’aide lorsque le sujet et des sujets proches sont évoqués.
Mais les effets néfastes de la roadmap de projets existent et peuvent être plus importants que ses bienfaits. A vous de juger.
Personnellement je pense que la roadmap commence par une stratégie. Elle doit permettre de se focaliser sur un petit nombre de projets.
Les choses qui importent le plus ne doivent pas être à la merci de celles qui importent le moins.
Goethe
Note de lecture : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, par Véronique Messager-Rota
Note : 5 ; Un point de départ pour le chef de projet débutant, complété par des évolutions mineures, au fil des éditions.
Il est certainement une chose plus difficile que donner une note et un avis sur un ouvrage auquel on a participé : c’est se livrer au même exercice sur un livre dont on est l’auteur ! Je n’en suis pas là, mais cet exercice reste bien assez difficile pour moi.
Ce livre n’est pas une bible de la gestion de projet agile. Je doute d’ailleurs qu’une telle chose puisse exister. Il s’adresse plutôt à un publique junior ou en tout cas nouveau venu dans l’agilité et adresse deux questions essentielles :
- Quelles sont les activités que doit mener ou maîtriser le chef de projet : Ce sujet est traité tout au long du livre, car les différents chapitres traitent chacun un aspect spécifique des disciplines à maîtriser : ébauche de la vision, gestion des besoin, suivi des hommes et pilotage du projet. Il manque hélas une partie consacrée aux tests, et je regrette de mon coté que la facette plus technique du projet ne soit pas abordée, car je considère le rôle du chef de projet comme davantage holistique.
- Quel style aborder pour gérer les projets ? Le titre du livre réponds à cette question, bien que parfois le texte ne nous laisse pas clairement comprendre quelle approche est la bonne. Toutefois mettre les approches classiques et agiles en perspective est un bon exercice.
L’une des particularités du livre est certainement de laisser une part importante aux retours d’expériences (y compris ceux de votre serviteur) pour éclairer le propos. Sans être réellement aride ni académique, celui-ci est souvent un peu trop formel à mon goût.
Ce livre en est maintenant à sa 3ème édition. Que dire des évolutions entre la première mouture et le dernier rejeton ?
Tout d’abord que ces deux nouvelles éditions répondent en premier lieu au « business model » d’Eyrolles consistant à publier très régulièrement de nouvelles éditions de ses best-sellers. Donc il s’agit d’un best seller ! Comme chacun sait, cela n’est pas synonyme de qualité, mais en l’occurrence ce texte atteint bien sa cible (celle que j’ai évoquée plus haut) et le succès du livre en est témoin.
Dans la seconde édition, l’auteur a profité de l’occasion pour rafraîchir sa prose, même si c’est de façon mineure. Cela se voit dès la pagination, le volume total passant de 230 à 250 pages (hors annexes). Il s’agit surtout d’ajouts à l’intérieur des chapitres existant, le texte de base me paraissant inchangé. Ainsi le chapitre 2 qui exposait déjà de manière synthétique et avec brio les différentes méthodes agiles, ajoute « Lean » à sa panoplie. Le chapitre 3 se voit étoffé d’un court comparatif entre les users stories et les cas d’utilisation. Utile en soi, ce comparatif est je pense matière à débat. En clair : il faut qu’on en reparle, Véronique ! Le chapitre 7, consacré à l’adoption des méthodes agiles est celui qui bénéficie le plus d’ajouts : mesure de l’adoption et accompagnement de la conduite du changement.
L’apport le plus important à l’ouvrage est la section consacrée aux apports du coach (toujours dans le chapitre 7). Ces quatre pages supplémentaires ciblent les apports du coach par rapport à l’équipe et au management sur le « savoir être ». Il s’agit d’une prémices du prochain livre de Véronique !
La troisième édition qui n’apporte à nouveau que des bribes de nouveautés. On notera ainsi :
La section dédiée aux organisations agiles, au chapitre 2, qui permet de valoriser les idées avancées par Jérôme Barrand. Le chapitre 4, se voit lui, gratifié d’une page consacrée au pomodoro, ce qui est un ajout original et sympathique. Au chapitre 6, un petit ajout est fait sur le thème de la facilitation.
Sans avoir réellement vieilli, le livre voit son public se restreindre d’année en année : s’il adressait un public d’early adopter lors de sa sortie, il s’agirait maintenant plutôt de late adopters, pas forcements enclins à aller rechercher activement de l’information. Véronique Messager ne semble guère souhaiter poursuivre la politique de retouche mineures du texte et c’est à son honneur.
Si vous débutez en gestion de projet et vous posez la question de l’adoption d’une approche agile, ce livre est pour vous. Il vous permettra de poursuivre plus facilement votre apprentissage par des textes plus avancés ensuite.
Référence complète : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, 3ème édition – Véronique Messager-Rota – Eyrolles 2010 – EAN : 978 2 21212750 8
Note de lecture : Pair Programming Illuminated, par Laurie Williams & Robert Kessler
Note : 7 ; Plutôt bon, mais un livre qui ne présente pas le même niveau d’intérêt pour tous les publics !
Laurie Williams est reconnue dans la communauté agile pour être une grande spécialiste des aspects collaboratifs, il est donc logique qu’elle soit l’auteur de l’ouvrage de référence sur le pair programming, avec Robert Kessler, son mentor.
Le « pair programming » est probablement la pratique qui fait l’objet du plus de résistance lors de la mise en place d’une méthode agile. A cet égard, il n’est pas illogique de chercher à blinder la mise en place de cette pratique, par exemple à l’aide de ce livre. On reconnaitra que le texte cherche vraiment à traiter toutes les facettes du pair programming.
La première partie a trait à la compréhension de ce qu’est vraiment le pair programming. C’est sur cette partie qu’il faudra construire l’argument pour convaincre. L’auteur s’attaque aux mythes justifiant l’opposition à cette pratique avant d’évoquer les aspects bénéfiques. Vient ensuite le plat de résistance : convaincre le management. J’avoue que c’est du solide, avec des arguments, des chiffres et tout et tout. Cette partie se termine par l’évocation des difficultés qui peuvent se rencontrer à la mise en place du pair programming. Somme toute, cette première partie est une sorte de préambule à la mise en place de la pratique : pour convaincre, anticiper les obstacles et les objections, etc… Il n’y a rien à jeter et on a vraiment des choses solides sur les 60 pages de cette partie.
Longue d’une trentaine de pages, la seconde partie intitulée « getting started » m’a paru moins utile. Beaucoup d’éléments qui y sont présentés viennent simplement du bon sens et l’on a guère besoin du texte pour y arriver. Mais peut-être n’est-ce pas si mal d’avoir cela écrit quelque part ? Une mention particulière au chapitre 11 « tips ‘n tricks » qui donne pas mal de trucs utiles.
La troisième partie est la plus longue du livre avec une centaine de pages. Elle est écrite sous forme de patterns avec les différentes configurations de pairing (expert / novice, expert/expert , etc…) et différentes situations émotionnelles. L’idée est de fournir des solutions sous forme de scénarios afin de rendre possible ces différentes dynamiques de travail. Je ne suis pas convaincu que tout cela marche d’une manière aussi simple, mais au moins cela donne des pistes de réflexions.
La dernière partie enfin évoque différents aspects rassemblés ici de manière un peu hétéroclite : aspects économiques, les bonnes habitudes, pair programming versus code inspection, etc..
Le texte n’est pas mal écrit et plutôt plein de bon sens. De plus il est abondamment émaillé de références bibliographiques (l’auteur les a même fait figurer en fin de chaque chapitre). La première partie est littéralement de l’or en barre et on trouve clairement du matériel intéressant dans les autres. Beaucoup de matériel reste surtout intéressant pour ceux qui portent un intérêt académique au sujet (c’est mon cas). C’est un livre que je conseillerais sans hésiter au coach qui va y trouver beaucoup de matière première pour guider les pratiques d’une équipe. Le manager va y trouver des arguments pour défendre cette pratique, mais le développeur aura sans doute la sensation de perdre son temps à cette lecture.
Référence complète : Pair Programming Illuminated – Laurie Williams & Robert Kessler – Addison Wesley 2002 – ISBN: 0-201-74576-3
Le bon sens est la chose au monde la mieux partagée : car chacun pense en être bien pourvu.
De l’usage des exceptions en C++
J’ai écrit cette petite synthèse il y a environ 14 ans, pour contribuer aux réflexions sur l’usage, les contraintes et les pièges liés à l’emploi des exceptions en C++. Beaucoup d’éléments restent d’actualité aujourd’hui, je pense.
En tout cas, il s’agit d’une invitation à se méfier d’une approche naïve “si ça compile, c’est que c’est bon". La compréhension et la bonne utilisation d’une caractéristique du langage vont bien au-delà de la compilation ou même de l’exécution et du passage des tests ! Le C++ est bien connu pour cela, mais c’est aussi vrai pour la plupart des langages et trop souvent ignoré.
Note de lecture : 97 Things Every Software Architect Should Know
Note : 4 ; Un concept intéressant, avec un contenu plutôt hétéroclite, mais aussi certaines entrées plutôt pertinentes
Voilà un concept vraiment original : un livre collaboratif, publié en open source, compilant 97 conseils écrits par presque autant d’auteurs différents, chaque conseil tenant en 2 pages (en réalité plutôt un peu moins, environ 1 page et demi). L’intérêt de ce concept est que chaque « thing » est nécessairement concise, efficace et se doit d’aller au but, on n’a guère le temps de s’ennuyer. Le volume du livre reste aussi de taille plus que raisonnable : 195 pages dont j’estimerais que cela correspond à 150 pages d’un ouvrage plus classique.
L’ouvrage souffre quand même d’une faiblesse due au sujet traité : qu’est-ce qu’un architecte et quel est son travail ? Ainsi les conseils traitent d’aspect très diversifiés, ce qui peut être vu comme un bénéfice en élargissant le spectre des aspects traités : aspects fonctionnels, humains, performances, infrastructure matérielle, conceptions, technologies et frameworks, etc… Mais cela ressemble finalement à un grand « melting pot » qu’à un tout cohérent.
Il est d’ailleurs intéressant de voir à quel point les avis d’experts sont variés, allant de la figure paternaliste aux travail d’architecture réparti chez les développeurs eux-mêmes. Parmi les tendances que je vois se dessiner au long de ces 97 conseils :
- La nécessité de connaître la substance de base : les patterns, qu’ils soient architecturaux ou de conception.
- L’importance du facteur humain.
- L’importance des facteurs « environnementaux » : le lien avec le contexte métier, la contrainte d’entropie du système, etc..
Au final, il y a certes des choses à jeter, mais aucun article n’est mal écrit (ils sont courts, donc les auteurs doivent faire très attention), et il y a nécessairement des choses valables.
Ce n’est pas le livre de l’année, mais je le classerais volontiers dans les « lectures amusantes ».
Référence complète : 97 Things Every Software Architect Should Know – Richard Monson-Haefel edt. – O’Reilly 2009 – ISBN : 978 0 596 52269 897
Les deux choses les plus importantes n’apparaissent pas au bilan de l’entreprise : sa réputation et ses hommes.
Software Freethinker 
