Sam High-Tech Blog

Le blues du développeur

En revenant d’une conférence sur GIT dans le cadre du BreizhCamp (faite par Sebastien Douche, excellent orateur) je rentre chez mon frère qui m’héberge. Et commence la conversation type que nous développeurs nous avons déjà eu des dizaines de fois:

Mon frère : Alors cette conf, sympa ? C’était sur quoi ?
Moi : Ouep super bien, on nous a présenté GIT
Mon frère : Ah ? C’est quoi GIT
Moi : Un super outil de GConf pour remplacer SVN qu’il est grand temps de virer.
Mon frère (perplexe) : Ah…ok….bon, et sinon les enfants, ils vont bien ?

Et votre femme (oui car souvent le développeur est un homme ) ne vous a jamais demandé comment s’est passé votre journée ? Chez moi ça donne à peu près ça :

Ma femme : Alors ta journée ? bien passé ?
Moi : Oui le top, j’ai complètement refait la gestion transactionnelle du projet pour utiliser de l’AOP en mettant le place spring et Jersey pour l’exposition REST.
Ma femme (perplexe) : Ah… en effet ça a l’air bien.
Moi : Et toi ? bonne journée ?
Ma femme : Oui pas mal, j’ai diagnostiqué un truc grave au plus tôt, ça va sûrement lui sauver la vie.
Moi (perplexe) : Ouais… C’est pas mal non plus…

C’est je trouve le plus frustrant dans notre métier, on peut faire des trucs hyper techniques, c’est très compliqué de l’expliquer et de le faire partager aux non néophytes. Pire : plus c’est technique et moins c’est impressionnant/intéressant pour les autres. Faites une page web avec un GIF animé et vos amis vous prennent pour un dieu de l’informatique. Par contre plus c’est technique et moins on peut montrer un résultat concret.

Personnellement j’ai vu le changement quand je suis passé d’un projet Java sur le Machine To Machine au développement sur iPhone. A expliquer à mon entourage c’est le jour et la nuit

C’est aussi pour ça que des journées comme le BreizhCamp ça nous fait du bien à nous les développeurs, on peut discuter avec d’autres personnes qui comprennent ce que l’on fait. Donc encore merci Nicolas pour l’avoir organisé !

Choisir un développeur

Je viens de lire un article très intéressant : Why the new guy cant code

Comme je l’ai dit dans l’article sur les forfaits, il est indispensable de bien choisir ses développeurs et c’est loin d’être simple. TechCrunch explique bien que le processus de sélection des entreprises n’est pas souvent très performant. Même chez Google il y a des choses à améliorer. J’ai par exemple bien aimé le test technique à faire pour déposer son CV chez Ippon, mais ce n’est pas suffisant.

J’ai aussi souvent cet exercice à faire et ce n’est pas simple. Pour préparer l’entretien je commence par googler le nom du candidat. Je suis en phase avec l’article : aujourd’hui il est juste inadmissible qu’un développeur ne possède pas de site web/blog. Un bon développeur c’est avant tout un passionné, il doit exister sur la toile. Pour une prestation j’ai passé un entretien avec un gars qui avait un site web où il présentait son voyage à Lego Land et des Add-on Counter Strike qu’il avait développés. Avant même de le voir en entretien je savais qu’il était bon car un homme qui aime encore les Legos ne peut qu’être bon J’ai encore le souvenir de sa tête se décomposant au moment où je lui est demandé pendant l’entretien : « Alors ? C’était comment Légo Land ? » (la tête de sa commerciale était pas mal non plus ). Il était un peu gêné au début mais pour moi ce n’était que du positif : il a un site web, il développe des add-on CS sur son temps perso et le contact était bon pendant l’entretien. Résultat : une bonne recrut qui a fait du super boulot.

Pas simple non plus de s’y retrouver avec les CV que l’on reçoit des SSII. Entre les CV retouchés par les commerciaux pour y placer les mots clés recherchés et les CV où le commercial a juste collé l’entête de sa société sur le CV du gars, on est pas aidé. Je ne supporte plus les CV où sont listés les 36 langages informatiques connus, ça ne veut plus rien dire ! Une fois j’ai eu une personne avec sur le CV : « Assembleur Intel et Motorola », sûrement un TP fait il y a 3 ans : super intéressant pour une presta JEE. Et là pas de chance, moi aussi j’en ai fait de l’assembleur ! Et oui n’oubliez jamais que si vous notez quelque chose sur votre CV, il faut assurer après. Du coup au milieu de l’entretien je demande au candidat : « Peux-tu me dire la différence entre l’assembleur Intel et l’assembleur Motorola ». Et là patatras… même pas capable de se rappeler de l’inversion des bits de poids faible et des bits poids fort pour les octets. Donc pitié, sur les CV ne mettez que l’essentiel et indiquez le niveau de compétence (Java : 3 ans, C# : 1 an, etc…)

Autre expérience intéressante. Je cherchais un développeur JAVA en urgence (genre pour demain) et bien sûr avec de la bouteille. A cause des délais je n’ai eu le CV que d’une personne avec peu d’expérience mais avec des mots clés intéressants comme Maven. L’entretien se passe bien mais j’avais encore des doutes sur ses compétences. Devant son commercial je lui demande : « Tu as une heure de dispo ? J’ai justement un problème avec un appel WS avec Axis, tu m’aides à le coder ? ». Là encore je les ai un peu surpris, mais on s’est mis à deux devant un écran et on a corrigé le problème.

Le plus important ce ne sont pas les réponses aux questions mais comment ils répondent. J’ai sélectionné de très bons développeurs qui savaient répondre « Ah non ça je ne connais pas » au lieu d’essayer de m’embrouiller. Un autre point à ne pas négliger non plus c’est bien sûr le relationnel. Un excellent développeur peut devenir un poids mort s’il ne s’intègre pas facilement dans une équipe.

Pour résumer mes critères perso pour choisir un bon développeur :

• Avoir un blog, un site, une activité informatique sur son temps perso
• Pour les développeurs iPhone/Android : avoir publié une application à titre perso.
• Un bon contact lors de l’entretien.

Recrutement Ippon vraiment original

Je viens de tomber sur une offre emploi super bien faite d’Ippon Technologies sur l’excellent site de Nicolas Martignole : l’express board. (bon ok je suis un poil à la bourre elle date de Février…)

******************************************************************************

Chez Ippon Technologies, nous cherchons des consultants capables de lire cette offre d’emploi :

https://github.com/ippontech/IpponRecrute

******************************************************************************

Julien Dubois (passé de SpringSource à Ippon Technologies récemment) a même poussé le vis en encodant le texte de l’annonce dans le code. Il faut donc l’exécuter pour la lire.

Bravo Julien, j’adore l’idée !

Peut-on réussir un forfait ?

Plus je travaille avec des SSII et plus je trouve que les projets gérés au forfait se passent mal. Les torts sont souvent partagés, mais je constate plusieurs causes d’échec :

Le client est incapable de rédiger un cahier des charges

Là je sais de quoi je parle, j’ai souvent le rôle de client en ce moment

Le besoin évolue, n’est pas forcément clair et donc il est très dur de rédiger un cahier des charges exhaustif. Le client est obsédé par la garantie de réalisation qu’apporte le forfait, alors qu’il est incapable d’exprimer correctement son besoin. Pire je vois de plus en plus de forfait où on demande au prestataire de rédiger le cahier des charges : on rêve.

Les acheteurs : price killer

Oui c’est une bonne chose de tirer les prix vers le bas, mais il faut aussi rester raisonnable. Comment voulez-vous travailler sereinement avec des prestataires à qui on a mis le couteau sous la gorge.  Pourquoi pas des enchères inversées pendant qu’on y est ? -souvenir-

Le réflexe « perdant – perdant »

J’ai l’impression d’être le seul à demander aux SSII d’augmenter leur chiffrage quand j’ai l’impression que c’est un peu juste. Une fois j’en parlais à un chef de projet, il m’a même répondu : « Ne leur dis rien, s’ils se plantent c’est pour leur pomme ! ». On sait très bien que ça ne se passe pas comme cela. A un moment si le prestataire s’est vraiment planté, c’est le projet qui va en pâtir (qualité de code, test unitaire, bug..)

L’inter-contrat

Même si les commerciaux sont les spécialistes pour vous faire de beaux discours sur leur « cellule forfait » avec des personnes dédiées. Il ne faut pas se leurrer, le forfait c’est l’idéal pour occuper une personne en inter-contrat. Le problème pour le projet c’est que l’on n’a jamais les mêmes développeurs en face. C’est dur d’assurer une continuité des développements.

Junior en solo

C’est un peu lié au problème des prix tirés vers le bas mais je vois de plus en plus de débutants seuls sur des projets. J’ai absolument rien contre les débutants mais il faut les encadrer. Le problème c’est qu’en SSII des développeurs avec 10 ans d’expérience c’est super rare. Et oui, on vend plus cher un mauvais chef de projet qu’un bon développeur avec de l’expérience.

Le Mythe du forfait de service

Depuis un certain temps on nous a mis en place des « forfaits de services ». Alors ça c’est encore une belle invention d’acheteur qui n’a pas du travailler dans le monde du développement. En gros le principe c’est d’envoyer une demande par email et d’attendre le livrable 2 mois plus tard. Vous ne savez pas qui travaille sur le projet, c’est une boite noire. Et donc on retombe dans les travers des deux précédents points et on va avoir des développeurs Flex juniors qui vont coder du J2EE.

Des solutions ?

Je sors justement d’une expérience forfait un peu difficile. A la signature du contrat tout est beau, c’est une société avec qui je travaille souvent, ils mettent en avant le fait qu’il sont CMMI niveau 3, on parle même d’intégration continue avec Hudson. Bref on est en confiance. Au final on nous livre du code Java d’une qualité affligeante (si si c’est le bon mot quand je trouve des noms de variable avec des accents), zéro test unitaire et cerise sur le gâteau le livrable ne compile pas car il manque des sources.

Malgré tout ça je vais continuer à travailler avec cette société. Car déjà elle n’est pas la seule responsable de cet « échec » mais surtout je pense que c’est avant tout un problème de mauvaise personne au mauvais endroit.

Mais comment faire en sorte que la future prestation se passe bien :

Travailler gagnant – gagnant

Partager les risques avec le prestataire, s’impliquer dans le chiffrage, travailler ensemble.

Choisir les intervenants

Il faut vraiment intégrer que la réussite d’un projet n’est pas lié à la société mais bien aux personnes qui réalisent. Faire passer des entretiens est donc primordial pour sélectionner son équipe. C’est le seul moyen d’être sûr que l’on va pas mettre un Flexeur à gérer des transactions JTA ( oui oui c’est du vécu…).

Faire des revues de code périodiquement

Les chefs de projets qui regardent la qualité du code livré sont rares, mais le faire à la livraison c’est surtout trop tard. Il est très important de bien suivre la qualité du code tout au long de la vie du projet pour s’assurer que ça ne diverge pas.

Et non coder un « proto » n’autorise pas à faire n’importe quoi ! (si je retrouve le gars qui a codé la gestion des transactions à la main dans un filtre HTTP je l’étripe

Conclusion

C’est bête à dire mais pour réussir il faut juste travailler en bonne intelligence avec le prestataire. Arrêter ce rapport maitre/esclave qui ne peut que mal finir et discuter d’égal à égal.

Le client devrait passer plus de temps sur son expression de besoins que sur les petites lignes du contrat cadre. Arrêtez d’être obsédé par la garantie de résultat et de date de livraison complètement illusoire pour vous reconcentrer sur l’essentiel : le produit.

Le développement agile permet de résoudre beaucoup de problèmes. Mais quand je vois que l’on demande à des prestataires de travailler de façon Agile mais en gardant un cadre type forfait avec engagement de résultat, c’est complètement antinomique !

Profiling SQL

C’est une étape souvent négligée par les projets utilisant des librairies de mapping objet. Mais faire de l’Hibernate c’est bien, regarder les requêtes générées sur la base c’est mieux.

J’ai le souvenir d’un vieux projet utilisant des EJB Entity 2 où à un moment on ajoutait un objet dans une liste. En regardant les requêtes on s’est aperçu que le conteneur chargeait toute la liste avant de faire l’insert. C’était complètement inutile.

Donc comment étudier correctement les requêtes ? Déjà si vous utilisez hibernate mettez la property « show_sql » à true de temps en temps. Après pour avoir plus d’informations j’utilise p6spy et IronEye SQL.

p6Spy est une librairie qui remplace votre driver de base de données. C’est en quelque sorte un driver proxy de BDD. IronEye apporte juste une vue graphique des informations récoltées par p6spy. Pour trouver de la doc c’est un peu dur www.p6spy.com ne fonctionne plus mais j’ai trouvé un site expliquant la mise en place de p6spy et de IronSql.

Par contre ce sont deux outils un peu « vieux ». p6spy n’a pas été mis à jour depuis 2003 et pour IronEye SQL la société IronGrid a disparu. Comme il est maintenant impossible de trouver IronEye en téléchargement je vous propose la version 1.2.359 que j’avais heureusement conservée : ironeyesql-installer-1_2_359.jar. (fonctionne que sur Windows chez moi). Le site sourceForge de p6spy est toujours up.

Sans refaire la doc, installer p6spy c’est simple, il faut juste remplacer le nom de votre driver jdbc par com.p6spy.engine.spy.P6SpyDriver et de mettre le nom du vrai driver dans le fichier spy.properties : realdriver = oracle.jdbc.driver.OracleDriver. Pour utiliser IronEye il faut en plus activer un port d’écoute dans le spy.properties :
module.monitor=com.irongrid.monitor.server.MonitorFactory
monitorport=2000

Et voilà ! vous pouvez observer toutes les requêtes faites sur votre base. IronSQL va les regrouper, les compter et calculer le temps moyen d’exécution.

Sans être DBA vous allez très vite voir quelles requêtes sont faites souvent et les plus longues à s’exécuter. Très pratique pour voir si un cache L2 fonctionne bien ou si on a oublié un index sur une table.

Un exemple concret que j’ai corrigé hier :

Dans un service REST on passe en paramètre l’id d’un objet. C’est un service de monitoring appelé par du matériel pour lui passer des infos et s’assurer qu’il est encore en vie (du polling à défaut de push en gros)

Truc t = trucDao.getById(tid);
t.setLastAccess(now);

Assez logique en java avec hibernate, mais l’objet t n’est jamais utilisé après. Le problème c’est qu’au niveau SQL on a un SELECT qui récupère toutes les informations de l’objet pour ensuite faire un UPDATE. Si en plus vous avez configuré des associations de votre objet en lazzy, ça peut être vraiment problématique.

J’ai changé ce code par :

trucDao.updateDateById(tid, now);

Maintenant il ne reste que la requête UPDATE. Lorsque l’on sait que nous allons avoir plusieurs milliers de « Truc » et qu’ils font cette requète toutes les 15 secondes. Je vous laisse calculer le gain en perf. Dans la même fonction j’ai aussi trouvé une requête SQL faite uniquement pour un log debug : no comment.

Best-of Cdp

En 10 ans j’ai croisé pas mal de chefs de projets différents. J’ai envie de vous faire partager plusieurs échanges assez étonnants que j’ai pu avoir avec eux dans différentes sociétés.

Cdp : On est mal sur un projet. Il faut absolument livrer dans 1 mois !
Moi : Ok, je peux peut-être vous aider. Quelle charge en « Reste à faire » il te reste pour livrer ?
Cdp (étonné) : heu… je sais pas. Mais il faut livrer dans 1 mois !
Ils ont livré avec 4 mois de retard


Moi : Comment s’est passée la prestation avec la société X ?
Cdp : Je suis un peu mitigé
Moi : Ah bon ? Pourtant j’ai vu le livrable je trouvais ça pas mal
Cdp : Oui en effet, ils ont fait ce que j’avais mis dans le cahier des charges
Moi : Alors ? Où est le problème ?
Cdp : J’attendais un peu plus
Moi : …


Moi : Je peux voir les sources de ton projet ? Elles sont où en GConf ?
Cdp : heu… J’ai du les mettre quelque part sur un répertoire partagé. Attends je cherche.
2 jours après
Moi : Dis moi, c’est normal que le code compile pas ?


Cdp : On a besoin d’aide pour livrer à temps
Moi : Ok, vous avez regardé quelles features on peut décaler d’une release ?
Cdp : Impossible de réduire, on en a une seule : « l’inscription d’un utilisateur ».
Moi étonné : ah… mais il y a combien de pages web pour cette fonction ?
Cdp : 70 pages
Moi : …
Cdp : Oui ça prend 1h30 à l’utilisateur pour s’enregistrer
Moi : Ah quand même …


Cdp : Tu peux nous aider à nous organiser sur ce projet ?
Moi : Pas de problème, on va faire un Scrum Board. J’ai apporté des post-it !
Cdp : Non mais Samuel, ça va, on a plus 6 ans on va pas perdre du temps avec tes post-it.


Moi : Je viens de regarder les sources de ton projet, y a un gros problème au niveau du code
Cdp : Mais non tu dramatises, c’est en prod ça marche super bien
Moi : Ecoute non, la gestion des transactions est une catastrophe, il faut la refaire.
Cdp : Oui oui, et bien on verra, pour le moment on n’a pas le temps.
2 semaines plus tard
Cdp : Merde le service est KO. Qu’est-ce qui se passe ?


Bien sûr j’ai croisé plus de bons chefs de projet que de mauvais. Mais c’est nettement moins amusant à raconter