Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un trop grand nombre de choix impacte-t-il la productivité ?
Selon un senior, cela paralyse les développeurs

Le , par Amine Horseman

44PARTAGES

1  0 
Dans un billet de blog, Jason Gorman, le fondateur de Codemanship, s’intéresse à la productivité des développeurs, et plus particulièrement sur la relation entre les standards de code restrictifs et la productivité.

L’origine de ce billet remonte à il y a plus d’un mois, lorsque Gorman eut une discussion avec un de ces clients dont l’équipe avait mis au point un système leur permettant de contrôler la qualité de leurs codes avant de son intégration. Le fonctionnement de ce système de contrôle est assez simple : il détecte les commits qui introduisent de nouveaux threads dans le code et les places dans une file d’attente pour être jugées par l’équipe. Si les autres développeurs de l’équipe pensent que le thread introduit n’est pas nécessaire, ils peuvent refuser d’intégrer ce commit au code source de la solution.
La raison pour l’ajout d’une telle restriction est que le code introduisant du multithreading couterait plus cher à l’équipe : « nous avons tous remarqué ce que la complexité inutile fait à notre code. Il le rend plus difficile à comprendre, plus difficile à modifier et plus susceptible de contenir des erreurs. Le multithreading ajoute sans doute la forme la plus pernicieuse de complexité, la création d'une explosion dans les manières que peut avoir notre code pour mal fonctionner ».

Toutefois, ce qui intéressait Jason Gorman n’était pas les effets du multithreading sur la complexité du code, mais plutôt « l'impact que peuvent avoir les standards de codage rigoureusement appliqués sur la productivité ». Il affirme que « les normes sont des règles, et les règles sont des contraintes », et les contraintes limitent le nombre de solutions possibles pour résoudre un problème, ce qui est bénéfique pour l’équipe de développement selon lui, puisque les « les programmeurs sont paralysés lorsqu’il y a trop de choix ». Il argumente son avis en citant un exemple du quotidien où il est plus facile de cuisiner un plat se limitant aux seuls ingrédients disponibles chez soi que de considérer la liste des ingrédients disponibles dans le super marché. « Sur le long terme, nous nous limitons à éviter d'être submergés par le choix dans le feu de l’action, quand les décisions peuvent avoir besoin d'être prises rapidement. Mais nous nous limitons à une bonne sélection de choix - ou devrais-je dire, une sélection de bons choix - qui va marcher dans la plupart des situations. Tout comme Einstein limitait sa garde-robe pour qu'il puisse passer [plus de temps] à inventer la gravité ou quoique ce fut ce qu'il faisait ».

Mais il ne faut, selon lui, pas tomber dans le piège de faire de « l’analyse de nouvelles solutions » ainsi que « l’essai de nouveaux langages / plateformes / outils » une activité explicite : ceci aurait « l'effet indésirable de créer une option supplémentaire pour les gestionnaires non techniques. Tout comme le refactoring, il est probablement plus sage d’enlever cette tâche de leur attribution ».

Il suggère de retarder cette découverte de nouvelles solutions jusqu’au moment où on trouve que notre boîte à outils est trop limitée pour faire une certaine tâche. Une fois arrivé ce moment, « nous devrons improviser comme nous le faisons toujours » avant de passer au mode Recherche et Développement : « Dans l'Extreme Programming, nous appelons cela les "spikes" ». Le but est d’éviter de perdre du temps dans les choix alors qu’on peut avoir « une très bonne solution que nous pourrions appliquer immédiatement ».

Source : Codemanship

Et vous ?

Êtes-vous d’accord avec l’avis de Jason Gorman ?
Selon vous, avoir plus de choix est-il bénéfique pour un développeur ou pas ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 01/04/2015 à 12:04
Le problème de cette solution est que si on limite trop les solutions disponibles pour le développeur, celui-ci va finir par réinventer la roue à chaque fois en se disant que oui, il y a bien la solution schmoll qui fonctionne, mais elle va être refusée, et donc autant la ré-écrire à la main.

Et le soucis est que ré-écrire à la main des outils validés et éprouvés est souvent une perte de temps et une augmentation de la complexité, à l'inverse donc du but recherché.
4  0 
Avatar de ovh
Rédacteur https://www.developpez.com
Le 02/04/2015 à 17:49
D'un autre côté, si on s'empêche d'explorer de nouvelles solutions/technos, on ne le fait jamais et on stagne en compétence...

Certes ce n'est pas l'idéal pour les parties critiques d'une grosse appli de production, mais sur les petits projets moins critiques, ou les parties moins sensibles, ça peut être pas mal d'en profiter pour faire un peu de R&D.

Car, on le sait tous, très rares sont les employeurs qui accordent vraiment du temps pour la formation continue, que tout développeur devrait pourtant avoir... Donc, à un moment, il faut essayer de l'imposer en en faisant au compte-gouttes dans les projets réels...
4  0 
Avatar de Cincinnatus
Membre expérimenté https://www.developpez.com
Le 02/04/2015 à 11:50
Envoyé par Matthieu Vergne
1 - Make it works -> utilise quelqu'un qui est juste là pour faire son job
2 - Make it right -> utilise un perfectionniste en modelling
3 - Make it fast -> utilise un perfectionniste en performance
Produire un logiciel qui fonctionne correctement (Make it works) n'est déjà pas à la portée de tous les programmeurs que j'ai croisés...
Donc ce n'est pas quelqu'un juste là pour faire son job. Un "développeur" juste là pour faire ses heures ne verra pas d'inconvénient à débuguer en prod, par exemple.

Limiter les choix en cours de développement est nécessaire, sauf à rencontrer de nouveaux besoins non couverts par les solutions retenues.
Il est préférable de se concentrer sur le projet en cours que se disperser sur des comparaisons d'outils et d'employer "en vrai" des solutions qu'on ne maîtrise pas encore.

Il y a donc un temps pour la veille technologique et la mise à jour des solutions techniques, et un temps pour le développement employant des solutions maîtrisées.
3  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 01/04/2015 à 15:04
Je suis aussi d'avis que trop de choix tue le choix. Mais c'est toujours une question d'équilibre : ni trop, ni pas assez. Il ne s'agit pas de dire "il faut qu'on puisse choisir" et se faire mitrailler de propositions au point de ne plus savoir combien il y en a, ni de dire "il faut pouvoir se focaliser" et proposer 2 solutions, une évidemment nulle et l'autre franchement discutable.

De là à parler de paralysie, je pense que c'est un peu exagéré, mais c'est vrai que quand le problème reste ouvert certains ont tendance à se dire "mais peut-être que..." sans arrêt. Surtout les perfectionnistes. Prioriser, ça s'apprend, et filtrer ça s'apprend aussi. Le tout étant de se recentrer sur les objectifs actuels : ont cherche une solution à un problème, pas la solution à tous les problèmes.

Je ne pense pas qu'il y ait de nombre magique pour poser une limite, en revanche je pense qu'il est important de savoir exploiter le feeling de chacun :
1 - Make it works -> utilise quelqu'un qui est juste là pour faire son job
2 - Make it right -> utilise un perfectionniste en modelling
3 - Make it fast -> utilise un perfectionniste en performance

Si on a quelqu'un qui a plusieurs de ces facettes, alors ça demandera moins de main d'oeuvre, mais il faut qu'il sache s'organiser pour ne pas y aller dans le mauvais ordre. Pour ma part, je pense être clairement du 2 et partiellement du 3, du coup il m'est difficile de faire du 1 sans y mettre beaucoup de temps. Ma productivité est donc plus exponentielle (beaucoup de préparation avant une implémentation rapide et efficace) que linéaire : ça permet d'avoir plus de qualité, mais c'est stressant niveau deadlines.
2  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 01/04/2015 à 23:37
Citation Envoyé par Matthieu Vergne Voir le message
Je suis aussi d'avis que trop de choix tue le choix. Mais c'est toujours une question d'équilibre : ni trop, ni pas assez. Il ne s'agit pas de dire "il faut qu'on puisse choisir" et se faire mitrailler de propositions au point de ne plus savoir combien il y en a, ni de dire "il faut pouvoir se focaliser" et proposer 2 solutions, une évidemment nulle et l'autre franchement discutable.

De là à parler de paralysie, je pense que c'est un peu exagéré, mais c'est vrai que quand le problème reste ouvert certains ont tendance à se dire "mais peut-être que..." sans arrêt. Surtout les perfectionnistes. Prioriser, ça s'apprend, et filtrer ça s'apprend aussi. Le tout étant de se recentrer sur les objectifs actuels : ont cherche une solution à un problème, pas la solution à tous les problèmes.

Je ne pense pas qu'il y ait de nombre magique pour poser une limite, en revanche je pense qu'il est important de savoir exploiter le feeling de chacun :
1 - Make it works -> utilise quelqu'un qui est juste là pour faire son job
2 - Make it right -> utilise un perfectionniste en modelling
3 - Make it fast -> utilise un perfectionniste en performance

Si on a quelqu'un qui a plusieurs de ces facettes, alors ça demandera moins de main d'oeuvre, mais il faut qu'il sache s'organiser pour ne pas y aller dans le mauvais ordre. Pour ma part, je pense être clairement du 2 et partiellement du 3, du coup il m'est difficile de faire du 1 sans y mettre beaucoup de temps. Ma productivité est donc plus exponentielle (beaucoup de préparation avant une implémentation rapide et efficace) que linéaire : ça permet d'avoir plus de qualité, mais c'est stressant niveau deadlines.
je suis les 3 mais mes programmes passe par les 3 étapes à tour de rôle
car 1 le client veut un truc qui marche rapidement
en 2 le client veut un fonctionnement parfait et de nouvelles fonctions
et en 3 il te demande de l'optimiser

mais souvent il arrête à la 1 ^^
2  0 
Avatar de Saverok
Expert éminent https://www.developpez.com
Le 02/04/2015 à 13:04
Au moment de la conception, je suis pour avoir le maximum de choix
Ce sont les compétences du/des concepteurs et architectes qui vont déterminer si les frameworks / API actuels couvrent le besoin ou s'il est nécessaire d'en introduire une nouvelle et la sélectionner.

Au moment du développement, c'est trop tard.
Ces choix se font en amont dès la phase de cadrage technique (puis précision lors de la conception).
2  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 02/04/2015 à 15:31
Citation Envoyé par Saverok Voir le message
Au moment de la conception, je suis pour avoir le maximum de choix
Ce sont les compétences du/des concepteurs et architectes qui vont déterminer si les frameworks / API actuels couvrent le besoin ou s'il est nécessaire d'en introduire une nouvelle et la sélectionner.

Au moment du développement, c'est trop tard.
Ces choix se font en amont dès la phase de cadrage technique (puis précision lors de la conception).
Je suis à moitié d'accord. Rien n'empêche une meilleure idée de surgir plus tard, et il serait dommage de ne pas l'exploiter parce que "ça n'a pas été prévu comme ça". Les méthodes agiles exploitent ce phénomène en rapprochant les deux phases au plus proche, et dans ces conditions il devient difficile de faire une séparation aussi stricte, vu qu'on passe son temps à switcher de l'un à l'autre. Donc sur le principe je suis d'accord, mais de manière pratique ça peut être bien plus synchrone que la manière dont tu le présentes.
2  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 31/03/2015 à 13:08
Je suis dubitatif sur ce sujet précis, mais je serais heureux de lire les commentaires.

Par contr, il me semble qu'une norme de codage stricte aide fortement la relecture, et donc la maintenance. Pour l'écriture initiale, je ne sais pas, mais pour la suite, j'approuve.
0  0 
Avatar de foetus
Expert éminent https://www.developpez.com
Le 01/04/2015 à 15:45
Citation Envoyé par Matthieu Vergne Voir le message
3 - Make it fast -> utilise un perfectionniste en performance
Tiens je l'aurais plutôt traduit "Code le le plus rapidement possible"

J'aurais plutôt dit: "Make it fastest/ Make it faster than actual"
0  0 
Avatar de Matthieu Vergne
Expert éminent https://www.developpez.com
Le 01/04/2015 à 17:54
Manque de bol, j'ai dit "fast", pas "quickly". Et je crois que c'est de Knuth, donc même si c'est pas bon... c'est pas ma faute à moi !
0  0