Par développeur, j'entends toute personne qui développe, indépendamment de son genre. On peut être un excellent développeur de Java, disons, et un piètre développeur en général. C'est la différence entre une bonne mémoire et une capacité de conception.

Comme toute personne ayant un nombre d'années d'expérience professionnelle à deux chiffres, je me pensais bon développeur. Que voulez vous, l'égo est un mécanisme de protection de soi puissant... Mon outil usuel est le Java, et mes technologies de base sont en gros Apache Hive, Apache spark, et les jours de folie, du spring. Et au bout d'un moment, vient une espèce de routine, une sorte d'habitude. Quand on rencontre 10 fois le même problème, on commence à comprendre les solutions, et les "bonnes conceptions" qui nous les évitent. Certes.

Assembler, c'est livrer

C'est cette expertise qu'on vend à un client, et c'est cette différence que le client paie. J'ai un collègue, excellent développeur Java, qui me faisait remarquer que ça ne servait à rien d'apprendre d'autres langages car on perdait du temps à résoudre "toujours les mêmes problèmes". On perdait finalement son temps, alors qu'une expertise dans un langage permettait au contraire de toucher aux différentes branches d'un domaine (front, back, big data, etc), et donc d'être confronté à de "nouveaux défis", voire de "nouveaux challenges" comme on dit quand on est commercial. Et l'argument est intéressant. Cependant, le métier change. La financiarisation de la DSI en général, et la multitude des frameworks java en particulier, font qu'une prestation technique n'est plus une réflexion de conception et d'architecture, mais un aller retour permanent sur le site du framework qu'on utilise et stack overflow (très bon site par ailleurs).

Mon travail ne consiste plus qu'à mettre en forme la documentation de l'éditeur (mon job d'architecte big data) et à assembler des frameworks ensemble (surtout en big data quand l'éditeur a fait tout le travail de conception). Et donc, mon avis est que se spécialiser dans un seul langage ne permet que de savoir de mieux en mieux assembler les composants que d'autres écrivent. C'est un travail technique très bien payé, c'est exactement ce qu'un client veut pour tenir ses délais (et donc avoir son bonus), mais qui n'a pas de valeur intellectuelle majeure ajoutée.

Je développe un projet personnel en C, et qui nécessite un serveur (en C) multi-threadé. N'étant pas fan de la programmation via CGI, j'ai développé le mien. Et j'ai renoué avec ce qui fait le charme de ce métier : concevoir, coder, tester sa solution (et se prendre plantage sur plantage avant de trouver la bonne idée, mais passons). Et c'est exactement ce qui manque aux développeurs expérimentés que je croise dans mes missions : ils ont fait le tour de leur domaine, leur intérêt technique n'est pas satisfait, il leur manque le plaisir de penser du code au lieu de suivre une documentation ou une API à la lettre (en particulier sur spring qui marche magnifiquement bien quand on suit le guide et qui nous sort des exceptions improbables quand on s'en écarte d'un cheveu). Etre un bon développeur d'un langage, c'est le connaitre, connaitre son écosystème, et savoir assembler des composants. Etre un bon développeur, c'est savoir prendre des problèmes non déjà résolus et mettre en place une conception qui règle la question dans le délai imparti.

Réinventer la roue ?

Les réponses / coups de massue que je reçois en pleine tête quand je fais part de ces réflexions sont les suivants :

  • "Formidable argument, mais on ne va pas réinventer la roue à chaque fois pour se faire plaisir alors qu'un client attend qu'on livre. Vite. Genre ASAP. Genre pour hier."
  • Corollaire du précédent : "OK, mais si tu veux coder pour le plaisir, tu as chez toi ou des missions chez des éditeurs / experts techniques. Un client grand compte n'a pas de temps à perdre avec ces considérations, il est le seul à avoir la connaissance métier, et c'est sur ça, et ça seulement qu'on doit se concentrer"
  • Mon préféré : "mais dis donc ! Comment ça se fait que tu sois encore développeur à ton âge ? Tu n'es pas encore manager ? Pourquoi tu codes encore ? "

Je comprends bien ces arguments. Deux sur trois sont très bons, le dernier est symptomatique d'un arrivisme que je méprise. Oui, certes, on ne va pas réinventer la roue, parce qu'on n'a pas le temps. Mais c'est un raisonnement court terme qui me perturbe. J'avais jusqu'à très récemment la responsabilité de recruter des gens pour la SS2I / l'ESN qui m'emploie.  J'ai donc vu défiler des gens qui savaient tout à fait répondre à des questions ne nécessitant que de la pratique et de la mémoire, mais qui séchaient devant une question simple d'algorithmique (à savoir, calculer la moyenne en double d'une liste d'entiers passée en paramètre). Authentique. Mes collègues me remontent que le fizzbuzz est souvent un carnage. Et le problème est là : assembler n'est pas développer. Sous couvert de ne pas réinventer la roue chez un client, on ne fait que prendre des solutions déjà existantes, et on ne prend plus le temps de développer sa faculté de résoudre des problèmes non triviaux. Conséquence : à la première difficulté, en attendant qu'une âme charitable réponde sur internet, on fait des claquettes au client pour le faire patienter, parce que non seulement on ne sait pas répondre, mais on ne sait plus chercher par soi même. On devient utilisateur du code qu'on copie colle, et plus auteur du code.  Le problème devient donc : comment cultiver ses qualités de développeur, comment faire en sorte qu'on sache résoudre un problème nouveau ?

Admettons, mais dans 99% des cas, ça passe. Pourquoi se fatiguer ?

Je tiens cette analyse d'un consultant senior, et je vous la reproduis telle quelle, en italique. Sa théorie est relative aux budgets qui ne permettent plus que d'assembler de l'existant, développé ailleurs. Parce que, dans les années 1990 et 2000, les DSI reines (crises mises à part) ont tiré le client d'un coté, et trop fort : "OUI, monsieur le client, vous allez voir, on va vous développer une solution technique magique, etc. Bon, c'est super cher, mais avec ça, vous allez devenir leader dans votre domaine. Merci de mettre le chèque sur la table, on vous recontacte dans six mois". Conséquence logique de tout abus, sans parler du mouvement global de financiarisation des entreprises, les financiers ont repris la main en répondant : "votre solution, c'est bien gentil, mais c'est super cher, vous nous avez pipoté sur les délais que vous avez explosé, et les couts qui ont suivi le même rythme. Maintenant, voilà un budget, et débrouillez vous à faire tenir vos plans là dedans".

La conséquence logique, et que je constate dans mes missions, est que le budget réduit se rajoute à un culte absolu du "time to market" : on doit livrer vite, et dans le budget. Donc, on assemble dans la précipitation du code trouvé sur le net, en croisant les doigts. Et souvent ça passe. Mais, la dette technique des projets explose. La situation est encore sous contrôle, le fait qu'une application soit buguée est devenu un standard, personne ne s'en préoccupe, on attend la correction qui va bien. Sauf que je prédis que les applications vont se dégrader suffisamment pour qu'un beau jour, elles plantent en suivant un effet domino. Le financier va rendre l'informatique responsable, avec raison, d'une perte opérationnelle majeure, et il faudra débloquer du budget en urgence pour reprendre le code et le stabiliser. Les financiers vont se tourner vers les éditeurs, n'ayant plus du tout confiance dans leurs équipes. Et c'est un excellent choix, les meilleurs développeurs sont là bas, pour les raisons mentionnées plus haut. Donc, ruée massive vers les éditeurs, qui promettront avec raison un développement personnalité qui sera de bien meilleure qualité que le développement de la DSI.

Mais, parce que les éditeurs ont également lu Adam Smith, ils vont profiter de leur monopole pour augmenter leur TJ. C'est qui qui donc qui n'aura pas assez d'argent pour payer, mais un réel besoin d'aide, et qui suppliera l'éditeur de leur faire un "bon prix" ? Le même financier qui pressait sa DSI comme un citron en n'écoutant pas quand la dite DSI suppliait pour avoir du budget. Et vous l'aurez compris, le financier se rabattra sur de la prestation standard (comprenez des gens comme moi). Et là, c'est le drame... A force d'encourager la prestation au moins cher et au plus vite, les qualités nécessaires pour rentrer dans du code complexe, et produire du code stable, se perdent. Donc, les bons développeurs, celles et ceux qui ont fait attention à préserver leurs compétences, vont s'arracher à prix d'or, et il ne restera que les autres pour reprendre des "projets critiques" qui ont été laissés en friche pendant des années.  

Je vous laisse, j'ai des qualités de développeur à conserver.

 

Comments are closed.

Set your Twitter account name in your settings to use the TwitterBar Section.