Il y a quelque temps, lors d’une soirée entre développeurs autour d’une bonne bouteille de vin, est revenu l’éternel débat sur le professionnalisme.
Le débat est parti du constat qu’un des fondateurs d’une société de jeux vidéo que je ne citerai pas, était capable de sortir des perles de jeu, mais personne dans son équipe n’était capable de reprendre son code. Les arpinumiens présents ont alors émis l’hypothèse que cela faisait de lui un bon « game designer », mais un mauvais développeur : un non professionnel.
Si on définit un professionnel par sa seule aptitude à gagner de l’argent grâce à son activité, alors le seul moyen de juger est la quantité d’argent amassée. Ceci dit, j’aime la version Wikipédia du professionnalisme :
Le professionnalisme caractérise la qualité du travail de quelqu’un ayant de l’expérience.
Il est possible d’avoir l’impression que ces deux définitions ne se comprennent pas. L’une parle d’argent, l’autre de qualité. Mais finalement est-ce le cas ?
Le professionnel, contrairement à l’amateur, doit savoir maximiser le retour sur investissement. Un développeur professionnel sait donc que la qualité d’hier est la productivité d’aujourd’hui. Il doit donc à priori toujours produire le code de qualité correspondant aux besoins à un instant T : pas de sur-conception, c’est du gaspillage, mais pas de code illisible et couplé, il sera plus difficile à modifier.
Le bon professionnel gagne donc effectivement de l’argent de son activité, mais optimise en plus chaque denier qui est placé en lui.
Cette optimisation peut alors passer parfois par dire « Non » . Non, nous n’arrêterons pas de faire des tests ; non, cette fonctionnalité n’est pas réalisable dans le temps impartis, mais nous allons trouver un compromis ; <ajouter ici la clause où vous vous reconnaitrez>
Pour revenir à notre exemple initial, qu’est ce qui fait de cette personne un développeur amateur, mais un bon game designer ?
Nous avons conclu que, en tant que game designer, il maximise le ROI de sa société en découvrant des mécaniques de jeu innovantes et amusantes, qui vont donc trouver un public. Il ne suit pas un plan préétabli, mais joue avec des hypothèses, et si elles s’avèrent mauvaises, n’hésite pas à les jeter. Il connaît son marché et le temps à y consacrer : pour un jeu casual, il ne faut pas chercher les mécaniques d’un Eve Online, ni les mêmes temps de développement. Pour résumer, il cherche de manière itérative et incrémentale son nouveau game design, dans une limite de temps correspondant aux bénéfices attendus.
En tant que développeur ceci dit, ce n’est pas la même chanson :
en ne testant pas le plus tôt possible, il augmente le temps de tests de recette et son code illisible augmente le coût de correction. S’il tombe malade, personne ne peut reprendre son code, et il immobilise la société.
En ne produisant pas du bon code, il ne peut pas être utilisé dans d’autres projets, ou servir de source d’inspiration pour d’autres. La connaissance n’est pas transmise.
La société en question se porte pourtant merveilleusement bien. Est-ce que ça veut dire que tout ce beau débat sur le professionnalisme ne sert à rien ? En développant essentiellement des jeux courts sur lesquels ils ne reviennent pas, le souci de qualité est amoindri. Je verrai dans ce cas le manque de professionnalisme comme un coût des opportunités perdues.
Dans un contexte différent cependant, comme un éditeur de logiciel, une équipe travaillant sur le même produit pendant des années sans être rigoureux sur la qualité peut tout simplement couler la société. Le cimetière des entreprises en est rempli (ce n’est bien sûr pas la seule raison possible, la qualité est une condition nécessaire, pas suffisante).
Notes :
Pour plus d’informations sur les caractéristiques et l’éthique d’un développeur professionnel, il existe quelques livres : The clean coder, the pragmatic programmer, the mythical man month, The passionate programmer.