Développeurs seniors. Pourquoi ? Comment ?

| 19 Comments

developpeur seniorAprè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 arrive par cet enchainement logique à reconnaître que la tâche dévolue aux développeurs est, et reste, complexe.

Le métier étant complexe, il faut d’une part des personnes bien formées, mais surtout, et c’est là que l’effort doit porter,  encourager une filière d’excellence pour bénéficier de développeurs seniors expérimentés.

Quelques pistes pour créer une telle filière d’excellence :

  • encourager (promotions, salaire, …) les personnes (a priori nombreuses) que l’activité intellectuelle de développement passionne, à poursuivre dans cette voie, et arrêter de transformer des programmeurs brillants en chefs de projets banals
  • maintenir l’intérêt et les performances des meilleurs développeurs en leur confiant des tâches à la hauteur de leurs compétences, et ne pas les laisser s’ennuyer sur un plateau de TMA
  • favoriser le partage et le transfert d’expériences (pair programming, revues de codes,  …) pour stimuler les équipes et accroitre la compétence collective
  • encourager ceux qui s’en étaient éloigné (architectes, scrum master, chefs de projets, …) et que cela intéresse, à revenir pour partie dans le développement, tant par ce que peut apporter leur expérience, que pour leur éviter d’être trop éloignés de la réalité du terrain

 

La fonction « ressources humaines » doit donc être en pointe sur sujet.

Les services achats et responsables économiques ne doivent pas échapper à cette évolution. Il leur faut absolument revoir et sans doute complexifier leurs instruments de mesure, car un bon programmeur ne devra pas être jugé sur son seul coût journalier (forcément plus élevé à mesure qu’il gagne en expérience et que l’entreprise reconnaît sa valeur) mais sur son apport qualitatif et quantitatif à la réussite des projets.

Un beau chantier en perspective, mais toutes les entreprises qui ont su ainsi miser sur l’expérience et l’excellence de leurs développeurs y ont largement gagné.

 

PS : Mes relecteurs au sein d’ekito (merci à eux) me signalent – entre autres –  deux références très intéressantes : un article de Nicolas Martignole qui raconte l’aventure du développeur passant PetitChef  http://www.touilleur-express.fr/2009/07/27/senior/ et l’association « Fier d’être développeur » (bravo !) http://fierdetredeveloppeur.org.

Laurent Blondon Author: Laurent Blondon

Plus de 20 ans dans l'économie du logiciel.
Ingénieur de formation, ayant participé aux tous premiers projets Objet en France puis aux prémices du MDA, avant d’exercer d’autres rôles (formateur, commercial, manager), et de prendre part à de très belles réussites d’entreprises.
Un temps client d'ekito, observateur attentif de son projet novateur, finalement rejoint début 2010.
Pour contribuer à faire vivre et développer son modèle d'expertise technologique et d'innovation organisationnelle.
Et l'ambition de faire d'ekito l’entreprise de référence pour tout architecte, agiliste, expert, passionné, et impliqué ; le lieu incontournable de réussite des projets technologiques ambitieux.

19 Comments

  1. Pingback: Développeurs seniors. Pourquoi ? Comment ? | ekito people | Liberté & Informatique | Scoop.it

  2. Dans la lignée, je te conseille la lecture de cet excellent article: http://blog.mandraxe.info/ingenieurs-grincheux.html

    • Merci pour l’article “grincheux” :)
      Il est effectivement intéressant, et je trouve très pertinente l’idée de parler de la représentation des développeurs, par eux mêmes et par les autres

  3. Je plussoie intégralement!

    A noter aussi le software craftsmanship qui véhicule ces même valeurs: http://www.meetup.com/paris-software-craftsmanship

    Il faut continuer à faire bouger les choses, et à montrer la vraie valeur ajoutée d’un bon développeur.

    • Merci pour le retour
      Je pense vraiment que les choses peuvent bouger, même si l’on peut s’étonner que cela ne se fasse pas plus vite.

  4. Bravo Laurent pour la qualité de cet article.
    Autant sur le fond que sur la forme, exceptionnel.

    Merci !

    • Merci Baptiste
      Et je te souhaite de continuer à faire plein de choses intéressantes techniquement … même passé la trentaine

  5. Bonjour et merci Laurent pour cet article très bien écrit et presque… émouvant !
    Tu fais honneur à la fonction de commercial dans ce secteur
    Bravo

    Bref, tu as tout dit
    en bon agiliste, +1 pour moi

    Le déséquilibre est aujourd’hui flagrant
    Mais comme toutes les causes à défendre, il faudra, lorsque cet équilibre aura été rétabli, ne pas verser dans l’excès inverse, à savoir de reconnaître aussi le bon du moins bon “manageur” (au sens de la psychologie, de la prise de recul et du développement de synergies), qu’on l’appelle chef de projet, scrum master ou que sais-je

    • Bonjour David,

      Merci pour ton retour. Tu as raison sur le fait qu’il ne faudrait pas passer d’un extrême à l’autre

  6. Pingback: Développeurs seniors. Pourquoi ? Comment ? | ekito people | TIC sur son 31 | Scoop.it

  7. Pingback: Développeurs seniors. Pourquoi ? Comment ? | ekito people | Ma confession, par Huguette, Sénior connectée de 84 printemps | Scoop.it

  8. Pingback: Développeurs seniors. Pourquoi ? Comment ? | ekito people | Communication et générations | Scoop.it

  9. Bonjour Laurent
    et merci pour ce message. Je crois que le phénomène dépasse la question du logiciel et touche l’ingénierie, quelle qu’elle soit. Depuis quelques dizaine d’années les dirigeants sont des commerciaux, des financiers, où sont les “capitaines d’industrie” issus du technique ? Et le soft et son côté “pas sérieux” (rester toute la journée devant un écran, je peux écrire une vague macro VB ds excel donc le soft c’est pas si compliqué…) accentue ce manque de considération. En ce qui concerne les solutions, si j’achète ce que tu proposes, il me semble que la balle est dans le camp des Développeurs. Aujourd’hui des initiatives existent, je pense à mes petits camarades de scopyleft.fr par ex à Montpellier. Ou bien le mouvement craftsmanship où nous sommes heureux de nous retrouver. Et ce n’est pas le pays des bisounours : cela passe par une responsabilisation.
    Mes deux centimes d’euros.
    T.

    • Bonjour Thierry,

      Je ne sais pas si la balle est uniquement dans le camp des développeurs, ou des ingénieurs pour élargir le débat.
      Mais si l’on regarde le cheminement des idées agiles – et tu seras bien mieux à même que moi d’en parler – il me semble effectivement que cela a été le point de départ.
      Ensuite, dans la mesure où il y a quand même beaucoup de bon sens dans ce que l’on dit, et que la main mise de ces dernières années par les financiers n’a pas forcément eu les succès qu’ils pouvaient en attendre, y compris et surtout du point de vue économique, je pense que l’on peut être confiant dans une évolution positive des choses. Sans être dans les bisounours.

  10. “Au-delà des compétences des individus, c’est bien le système qu’il faut revoir.”

    Tout à fait, le problème vient principalement de la culture des organisations et du management des travailleurs du savoir (par exemple le développeur).

    Mais l’idée commence à se répandre. C’est l’objectif du mouvement Stoos http://www.stoosnetwork.org/

    Et d’ailleurs je participe à l’organisation sur Paris de l’événement global Stoos Connect! http://stoosparis.eventbrite.fr/?ebtv=C

    Dans tous les cas, très bon article :)

    Yannick Grenzinger

  11. Pingback: Développeurs seniors. Pourquoi ? Comment ? | ekito people | Aequoveille | Scoop.it

  12. bonjour
    je fais partie des “seniors seniors” (c.a.d. des développeurs d’un age “avancé”).
    Comme j’aime le développement (et que je me suis toujours maintenu à un très bon niveau technique) j’ai du batailler ferme pour continuer à exercer dans l’optique qui m’est chère….(toujours l’argument “si vous n’êtes pas manager à votre age …. c’est que….”).
    Bon je vais pas trop me plaindre j’y suis arrivé mais parce que j’ai accepté d’être “mal payé” (sniff!)
    Mais maintenant je suis confronté à un autre problème : on veut me pousser à la retraite (pas trop d’acc), il faut que je forme un jeune (tout à fait d’acc.) … mais quel niveau de salaire pour ce jeune? A ce niveau de compétences si j’étais jeune je n’accepterais pas mon salaire! ;-)
    affreux dilemne ;-)

  13. Lecture très intéressante, et bien qu’étant un jeune développeur je suis très réceptif quant à la teneur des propos de cet article et les valeurs qui s’en dégagent.

Leave a Reply

Required fields are marked *.