The Psychology Of Computer Programming

Il Faut Lire!

Cette année, j'ai pris une résolution : commencé à lire. Il était temps me direz vous, mais ceci est un autre sujet, pour ce qui nous concerne maintenant, je viens juste de terminé un livre dont j'ai beaucoup entendu parlé et dont le sujet m'a fortement intrigué : Psychology Of Computer Programming de Gerald M. Weinberger.
C'est un livre que je recommande fortement à tous ceux qui sont en relation direct ou indirecte avec l'industrie du logiciel et voici pourquoi.

Dingue comment ce bouquin est vieux ET récent

Première chose : ce livre à été édité pour la première fois en 1971, il y a donc 41 ans au moment de l'écriture de ces lignes. C'est en partie pourquoi certains détails m'échappent. L'informatique de de l'époque consistait en l'écriture de programmes sur cartes perforées à destination d'un système central occupant un étage voir un bâtiment complet. Il est souvent fait référence à des programmes en PL/1, il fallait prendre rendez-vous pour faire exécuter son programme, et faire en sorte qu'il ne prenne pas trop longtemps afin de permettre l'exécution d'autres programmes. Bref toute une activité humaine prise en charge aujourd'hui par le système d'exploitation installé sur nos ordinateurs pesant moins de 10 kg.
Et pourtant, tous les concepts abordés, chaque exemple décrit et chacune des situations exposées est transposable à notre époque.

C'est quoi déjà la programmation?

La première partie pose les bases pour tous le reste du livre. En effet, il convient de comprendre ce que l'on entend par «programmation» avant d'en étudier les différents aspects psychologiques.
On dit bien «écrire un programme»s; pour faire référence à la fabrication d'un logiciel. Il est intéressant de remarqué qu'aujourd'hui comme dans les années 70, on forme les développeurs à écrire des programme mais pas à lire. Il n'y a que ceux qui doivent effectué une maintenance qui sont confrontés à la lecture de programmes écrits par d'autres. De mon point de vue, je n'ai jamais autant appris sur mon métier qu'en lisant des programmes écrits par d'autres. Et aujourd'hui, avec l'essort des logiciels libres, chacun est en droit de lire les sources des frameworks (Spring, ...) et des outils utilisés (Ant, Maven, Git, serveurs d'applications, ...) donnant ainsi un aperçu sur comment on écrit des programmes.
Un autre aspect qui est évoqué : Qu'est-ce qui fait un bon programme ? C'est une question qui prend son sens quand on voit comment le(s) critère(s) de qualité peuvent influé sur les autres (parmi Efficacité, Développer dans les temps, Résistance au bugs, ...).
Enfin, dernier aspect de l'activité du programmeur : La documentation. Il y a en effet différents niveau de documentation, de la plus technique destinée à l'équipe en charge du logiciel, à la plus vulgarisante destinée aux utilisateurs.

Une activité social

La deuxième partie évoque le développement logiciel en groupe. Le concept le plus intéressant est intitulé «Egoless Programming» qui repose sur la dissociation entre le code produit et la personne qui le produit. Et réciproquement, comment se détacher du code que l'on produit pour accepter favorablement toutes critiques provenant de tout autre développeur.
D'autres concepts très intéressant sont évoqués, l'organisation formelle et informelle, ce qui constitue une équipe, l'importance des objectifs, les crise qu'une équipe peut rencontrer, «la mère» et «le père» d'une équipe, ...
Un dernier point à attirer mon attention : l'équipe «démocratique» qui, selon ma compréhension, représente le mode organisationnel de base de toutes les méthodes agiles: connaissance collective, répartition autonome des tâches, formation et éducation des nouveaux membres.

Une activité individuelle

Une troisième partie détail les aspects du développements sur le plan de l'individu. Nous ne sommes pas tous égaux devant l'ensemble des tâches que constitue le développement logiciel. Certains semble avoir de meilleures dispositions pour la rédaction de code tandis que d'autres seront meilleurs pour la relecture et d'autres encore sur le débogage. Il convient pour chacun d'entre nous de comprendre quels sont nos points faibles afin de les travailler au mieux.
La personnalité du développeur joue également un rôle non négligeable. Si aucun profil n'est meilleur qu'un autre pour faire un bon développeur, la détection d'un changement de personnalité doit être prise au sérieux.
Un point intéressant est porté sur l'impossibilité de mesurer la performance des individus, malgré tous les efforts déployés par les compagnies pour normaliser les développeurs.
Un dernier paragraphe porte sur l'importance de la motivation des individus dans la réalisation de leur tâches et le lien avec les objectifs.

Une activité outillée

Cette dernière partie porte sur la justesse des outils compte tenu du fonctionnement du plus ancien des ordinateurs : notre cerveau. Cette partie porte plus particulièrement sur les langages de programmation mais également sur la documentation et l'importance que cette dernière accompagne le code. C'est aujourd'hui naturel de voir de la JavaDoc sur du code Java, ou tout autre forme de documentation exploité par des outils tels que Doxygen (C/C++, ...) ou RDoc (Ruby) mais à l'époque c'est un sujet de veille et d'avancée. Un point reste pourtant d'actualité : pas de documentation vaut mieux que de la mauvaise documentation.
Beaucoup d'exemples portent sur la difficulté de faire un code fiable lorsque le langage permet de faire la même chose de plusieurs manières.
Un dernier point qui a attiré mon attention repose sur les habitudes des développeurs sur les environnements. Nous avons chacun chacune nos propres habitudes et même si les programmes doivent respecter une certaines normes pour facilités leur maintenance par tous, il convient de laisser un minimum de liberté au développeur des outils lui permettant de réaliser son travail, depuis son bureau jusqu'au IDE en passant par le système d'exploitation de sa station ou même le clavier ou la souris.

Conclusion

Chaque chapitre est suivi d'un paragraphe de "dé briefing" dans lequel on trouve des questions de l'auteur à destination du lecteur, certaines pour les programmeurs et d'autres pour les membres de l'encadrement, manager et chefs de projet. C'est donc un livre à destination de différents profils de lecteurs. J'ai trouvé beaucoup de situations similaires dans mon expérience professionnel et tiré beaucoup d'enseignements. Si j'avais lu ce livre avant, j'aurai sûrement pu comprendre les facteurs de succès de certaines situation mais également pu éviter certains choix qui ont conduit à des échecs cuisant.
J'estime à 60~70% la quantité d'information que j'ai pu comprendre, compte tenu de ma maîtrise de l'anglais, je n'ai pas toujours pu ouvrir un dictionnaire, et certaines situation m'ont échappées compte tenu de l'évolution du métier du développement logiciel. Malgré cela, j'ai appris bien plus que je ne l'aurai espéré en lisant quelques centaines de pages écrite il y a plus de quarante ans.
Ce livre vaut vraiment l'effort de le lire, même quand on est pas forcément à l'aise en anglais. Je conseille également l'édition «Silver Anniversary Edition» qui comporte en plus le regard de l'auteur 25 ans après sa première édition.