Interrompons les développeurs !

This article is also available in English.

Le contexte

Vous êtes peut-être comme moi tombés récemment sur des articles expliquant qu’il ne faut surtout pas interrompre des développeurs dans leur travail. C’est un peu comme mettre de l’eau sur un Gremlin : le monde s’écroule si le pauvre garçon (ou la pauvre fille, mais il y en a très peu parmi nous, et surtout je ne les vois pas se plaindre de la sorte) est interrompu.

Il y aurait, il parait, ce “flow”, état quasi-mystique dans lequel le développeur se plonge progressivement et devient capable, sous pleine concentration, de miracles de rapidité en programmation. Jamais de question sur la qualité du code ainsi produit, mais bon…

Au cas où vous auriez raté la mode, voici quelques liens, parmi tant d’autres :

http://www.infoworld.com/d/data-center/no-interruptions-technologist-work-247487

http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

http://programmers.stackexchange.com/questions/46252/how-to-explain-a-layperson-why-a-developer-should-not-be-interrupted-while-neck

http://blog.ninlabs.com/2013/01/programmer-interrupted/

http://casa-laguna.net/all-the-news/show/do.-not.-ever.-interrupt.-a-programmer

http://www.drdobbs.com/tools/just-let-me-code/240168735

La réalité

Oui, bien sûr qu’il faut ménager des moments calmes pour avancer sur du code de manière efficace, mais c’est vrai de n’importe quel type d’activité. Idem pour lire un livre, s’endormir, écrire un article de blog, etc. La plupart des activités (surtout réalisées par des hommes, qui ne sont pas multitâches Sourire) nécessitent que leur auteur n’ait pas son attention morcelée pour être réalisées efficacement. Ce sont des comportements de diva de faire croire que c’est plus important pour les développeurs que pour les autres.

Et surtout, c’est révélateur d’une façon de penser qui pose plusieurs problèmes, de mon humble point de vue.

Problème n°1 : certains pensent que coder est l’activité principal d’un développeur

Je plaide coupable, parce que j’ai longtemps eu ce biais. Je ne compte pas le nombre de programmes que j’ai codés le soir chez moi sans aucune autre utilité que de coder sans avoir à faire de documentation, d’analyse, de schémas explicatifs… J’ai même publié du code en Open Source alors que son utilité pour d’autres (comme le montre le faible nombre de téléchargements) était on ne peut plus limitée.

Avec un peu de recul (le “un peu” est destiné à ne pas me sentir trop vieux, ça fait 28 ans que je code), je sais maintenant que le code représente un quart, maxi 30% du métier de développeur si on veut l’exercer à peu près proprement.

Problème n°2 : est-ce la bonne façon de programmer ?

Si vous avez besoin de 15 minutes pour rentrer dans votre projet, c’est qu’il n’a pas été assez décomposé et la complexité de chaque portion est donc encore trop grande pour être traitée sans incorporer un tas de bug.

S’il faut autant de temps pour remonter la pendule cérébrale d’un développeur à un point où elle sera en mesure de continuer à avancer, c’est que le sujet n’a pas été suffisamment modélisé. Lordon parle d’une “frontière technique”, où des concepts et du vocabulaire spécialisé sont mobilisés pour atteindre rapidement un état dans lequel l’intellect peut continuer à avancer sur une discipline. Peut-être que notre discipline, pourtant pleine de jargon mais très technique, manque de moyens intellectuels et de raccourci sémantique sur la modélisation ?

Problème n°3 : le “flow” est une belle invention…

… mais il y a de bonne chance pour que, lorsque vous le ressentez, vous soyez simplement dans un mouvement de routine. Un peu comme quand vous jouez à Five Dots, et que le fait de supprimer des points devient hypnotique. Vous perdez de vue l’idée de diminuer votre score, et vous finissez par jouer machinalement.

Même chose pour le code : nous avons tous expérimenté ce moment où, pris dans ce “flow” (ou n’importe quelle autre façon de désigner une simple concentration sur un sujet unique), nous nous retrouvons à ajouter des fonctionnalités non prévues, voire seulement prévoir des cas sans qu’ils aient été clairement définis comme des besoins réels de nos utilisateurs.

Vous voulez vous en convaincre ? La prochaine fois que vous sortez du fameux “flow”, supprimez tout le code que vous venez d’écrire. Et recommencez. Vous vous apercevrez que la deuxième fois va beaucoup plus vite, qu’elle ne nécessite pas une concentration particulière (évidemment, puisque vous avez cette fois-ci fait l’effort de décomposer le problème avant de rentrer dans le code) et surtout qu’elle aboutit à un code plus compact et plus propre.

Problème n°4 : une bonne part de fatuité

L’impression que j’ai est que de nombreux développeurs se cachent derrière cette notion de “flow” pour faire croire qu’ils sont très bons en code. Et cette façon d’insister sur l’importance capitale de ne pas interrompre les développeurs (voir tous les liens plus haut, et il suffit de chercher pour en trouver des tas d’autres) sent un peu l’envie de profiter que les gens ne comprennent pas notre travail pour leur raconter n’importe quoi et continuer tranquillement à coder sans faire attention à la qualité autant qu’on devrait.

La qualité du code est toujours un problème, la discipline de l’ingénierie informatique étant encore très jeune par rapport aux autres disciplines d’ingénierie. Il est donc encore plus important de se garder de cette fausse impression de qualité alors que le “flow” est simplement un état de concentration autorisé par le fait qu’on ne réfléchit qu’à une seule chose : le code (et comme dit plus haut, pas ses impacts, ni ses fonctions secondaires, etc.)

Est-ce que mes projets Open Source ou les rares fois où j’étais dans le soi-disant “flow” au bureau ont produit quelque chose de mieux que du code que j’ai réalisé petit à petit ? La réponse est non. Il y a bien eu quelques bouts de code importants (utilisés en production par quelques milliers de clients), mais ils ne sont au final pas de meilleure qualité que d’autres.

Aujourd’hui, si je dois passer plus de dix minutes à coder une fonctionnalité, je ne commence même pas à coder, car ça veut juste dire que je n’ai pas encore suffisamment décomposé le problème pour pouvoir le coder de manière efficace et avec le bon degré de qualité dans chacun de ses composants…

Et tant qu’on y est

Peut-être que c’est le bon moment pour essayer de régler leur compte à quelques imbécilités qu’on lit sur le sujet :

  • Instant Messaging “If you really, really need me, you can interrupt, but expect a grumpy return.” (source) : si c’est tellement important d’être dans le soi-disant “flow”, est-ce que ça ne serait pas tout simplement moins bête d’éteindre Messenger ?
  • Même chose pour Skype (source).
  • La comparaison avec arrêter un chirurgien dans son boulot est peut-être le pompon (même endroit que le point précédent) : en plus d’être d’une vantardise extraordinaire (sérieux, il y a peut-être 1% d’entre nous informaticiens qui bossons sur des programmes dont dépendent des vies), la comparaison est de toute façon erronée : sur une opération qui dure quelques heures, un chirurgien s’interrompt sans arrêt, utilise l’aide de ses assistants, explique à un interne la façon dont il procède, etc. Il ne se colle pas un casque sur les oreilles pour travailler tranquille, quitte à faire des erreurs que personne ne pourra contrôler.
  • Et tellement d’autres que je ne vais pas m’appesantir là-dessus…

Conclusion

Interrompons les développeurs ! Sérieusement ! Si vous voyez un développeur qui a son casque sur les oreilles et qui ne fait que taper sur son clavier depuis deux heures, stoppez-le… Dites-lui de prendre une pause, de réfléchir deux minutes à ce qu’il fait, de vous l’expliquer. Dites-lui de faire un schéma, de reposer avec vous une autre façon de décomposer le problème en classes. Pensez-vous vraiment qu’il n’aura rien à reprendre sur son code pondu en une seule séance ? Qu’à deux vous n’aurez aucune idée d’amélioration ?

About JP Gouigoux

Jean-Philippe Gouigoux est Architecte Logiciel, MVP Connected Systems Developer. Il intervient régulièrement à l'Université de Bretagne Sud ainsi qu'à l'Agile Tour. Plus de détails sur la page "Curriculum Vitae" de ce blog.
This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to Interrompons les développeurs !

  1. Christophe says:

    Bonne réflexion sur l’excuse un peu facile de la zone. Je reconnais que ces moments existent, ce sont simplement des moments de concentration aiguë, qui améliorent au moins en apparence la productivité.
    Par rapport à ta conclusion, clairement on peut difficilement rester concentré deux heures donc la clairement l’interruption est nécessaire et opportune.

    Là ou je vais moins dans ton sens c’est sur le côté négatif.

    Je pense qu’il est bon de privilégier l’émergence de tels moments dans la journée des développeurs mais que rassembler les conditions pour ne pas être dérangé est en grande partie à la charge du développeur. Tu parlais de l’IM et clairement un développeur ne peut pas se plaindre d’être tout le temps dérangé s’il ne coupe pas lui même les notifications de son IM et ferme son lecteur d’e-mail. Des écouteurs, un panneau “ne pas déranger avant H:MM”, peu importe c’est à la portée de n’importe qui. Donc oui l’histoire du “flow” est souvent une excuse, si un développeur en a besoin il peut se le créer. La méditation est d’ailleurs encouragée pour s’entraîner à rentrer plus rapidement dans cet état de forte concentration.

    L’autre point qui me dérange c’est la qualité. La qualité du code est à la charge du développeur et de son équipe. Il a la responsabilité première d’écrire du code de qualité mais son code ne peut pas toujours être parfait (qu’il soit écrit dans le flow ou pas) et son équipe est là pour lui rappeler. Et puis rien n’exclut une revue personnelle de code après un moment dans la zone et surtout rien n’empêche de rentrer dans la “zone” pendant une code review 😉 C’est ce processus qui doit permettre de remettre en cause “des fonctionnalités non prévues” et réfléchir sur “des cas” qui n’ont pas “été clairement définis”. Le développement doit rester itératif, ce qui sort de la zone ne doit pas aller directement dans le produit, je te suis là dessus.

    Par contre je me demandais si on pouvait “zoner” en pair-programming 🙂

    • JP Gouigoux says:

      Merci pour ces commentaires, Christophe !

      Sur ta dernière remarque, je dirais que, justement, le pair programming me parait un excellent moyen pour éviter que la “zone” ne tourne à un aveuglement complet par rapport aux besoins effectifs de fonctionnalités du code. Il me semble plus difficile à deux de se retrouver embarqué à coder plus qu’il ne faut. Après, c’est peut-être une impression, et d’autres diraient peut-être qu’au contraire, il y a un effet d’entraînement, de surenchère qui serait encore pire…

      Mais je suis d’accord qu’une bonne revue de code permet de recadrer la qualité de code. L’inconvénient est qu’on a souvent tendance à régler la qualité du code proposé, mais pas à remettre en cause la présence même du code. Il est donc facile de se laisser abuser en revue de code par quelqu’un qui a créé des fonctionnalités inutiles si elles sont bien codées.

      • Christophe says:

        Effectivement, même en revue de code on peut être tenté de laisser passer des fonctionnalités non prévues juste parce que “le boulot a été fait, ça serait dommage de le jeter”.
        Ça montre bien qu’il est difficile de définir et surtout d’appliquer une éthique forte dans ces cas là au risque de paraître religieux ou comme l’emmerdeur de service (vécu sur les messages de commit ;-).)
        La décision doit être prise par l’équipe et elle n’ira pas toujours dans ton sens.

  2. Chris says:

    Effectivement, comparer du développement à une opération à cœur ouverte d’un chirurgien est abusivement exagérée.

    Tout comme il est, à mes yeux, tout aussi abusif de comparer du développement à … une sieste. N’importe qui peut faire une sieste.

    Je ne sais pas si vous travaillez dans une open space, donc je ne vous jetterai pas la pierre, mais c’est mon cas pour moi.

    Les interruptions sont vraiment multiples et cassent mon rythme, ou plutôt ce que j’appelle le “mental workload”.

    Leonard de Vinci disait “De même que tout royaume divisé est bientôt défait, toute intelligence qui se divise en plusieurs études différentes s’embrouille et s’affaiblit.”

    A mon avis, il est donc important, oui, de pouvoir s’isoler de demander à ne pas être dérangé.

    Mais je suppose que tout ça dépend de l’ambiance dans laquelle on travaille et de nos expérience respective.

    L’image du geek qui code en mode tunnel, et qui ne ressort pas de son trou tel un autiste avant un moment me parait non seulement exagéré, mais surtout, je l’espère, dépassée.

    • JP Gouigoux says:

      Bonjour, Chris, et merci pour votre commentaire.

      Nous travaillons en Open Space, et je suis tout-à-fait d’accord sur l’importance dans certains cas de s’isoler pour avancer sur des tâches bien précises. Je critique juste le fait que certains veulent ériger cet isolement comme mode de fonctionnement optimal d’un développeur. C’est pour moi dangereux dans le sens où la réflexion sur le besoin client, l’échange avec l’équipe sont au moins, voire plus, importants que la simple activité de codage.

      Malheureusement, on trouve tant et plus de ces articles (tiens, encore un récent que j’aurais pu ajouter à la liste : http://www.computerworld.com/article/2598334/it-management/paul-glen-you-cant-wear-the-manager-and-developer-hats-at-the-same-time.html) qui expliquent que le développeur doit être en état d’immersion intellectuelle profonde pour se lancer dans un codage long.

      Encore une fois, il y a pour moi un véritable danger à chercher à tout prix la prouesse de l’esprit (l’envie de tout résoudre en une seule apnée de programmation), au lieu de commencer par décomposer le problème en atomes plus facilement réalisables. L’approche que vous citez de Vinci ne me parait pas le moins du monde incompatible avec le réductionnisme de Descartes. La bonne recette, de mon point de vue, est justement d’utiliser les deux : d’abord découper les tâches et bien les comprendre en équipe, puis faire de COURTES isolations pour coder. Le terme important étant “COURTES”. De mon expérience, si ça prend plus d’une heure, c’est au-delà de la capacité de concentration optimum. Ce n’est pas pour rien que les approches de type “Pomodoro” se basent sur des cycles de 25 minutes.

      En espérant avoir réconcilié nos points de vue,

      JP

      • Chris says:

        Je suis tout à fait d’accord avec vos précisions.

        Je vois la maxime de De Vinci, comme le fait de fragmenter les tâches complexes d’une même étude, en plusieurs petites tâches.

        L’humain sait relativement bien résoudre de petits problèmes simples, il a davantage de mal sur un seul gros problème complexe.

        Je reste par contre persuader qu’il faut éviter la multiplication “des fronts différents”, c’est à dire de travailler sur une même semaine sur différents projets.

        Je ne sais pas vous, mais personnellement j’ai toujours un temps de latence nécessaire pour retrouver mentalement le contexte: entrées, sorties, buts, problèmes, etc…

        Et au plus je change de contextes, au plus ces temps de latences se multiplient.

        C’est donc, encore une fois pour moi -je peux comprendre que cela n’en gêne pas d’autres- une source de gêne et de perte d’efficacité.

        Mais je partage votre point de vue sur les personnes qui travaillent en isolé, sans contact avec l’équipe.

        Avant, je pouvais insister sur une journée, et travailler (coder) plus de huits heures, parfois 10, voir 11.

        C’est complètement improductif. Le lendemain on relit ce qu’on a fait, et l’on se dit : Mais… C’est moi qui ai écrit ça ?

        Aujourd’hui je sais m’arrêter 😉

        Merci pour cet échange, et pour votre blog !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha Captcha Reload