{"partition": "head_middle", "source_domain": "www.ekito.fr", "digest": "sha1:K35FS3CKF4VXV7U5BSEX44GQGRSTSRXN", "path": "/lustre/fsn1/projects/rech/qgz/uzq54wg/processed_redpajama/base_processing/output/fr/2014-15/000_00006.parquet"}
techStudio
Développeurs seniors. Pourquoi ? Comment ?
January 21, 2013 by Laurent Blondon | 19 Comments
Après 25 ans dans le logiciel, je reste en proie à de nombreux étonnements quant au fonctionnement de cette industrie. Parmi ceux-ci, l’un récurrent concerne la position et le peu de reconnaissance généralement dévolue aux développeurs.
Certes l’on sent confusément que l’époque valorise davantage « ceux qui font faire » que « ceux qui font », ou mieux encore « ceux qui font savoir ». Mais est-ce légitime dans le domaine du logiciel ?
Il ne s’agit pas ici de faire un plaidoyer pro domo, ni de m’insurger contre une injustice à mon égard ; cela fait bien longtemps que je n’ai écrit une ligne de code. Pourquoi d’ailleurs ? Sans doute le hasard des rencontres et des opportunités professionnelles. Mais certainement, consciemment ou non, la pression sociale, avec à l’époque où j’ai débuté, la pensée répandue que si après 2 ou 3 ans de développement on ne passait pas chef de projet, on ratait sa carrière.
Il me semble que le dénigrement vis-à-vis de la fonction de développeur n’a cessé de croitre. Pas forcément dans les discours à l’encontre de ces derniers, mais dans le modèle économique même, où l’instrument de mesure principal semble être le prix journalier (tiré vers le bas), où les ressources sont considérées comme interchangeables, et le mouvement vers l’offshore, même sous couvert d’industrialisation et de CMMI, n’a fait qu’accentuer ces tendances.
En quoi est-ce gênant ? Pourquoi effectivement ne pas considérer la fonction de développeur comme ayant peu de valeur ajoutée, et en faire une industrie de main d’œuvre peu qualifiée et donc peu chère ? Cela aurait très bien pu avoir du sens. Mais pour cela, il aurait fallu qu’en contre partie la tâche de développement devienne beaucoup plus simple. Certes l’utilisation de frameworks ou de pattern de codes sont sources de simplification. Mais qui osera prétendre qu’il est simple de développer ? Que la connaissance même et la maîtrise des frameworks soit un exercice simple à la portée de tous ? Certainement pas la réalité des projets !
Il s’agit là toujours d’une grande source d’étonnement pour moi. Comme si l’industrie du logiciel faisait mine de croire à des progrès tels du génie logiciel que le développement soit devenu une tâche facile. Comme si éditeurs, SSII, grandes et petites entreprises faisaient mine de ne pas voir que leurs projets de développement coûtent de plus en plus cher et continuent allègrement de dépasser budgets et plannings. Comme si les politiques d’achats faisaient mine de croire qu’il suffit de baisser les prix journaliers des développeurs pour faire des économies, …
Fort heureusement, il existe d’autres manières de penser.
J’ai suivi avec beaucoup d’intérêt les premiers succès des méthodes agiles. Dont il serait dangereux de ne retenir que la possibilité de faire évoluer des spécifications, ou le rituel « exotique » et les acronymes. La place faite aux développeurs, la reconnaissance de leur importance, le fait de laisser l’équipe de développement s’autogérer, sont des éléments essentiels, mais trop souvent oubliés.
La « starisation » de certains développeurs fait également plaisir à voir. Non pour le principe de starisation en tant que tel, mais pour la reconnaissance induite d’une vraie difficulté à bien développer (voire mais ce n’est pas le sujet ici, d’une véritable activité artistique).
Tout l’indique ; tous les critères objectifs de mesure des coûts des projets logiciels montrent bien la difficulté de ces projets, et cette difficulté n’est pas uniquement méthodologique ou dans des relations MOA-MOE. Elle est à la base fondamentalement technique.
Admettons donc cette difficulté et tirons en les conséquences. La réussite de projets logiciels passe nécessairement, pas uniquement, mais nécessairement, par la qualité et l’expérience des développeurs.
S’il s’agit d’arriver à la conclusion qu’il vaut mieux de bons développeurs que des mauvais, je trouverai certainement bien peu de contradicteurs. J’ai toujours vu chefs de projets et responsables d’équipes chercher à s’entourer des meilleurs profils, … dans la limite des contraintes qui leur sont imposées.
Au-delà des compétences des individus, c’est bien le système qu’il faut revoir.
Si l’on admet qu’il est toujours extrêmement compliqué de réussir des projets logiciels. Si l’on considère que différentes causes concourent à cette complexité, mais qu’on ne saurait écarter celle de la complexité technique, c’est-à-dire de l’acte même de développement. Si l’on ne nie pas que les méthodes et outils à la disposition des développeurs n’ont pas – encore – fait les progrès suffisants pour réduire de façon substantielle la difficulté de programmer (sans doute parce que les architectures et les environnements de développement se complexifient à mesure de l’avancée des outils). On arr