Tout d’abord, apprendre un nouveau langage n’est pas trivial, et avant de pondre un code de qualité acceptable digne d’être mis en production, il peut se passer beaucoup de temps.

Il n’est en effet pas rare que l’on se fourvoie dans la mise en œuvre du langage et que l’on se retrouve donc à faire et à défaire un certain nombre de fois avant d’arriver à un résultat acceptable en terme d’efficacité, de maintenance et de fiabilité.

Et dans le monde de l’entreprise, cela peut vouloir dire que les délais de livraison ne seront pas respectés, que le code ne répondra pas aux attentes, ou tout autre chose du même acabit qui auront finalement un impact financier plus ou moins important.

Dans tous les cas, l’entreprise perdra de l’argent, même si le ou les développeurs impliqués se seront enrichis intellectuellement, et je ne parle pas du sacro-saint ROI de certains investisseurs qui sera alors reculé au mieux de quelques semaines, au pire qui n’arrivera jamais.

Une autre problématique est celle du recrutement.

En effet, utiliser un nouveau langage pour commencer un projet peut être une stratégie intéressante, du fait des avantages qu’il apporte en terme d’efficacité et de performance.

Cependant, s’il s’agit d’un langage peu usité et que le projet doit évoluer, il deviendra forcément nécessaire à un moment ou à un autre que d’autres programmeurs y participent, ne serait-ce que pour éviter l’effet bus.

Or, il n’est déjà pas simple de recruter un bon développeur pour les langages les plus courants.

Je n’ose donc imaginer la difficulté que représente le recrutement d’un développeur pour travailler sur un logiciel conçu dans un langage peu connu ou exotique.

Le problème de la démission se pose également, car en général, les projets mettant en œuvre une ou plusieurs technologies nouvelles dans le contexte de l’entreprise sont portés par une personne qui en a déjà une relative bonne maîtrise, soit parce qu’elle a été recrutée dans cette optique (donc avec les difficultés susmentionnées), soit parce qu’elle a acquis les compétences nécessaires sur son temps libre.

Son départ de l’entreprise pour une raison ou pour une autre peut donc être un réel problème, car dans ce cas, l’avion se retrouvera sans pilote.

Choisir un langage que l’on ne maîtrise pas pour commencer un nouveau projet est donc à mon avis une excellente façon d’apprendre, et c’est peut-être même la meilleure stratégie possible pour cela.

Cependant, mettre en œuvre cette stratégie dans une entreprise et de plus dans le cadre d’un projet à fort enjeu économique me parait une attitude dangereuse et même suicidaire.

Pour Perrick, il aurait certainement été plus pertinent intellectuellement parlant pour ses développeurs de choisir un autre langage que PHP pour développer Loizeil ou tout autre nouveau projet dans le cadre de No Parking.

Cependant, économiquement, je suis intimement persuadé que le jeu n’en vaut pas la chandelle et qu’il a donc fait le bon choix en restant dans sa zone de confort et celle de ses développeurs.

Et c’est d’ailleurs l’un des problèmes de notre profession, car pour cette raison, nous n’avons pas souvent l’occasion de nous enrichir intellectuellement en appréhendant de nouveaux outils dans le cadre de notre travail.

Certes, il y a bien la possibilité de bénéficier de formation et de participer à des conférences, mais cela coûte financièrement à l’entreprise, et en conséquence, cela n’est pas toujours possible, sans parler du fait qu’il faut trouver le temps nécessaire.

Pour ceux d’entre nous qui ne travaillent pas dans une société qui a compris l'intérêt de la veille technologique et de l'auto-formation dans le cadre de l'entreprise, cela n’est donc possible que sur le temps consacré à un projet personnel, et pour peu que l’on ait une vie de famille, il devient rapidement difficile de trouver ce temps.