Où travailles-tu ?
Je suis ingénieur de recherche à l’#INRIA Saclay, dans le service d’expérimentations et développements (SED). C’est un service qui regroupe des ingénieurs pour aider les équipes de recherche dans leur activité de développement logiciel.
Les ingénieurs sont affectés, souvent pour un an, éventuellement renouvelable, sur un travail pour une équipe. Cela ressemble un peu à une SSII interne.
Sur quels sujets, dans quels domaines scientifiques ?
j’ai eu l’occasion de développer des logiciels dans plusieurs domaines: #biostatistique, génération d’ordonnancement de code #parallèle et distribué, arbres aléatoires, #outils de développement, …, qui m’ont amené à aborder des domaines techniques variés comme les #bases de données, des communications #réseau, de la parallélisation, des #interfaces web, …
Par ailleurs, en ce moment, je m’intéresse à de nouvelles formes de publication scientifique bénéficiant des possibilités des formats du web, ainsi qu’aux annotations de documents.
Je viens d’être affecté pour aider une équipe pour résoudre certains problèmes dans un logiciel offrant une #interface web donnant accès à un “dictionnaire dynamique de fonctions mathématiques”: leur comportent, leur développement, leur dérivées, selon des paramètres entrés par l’utilisateur.
Le logiciel est développé en #OCaml, appelé en mode FastCGI par un serveur apache, et interrogeant Maple pour les manipulations mathématiques.
Quel est ton parcours ? Comment es-tu arrivé à faire ce travail ?
En classe de terminale, je ne savais pas quoi faire. Un copain d’un an plus âgé était venu présenter au lycée la formation qu’il suivait en IUT d’informatique. Comme j’aimais bien les jeux vidéos, je me suis dit que j’allais faire ça :-) Un DUT, c’est deux ans, donc ça ne m’engageait pas trop par rapport à d’autres cursus.
Ca m’a plu, j’ai continué ensuite en Maîtrise de Sciences et Techniques (MST), qui correspondait à Bac + 4, puis j’ai enchaîné sur un DEA d’informatique fondamentale, théorie des langages, typages, preuves de programmes. Cette dernière année était un peu dure, je n’avais pas fait beaucoup de maths les années précédentes, même la lecture des lettres grecques était un souci.
Donc la formation que j’ai suivie était principalement #technique, avec beaucoup de développement logiciel dans de multiples langages et couvrant beaucoup de domaines: UNIX, réseau, bases de données, programmation système, interfaces graphiques, algorithmique, …
Je suis entré à l’IUT en 1994, donc le web à l’époque, c’était quand même limité. Et en résidence universitaire, il n’y avait pas de connexion internet. La première que j’ai eue à la maison, c’était en 2000, avec un modem… Le parcours normal après ce genre de formation, c’était être embauché par une entreprise, soit pour du développement, soit pour de l’administration système. La grande époque des applications silos, les débuts des intranets, …
Rétrospectivement, l’IUT et la MST m’ont donné de très bonnes bases pour appréhender ensuite les évolutions techniques, et le DEA, même si je n’ai pas tout bien suivi, m’a apporté un point de vue différent, plus théorique, sur l’informatique et le développement logiciel.
A partir de mon stage entre les deux années de MST, j’ai travaillé à temps partiel dans une société qui faisait des études de sûreté de logiciels embarqués dans des trains, des centrales, … C’est là que j’ai été en contact avec le milieu de la recheche en informatique, et c’est pour ça que j’ai bifurqué vers un DEA plutôt qu’un DESS. (pour les “jeunes” lecteurs, le DEA était l’équivalent du Master Recherche, tandis que le DESS était plus appliqué)
Après mon DEA, j’ai travaillé encore presque 2 ans dans cette société, puis j’en ai eu marre car on manquait de visibilité sur les développements à réaliser. Développer quelque chose en sachant qu’on va tout casser 3 mois plus tard, ce n’est pas très motivant.
J’ai atterri à l’INRIA sur un CDD d’un an, puis j’ai passé un concours. J’ai trouvé plus de liberté dans le monde de la recherche, plus de temps pour faire les choses, réfléchir. Il n’y avait pas encore cette organisation par #projet comme unique mode de gestion. Ou en tout cas ce n’était pas aussi prégnant. Ou bien je ne m’en rendais pas encore compte.
Quelle est la part du développement logiciel dans ton activité ?
Importante. Par développement logiciel, j’entends bien sûr toutes les activités que cela comporte (l’écoute, l’analyse, la proposition de solution, l’écriture de code, la modification, la correction, les #tests, la #documentation, le support, …), mais aussi la #veille, les discussions, les #formations, … La frontière n’est pas bien claire.
A partir du moment où on parle de développement logiciel en tant que #métier, alors le milieu entre en ligne de compte, car on n’exerce jamais un métier “hors sol”. Au contraire, l’environnement facilite ou freine l’activité, offre des possibilités qui nourrisent les #méthodes utilisées, apporte des contraintes avec lesquelles il faut composer et qui impactent donc la façon de travailler…
De ce point de vue, mon activité de développement ne peut pas se cantonner à une simple exécution d’un “processus de développement”; elle nécessite au contraire une partie de réflexion sur mes propres #pratiques, celles des collègues, les conditions qui font que le #travail peut être fait ou bien qu’il est “empêché”, etc.
Donc le développement logiciel en ce qui me concerne, c’est beaucoup de temps.
Qu’est-ce qui te plaît dans le développement logiciel ?
Plusieurs choses, selon le moment, selon le contexte.
C’est une activité dans laquelle on peut s’investir, s’appliquer, mettre de soi, essayer de “faire du beau”, avec un aspect très #artisanal, comportant toujours une part d’invention, de création, de nouveauté, que cela soit dans le problème à régler ou dans les solutions adoptées. Cela pousse à apprendre, à s’intéresser à des domaines dont on ne connaît parfois pas grand chose.
C’est aussi un moyen de rendre possible une certaine vision du monde. Par exemple, je pense que le monde de l’édition scientifique n’est qu’une transposition du modèle hérité du monde du papier. Pourtant, on devrait pouvoir publier dans des formats “pour” le web (HTML, CSS, …) et non pas juste de publier “sur” le web, comme c’est le cas avec le PDF. Mais cela n’est possible que si des outils existent pour faciliter de nouvelles formes de publication. Développer de tels outils, c’est donc avoir une vision de ce qui devrait être possible pour la faire advenir.
Quand des entreprises comme Facebook, Google ou Amazon offre des services, les logiciels qu’ils développent correspondent à leur vision du monde. On entend souvent dire que les algorithmes gouvernent le monde, mais ils sont juste l’implémentation d’un modèle sous-jacent, lui-même étant une représentation d’un monde possible. On devrait donc parler des modèles, plus faciles à critiquer que “les algorithmes”.
Développer du logiciel, surtout du #logiciel libre, permet donc une forme de résistance face à des tentatives de confiscation de nos capacités.
Développer ses propres outils est également un aspect qui me semble important. J’ai d’ailleurs développé mon propre éditeur de code, pas parfait, pas aussi poussé que d’autres, mais qui me suffit et surtout qui répond à mes besoins et ne m’impose pas des pratiques associées.
De ce point de vue, développer du logiciel est un moyen d’être libre d’adopter certaines méthodes plutôt que devoir s’adapter à un outil qui, in fine, prescrit une manière de penser quand on aborde un problème. Bien sûr, le temps limite les marges qu’il est possible de s’aménager de cette façon, et il est bon de partager un minimum de méthodes et de façon de penser avec les autres. C’est un juste milieu à trouver.
J’aime aussi la réutilisabilité du code. Le fait de régler un problème une fois permet d’utiliser la solution dans plusieurs contextes. On apprend donc tout en permettant une automatisation sur laquelle on pourra s’appuyer par la suite. C’est très stimulant, une sorte de version moderne des “épaules de géants”.
Qu’est-ce qui ne te plaît pas dans le développement logiciel ?
Il y a toujours des parties qu’il faut faire, mais qui ne sont pas la partie concernant directement le problème à résoudre: la lecture d’un fichier de configuration, le traitement des erreurs de saisie, … Bref, le code répétitif, pas assez générique pour le factoriser ou utiliser du code existant. C’est pénible, mais c’est aussi par là que des questions surgissent, propres à pousser plus loin la réflexion sur ce qu’on est en train de développer: le choix du nom d’une option n’est pas anodin, il oriente la vision que l’utilisateur aura du traitement effectué; parle-t-on alors de la même chose dans le code ?
Il y a quelques années, j’aurais cité la #documentation. Mais plus maintenant. J’arrive à trouver un intérêt presque à tout, il faut simplement changer son regard. Quand on doit faire quelque chose, autant y prendre plaisir, sinon on le fait mal, on s’en débarasse. J’avoue me débarasser de certaines parties de logiciels qui ne m’intéressent pas mais qu’il faut faire pour que ça tourne. C’est comme ça. On peut se mettre une note pour y revenir plus tard, quand on sera d’humeur à le faire bien. C’est comme la mise au point en photographie, une partie de la photo sera nette, une autre sera floue. On ne peut pas développer en faisant le focus sur tous les aspects en même temps.
J’ai appris à attendre le bon moment, attendre l’#envie. Quand un point reste dans la liste des choses à faire trop longtemps, il faut chercher à comment rendre cette tâche intéressante. On est parfois surpris. Cela peut prendre la forme d’un outil à développer pour se simplifier la tâche. Pour la documentation, d’une part j’ai développé des outils, d’autre part je la vois comme un moyen de donner un avenir au logiciel développé, ce qui rejoint une préoccupation habituelle qui est de s’assurer qu’un logiciel peut évoluer. Cela passe par des structures de données extensibles, mais aussi par la documentation qui permettra à un autre de continuer le travail dans la même direction. Cet autre, c’est d’ailleurs souvent soi-même. On est bien content d’avoir écrit une documentation quand vient le moment de la lire.
Pour revenir à la question, une chose que je n’aime pas, c’est manquer de #temps. Il y a souvent un compromis à trouver entre faire mieux et faire dans des délais raisonnables. Peut-être surtout, c’est le manque de longues plages de temps sans réunion, sans interruptions. Il y a parfois des problèmes qui demande une immersion longue pour trouver une solution.
Je n’aime pas non plus quand les outils ou les organisations se muent en obstacles sur mon chemin. Comme je l’ai dit, j’essaie de travailler sur quoi j’ai envie, selon le jour. Cependant, le développement logiciel est maintenant sur une telle pile #technique qu’on a vite fait de se retrouver entravé pour une raison ou une autre: une mise à jour qui casse une bibliothèque, un serveur en rade, … Les objets développés ont une certaine fragilité, capable de leur faire perdre leur sens. Combien de programmes écrits il y a dix ans tournent encore ?
Il arrive aussi parfois que pour avancer on voudrait organiser une réunion mais que par “optimisation des ressources” il n’y a plus de lieu disponible. Autant de situations de travail empêché. Mais ça, ce n’est pas propre au développement logiciel…
Quelle est ton approche du développement ? Comment définirais-tu en deux mots ta “méthode” de développement ?
Ma #méthode est surtout de ne pas en avoir. Je veux dire pas de méthode nommée. Parler de “#méthodes agiles” me fait bien rire. Est-ce que ce sont les méthodes qui doivent être agiles ou les développeurs ? Quand une méthode est figée par un nom, où est l’agilité ?
Pendant mes études, j’ai comme beaucoup subi le “cycle en V” pendant les cours de génie logiciel. Pas du tout adapté évidemment au monde de la recherche (dans peu de domaines, d’ailleurs) et donc pas mis en pratique.
Depuis pas mal d’années, les #méthodes agiles fleurissent, pleines de promesses de compétitivité, de réactivité voire du retour de l’être aimé. C’est un truc pour les décideurs et les manageurs. La meilleure #méthode, c’est celle que l’on adopte en fonction de la situation, en s’inspirant de l’expérience de chacun, en regardant comment font les autres. Je veux bien qu’on parle d’être agile, mais pas de méthode agile. Si c’est la méthode qui est agile, alors le développeur est rabaissé à une ressource pour l’appliquer.
Décrire une méthode nécessite d’expliciter le travail, dire ce qu’on fait, comment, dans quel ordre, pourquoi. Je pense qu’en grande partie on ne connaît pas les réponses à ces questions. On agit par rapport à son expérience, son intuition, sa vision du problème, sa perception des contraintes. Une grande partie du #travail est implicite, en quelque sorte cachée. Quand on ne prend que la partie explicitée pour en faire des “bonnes pratiques” à recommander voire imposer, ça ne marche pas, car tout l’implicite n’est pas pris en compte. L’implicite se retrouve caché dans la marge, celle qui est justement réduite par les volontés d’optimisation. A vouloir tout optimiser et réguler par des méthodes, on empêche le travail.
Mon discours est un peu radical et je ne veux pas dire qu’il n’y a rien à prendre du côté des “méthodes agiles”. Simplement, cela ne doit pas remplacer une réflexion sur ses pratiques et méthodes, ni être pris comme des recettes universelles. Un problème, cependant, c’est que ces méthodes se retrouvent dans des outils que les développeurs doivent parfois utiliser, les faisant tomber dans l’hétéronomie au lieu d’une #autonomie propice à l’adoption de #méthodes adaptées.
Par ailleurs, j’essaye de toujours faire en sorte que, dans les outils que je développe, l’utilisateur ait toujours une grande marge pour adapter ces outils à son usage, que ce soit par des options de configuration mais surtout par la possibilité de développers des greffons. Comme je sais combien il est pénible de se voir imposer une façon de travailler et donc de penser par un outil, j’essaye d’anticiper les extensions qu’un “power user” pourrait vouloir. Donc je considère que l’utilisateur a cette capacité, et qu’il ne faut pas l’entraver.
Bien sûr, il y a toujours des limites à ces possibilités de configuration, de modification ou d’extension; comme pour n’importe quelle technique ou technologie. C’est le cas aussi dans le langage: on a une grande variété de constructions dans la grammaire, on a même la possibilité d’ajouter de nouveaux mots, mais il y a une base commune qui permet de communiquer des idées, de se faire comprendre. C’est toujours un compromis entre faire comme tout le monde (utiliser les mêmes mots, utiliser un outil de la même façon, bref avoir des pratiques communes que certains aiment appeler “bonnes pratiques”) et avoir la possibilité de faire à sa façon.
En fait, comme je n’aime pas être forcé dans mes pratiques, j’essaie naturellement de permettre une souplesse dans l’utilisation de ce que je développe.
Enfin, je ne me sens pas un “vrai” ingénieur. A mon sens, il y a trop d’humain dans les logiciels pour qu’ils soient confiés à la seule rationalité des ingénieurs, souvent avec des considérations #économiques. On demande souvent aux ingénieurs: “pourquoi ne pas avoir réutilisé cette bibliothèque ou autre chose d’existant?”, avec l’argument que cela aurait coûté moins cher. On n’entend jamais demander “pourquoi ne pas avoir développé ta propre solution ?”. Il y a des arguments pour la réutilisation, comme le fait qu’un code soit déjà éprouvé. Cependant, s’assurer qu’un code répond bien à ses besoins, que ses évolutions futures permettront de continuer de l’utiliser dans les évolutions prévues ou envisagées dans son propre logiciel, tout cela prend aussi du temps. Développer sa propre solution, c’est être assuré qu’elle répondra à ses besoins. En plus, c’est l’occasion d’apprendre en faisant, de s’exercer. C’est important aussi. Cela participe à la saveur du #métier.
Sur combien de codes travailles-tu à la fois ?
Plein ! Il y a en général un code “principal” par période, mais qui peut nécessiter le développement ou l’enrichissement d’autres bibliothèques ou outils, ce qui donne des développements entrelacés. C’est d’ailleurs un moyen de rester motivé en étant affecté pour une période fixe sur un logiciel: En développant certaines parties séparément pour qu’elles puissent être réutilisées, je me donne la possibilité de m’investir dans quelque chose qui n’a pas de fin prédéfinie, ce qui est beaucoup plus facile que de s’investir dans un “#projet” dont on connaît déjà la date de fin.
Sur quelle durée travailles-tu sur un même code ?
C’est variable, bien sûr. C’est plutôt par périodes. Par contre, les affectations officielles sont sur des périodes souvent d’un an. C’est court, et surtout ça empêche de se projeter, donc ça nuit aux évolutions futures du logiciel, puisqu’il est difficile de penser aux extensions possibles d’un logiciel quand on doit déjà chercher une autre affectation ou bien quand on ne sait pas de combien de temps on disposera. On n’engage pas les mêmes travaux sur un code selon qu’on sait si on sera encore là 3 mois ou un an.
Pour moi, le #projet tue le logiciel, il ne permet que de faire des programmes.
Par ailleurs, travailler plus longtemps avec une équipe de recherche permet de comprendre et appréhender les pistes d’évolution de ses recherches, donc d’anticiper les directions vers lesquelles le logiciel devra évoluer. Tout n’est pas explicite.
Quelles technologies (langages, outils, …) utilises-tu ?
Je développe principalement en #OCaml, depuis une quinzaine d’années. J’ai fait pas mal de développements d’interfaces graphiques avec la bibliothèque #Gtk.
Depuis quelques temps, je développe un peu pour le web, en l’occurrence pour un système de rédaction de documents pour le web, type articles, avec j’espère bientôt de l’édition collaborative. Je fais donc du #javascript avec des #websockets. Le serveur est en OCaml. Et en javascript, le seul bon code est le code mort… ou le code généré. J’utilise donc Js_of_ocaml, un compilateur de code OCaml vers Javascript. Ca a l’avantage de faire plein de vérifications (typage, …) à la compilation, donc je passe moins de temps à déboguer et je garde l’expressivité d’OCaml.
Je travaille uniquement sous #Linux, beaucoup en ligne de commande, mais j’utilise aussi github, dont je trouve les outils vraiment très pratiques.
Pour la gestion de versions, j’ai utilisé successivement SCCS (si si, au siècle dernier!), CVS, #Subversion, Darcs et maintenant je n’utilise que #Git, quand j’ai le choix. J’avais essayé monotone aussi, mais ça n’a pas pris.
Je ne suis pas très environnement de développement, avec complétion automatique et tout le tintouin. J’aime bien comprendre où sont définies les choses, pas juste être une sorte d’utilisateur d’un environnement qui générerait plein de code à ma place. J’utilise mon propre #éditeur de code, Chamo. Je n’utilise la complétion qu’avec les fichiers qui sont ouverts comme source. Je préfère aller voir la documentation pour trouver la fonction dont j’ai besoin plutôt que la machine me la propose. Par ce geste répété, je (re)découvre d’autres fonctions qui parfois conviennent mieux, j’acquiers une meilleure vision de l’organisation des bibliothèques que j’utilise. Et faire appel à ma mémoire fait que je ne suis pas démuni si je me retrouve dans un environnement privé de ce genre de fonctionnalités.
Travailles-tu avec d’autres développeurs ? Dans une équipe ? Sur le même code ? Selon quelles modalités ?
Cela dépend des affectations. Comme mes activités sont très morcelées, comme j’aime également attendre le moment où j’ai envie de faire quelque chose pour le faire bien, je ne suis pas sûr d’être un bon candidat pour travailler en #équipe, disons de façon “intense”. Cela serait sûrement différent avec moins d’activités en parallèle. J’aime le côté asynchrone des outils “modernes”, que ce soit la messagerie électronique ou la gestion de versions. Cela laisse à chacun la possibilité d’avoir son propre #rythme, son #organisation, chose rare.
Avec quelles autres personnes travailles-tu ? (autres que développeurs)
Il m’arrive de travailler avec des matheux, pour implémenter des algorithmes et voir si l’implémentation rejoint la #théorie. C’est très agréable: Quand le programme donne le résultat attendu, tout le monde est content. Quand ce n’est pas le cas, soit le programme est bogué, soit c’est la propriété qu’on cherche à prouver qui est fausse. En tout cas, l’un remet en cause l’autre, comme souvent entre science et technique.
Comment fais-tu de la veille ? Avec quels outils ? Combien de temps y passes-tu ?
J’en fais beaucoup. Je pense y passer au moins 10 à 15% de mon temps, principalement en lecture, parfois en tests d’outils, de bibliothèques, …
J’utilise plusieurs outils, complémentaires à mon sens. Tout d’abord, les fils #RSS pour suivre des sites ou blogs. C’est une façon très efficace de se tenir au courant, mais bien sûr au courant de qu’on attend déjà, en quelque sorte. Si je suis un site concernant OCaml, il y a peu de chance d’apprendre par ce biais qu’un nouveau langage vient de sortir, ou un cadriciel web dans un autre langage.
Ensuite, il y a les #réseaux sociaux, #Twitter en ce qui me concerne. En suivant des comptes en lien avec ses intérêts, on voit passer tout un tas d’informations qui ne sont pas seulement celles qu’on attend, contrairement aux fils RSS. On a un écart par rapport aux attentes, qui permet d’élargir le spectre des informations, tout en restant assez proche de ses centres d’intérêts. Les deux outils sont donc complémentaires.
Bien sûr, il y a l’inconvénient qu’en utilisant ce type de réseau social, on donne beaucoup d’informations personnelles. C’est un compromis à trouver entre ce que je suis prêt à donner en échange de quel service. Pour cette raison, hors de question que j’aille sur Facebook. Je me suis mis à diaspora via framasphere.org, mais pour l’instant il n’y a pas encore beaucoup d’utilisateurs, donc moins d’informations que sur twitter.
Enfin, il y a d’autres façons de faire de la veille, par exemple discuter avec les collègues, être sur des listes de diffusion, participer à des ateliers ou des #formations, aller à des conférences, … ou encore les journées LoOPS :-é)
Cependant, il faut savoir aussi se limiter, éviter le fameux syndrome FOMO, “Fear Of Missing Out”, la peur de rater quelque chose. On ne peut pas tout savoir, et si vraiment une information est importante, il est probable qu’on l’apprendra d’une façon ou d’une autre. Est-il vraiment important d’être au courant avant les autres ?
La veille est pour moi une source d’inspiration, consciente ou non. Toutes ces lectures me donnent des points de vue, suscitent de nouvelles analogies, m’apprennent l’existence de techniques. Tout cela me change et donc a un impact sur mes développements, sur l’avenir que je peux leur imaginer et la façon d’aborder les problèmes.
Une autre activité qui peut se rapprocher de la veille, mais davantage sur les pratiques que sur l’existence d’outils etc., consiste à lire du code écrit par d’autres. Je ne le fais pas assez.
Ta façon de travailler a-t-elle changé depuis tes débuts ? A quoi est-ce dû ? Qu’est-ce qui est resté constant ?
L’activité de développement elle-même reste la même: résoudre des problèmes, trouver des solutions pour calculer une solution, si possible de façon élégante et adaptable à un avenir probable. Le tout accompagné de ceintures et bretelles: gestions de versions, de bogues, tests, etc.
Ce qui a changé, ce sont surtout les outils: internet bien sûr, mais aussi les gestionnaires de versions, les éditeurs de codes, les langages même ont évolué, beaucoup offrant davantage d’abstraction.
Les outils sont de plus en plus connectés, donc les pratiques tendent à s’uniformiser. Quand vous travaillez de plus en plus à plusieurs sur un logiciel, quand ces logiciels sont autant de groupes différents de personnes utilisant les mêmes outils, on voit rapidement apparaître des “bonnes pratiques”, qui ne sont au final qu’une certaine culture, qu’une certaine rationalisation, orientée par les outils, eux-mêmes conçus par des développeurs sur la base de #pratiques antérieures en voulant les faciliter.
Au fur et à mesure que les outils sont de plus en plus connectés, on converge vers des pratiques communes, que cela soit la taille des indentations, la façon de faire des branches dans un dépôt, etc.
J’ai découvert récemment Floobits, permettant d’éditer collaborativement du code dans on éditeur habituel (Emacs, Vim ou SublimeText). Celui qui veut profiter de cette fonctionnalité doit alors utiliser l’un de ces éditeurs, ou bien développer cette fonctionnalité dans son éditeur. Si cette fonctionnalité devient une pratique répandue, chaque développeur sera encouragé à utiliser un éditeur la supportant. S’il ne peut pas adapter son éditeur préféré, il devra soit en changer, soit se couper en partie de sa communauté. J’ai toujours vu mon éditeur comme un espace de liberté, l’interface avec les autres développeurs se faisant via les fichiers édités. Cela pourrait changer si les #éditeurs eux-mêmes deviennent connectés.
Comment diffuses-tu ou transmets-tu ton savoir-faire ? A qui (collègues, autres) ?
Comme je suis bien content de trouver des ressources sur internet, de profiter de discussions et de l’expérience des autres, je trouve normal en quelque sorte de “rendre la pareille”.
Ainsi, sur #Twitter, je diffuse des liens que je trouve intéressants. Dans les dicussions type pause café, je parle de ce que j’ai appris ou découvert, de ce que je fais.
Depuis plusieurs années, je fais également des #formations, notamment une introduction à OCaml. Je me suis attaché à construire un support écrit, pas juste des “transparents”, mais un vrai support réutilisable en dehors des sessions de formation. Et comme rien n’est plus pénible qu’un support dont les exemples ne fonctionnent pas ou plus, le support est compilé, pour m’assurer qu’il n’y a pas une erreur et que les sorties affichées sont bien celles de la version d’#OCaml en cours.
J’apprécie cette activité de formation, car elle force à aller au-delà de la simple utilisation. Au lieu de s’arrêter à “c’est bon, ça marche”, il faut comprendre pourquoi, aller voir les coulisses pour pouvoir mieux expliquer. Au final, on apprend souvent beaucoup de choses; on peut même se rendre compte qu’on utilisait mal une certaine fonction, ou qu’une construction du langage nous aurait épargné plusieurs lignes de code…
Bref, pour répondre à la question, un autre vecteur de transmission est de faire des exposés sur ce sur quoi on travaille. Bien sûr, cela prend du temps, mais c’est un bon exercice, et une bonne occasion de recueillir des avis. Cependant, je ne suis pas sûr que cette pratique soit vraiment encouragée pour ce qu’on appelle l’”#évaluation”.
Qu’est-ce qu’un logiciel “de qualité” à ton avis ?
C’est un peu comme la vertu dans le Ménon de Platon, on ne sait pas la définir mais on sait la reconnaître.
La question de savoir ce qu’est un “bon” logiciel, ou un logiciel “de qualité” n’a donc pas de réponse dans l’absolu. Est-ce un logiciel extensible ou performant, sachant que l’optimisation ruine parfois les possibilités d’évolution ? Ces qualités, entre autres, sont souvent en tension alors qu’elles sont désirables toutes les deux.
Cela signifie que l’appréciation de la “#qualité”, quoi que recouvre ce terme, dépend du contexte, des objectifs, de l’avenir envisagé pour le logiciel, etc., c’est-à-dire de critères qui ne sont pas quantifiables.
La “dispute professionnelle”, comme dirait Yves Clot, c’est-à-dire la discussion sans cesse renouvelée sur ce qu’est un bon logiciel, est ce qui forge une conception commune du métier de développeur: qu’est-ce qui est acceptable, qu’est-ce qui ne l’est pas, dans quel contexte, etc. C’est une réflexion qui intègre l’#organisation du #travail, ses contraintes, car l’environnement a un impact sur le travail, le développement logiciel n’est pas qu’une question technique. Par exemple, peut-on ignorer que les contraintes de #temps ont un impact sur les choix d’implémentation et le compromis sur la qualité du développement ?
Malheureusement, il n’y a guère de lieu actuellement pour ce genre d’échanges entre développeurs. A titre d’exemple, on pourra jeter un oeil au programme des JDev 2015: les thématiques sont uniquement techniques, il n’y a pas de place pour les aspects métier et nourrir la discussion sur ce qu’est un “bon” logiciel et plus généralement une éthique du #métier.
Ce n’est bien sûr pas un cas isolé, c’est une tendance lourde dans laquelle l’évaluation remplace le débat, des indicateurs “objectifs” remplacent l’appréciation et la culture commune et vivante. C’est dommage pour un réseau “métier”, de faire l’impasse justement sur le métier.
J’ai entendu une fois une personne qui disait qu’on pouvait #évaluer tous les logiciels dans l’absolu, selon des critères définis à l’avance, bref une vraie grille d’évaluation. C’est tout simplement grotesque. On ne peut “évaluer” un logiciel sans prendre en compte les objectifs et les moyens; il y a un monde entre un prototype et un logiciel en production.