IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Un trop grand nombre de choix impacte-t-il la productivité ?


Sujet :

Débats sur le développement - Le Best Of

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Développeur informatique
    Inscrit en
    septembre 2014
    Messages
    194
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : septembre 2014
    Messages : 194
    Points : 12 283
    Points
    12 283
    Par défaut Un trop grand nombre de choix impacte-t-il la productivité ?
    Un trop grand nombre de choix impacte-t-il la productivité ?
    Selon un senior : ceci paralyse les développeurs

    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 ?

  2. #2
    Expert éminent sénior
    Profil pro
    Inscrit en
    décembre 2007
    Messages
    6 484
    Détails du profil
    Informations personnelles :
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations forums :
    Inscription : décembre 2007
    Messages : 6 484
    Points : 30 311
    Points
    30 311
    Par défaut
    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.
    Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
    1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
    2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
    3)le temps de comprendre toutes les exigences, le projet est terminé
    4)le temps de terminer le projet, les exigences ont changé
    Et le serment de non-allégiance :
    Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

  3. #3
    Membre expérimenté
    Profil pro
    chercheur
    Inscrit en
    avril 2004
    Messages
    828
    Détails du profil
    Informations personnelles :
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : chercheur

    Informations forums :
    Inscription : avril 2004
    Messages : 828
    Points : 1 367
    Points
    1 367
    Par défaut l'obsolescence programmée
    Autrement dit : l'obsolescence programmée est-elle un moteur de l'industrie informatique ?
    Ce qui s'énonce clairement se conçoit bien ( Le hautbois)

  4. #4
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    mai 2004
    Messages
    9 881
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : mai 2004
    Messages : 9 881
    Points : 26 950
    Points
    26 950
    Par défaut
    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é.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  5. #5
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 149
    Points : 7 094
    Points
    7 094
    Billets dans le blog
    3
    Par défaut
    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.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  6. #6
    Expert éminent
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    juillet 2013
    Messages
    3 780
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : juillet 2013
    Messages : 3 780
    Points : 8 460
    Points
    8 460
    Par défaut
    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"

  7. #7
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 149
    Points : 7 094
    Points
    7 094
    Billets dans le blog
    3
    Par défaut
    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 !
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  8. #8
    Expert confirmé
    Avatar de TiranusKBX
    Homme Profil pro
    Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Inscrit en
    avril 2013
    Messages
    1 476
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur C, C++, C#, Python, PHP, HTML, JS, Laravel, Vue.js
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2013
    Messages : 1 476
    Points : 4 855
    Points
    4 855
    Billets dans le blog
    6
    Par défaut
    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 ^^
    Rien, je n'ai plus rien de pertinent à ajouter

  9. #9
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    mars 2007
    Messages
    545
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur d'applications métier
    Secteur : Service public

    Informations forums :
    Inscription : mars 2007
    Messages : 545
    Points : 1 483
    Points
    1 483
    Par défaut
    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.

  10. #10
    Expert éminent
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    août 2007
    Messages
    2 132
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : août 2007
    Messages : 2 132
    Points : 7 774
    Points
    7 774
    Par défaut
    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).

  11. #11
    Expert éminent
    Avatar de Matthieu Vergne
    Homme Profil pro
    Consultant IT, chercheur IA indépendant
    Inscrit en
    novembre 2011
    Messages
    2 149
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Consultant IT, chercheur IA indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2011
    Messages : 2 149
    Points : 7 094
    Points
    7 094
    Billets dans le blog
    3
    Par défaut
    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.
    Site perso
    Recommandations pour débattre sainement

    Références récurrentes :
    The Cambridge Handbook of Expertise and Expert Performance
    L’Art d’avoir toujours raison (ou ce qu'il faut éviter pour pas que je vous saute à la gorge {^_^})

  12. #12
    ovh
    ovh est déconnecté
    Rédacteur
    Avatar de ovh
    Homme Profil pro
    Architecte devops web full stack
    Inscrit en
    mai 2002
    Messages
    3 834
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte devops web full stack

    Informations forums :
    Inscription : mai 2002
    Messages : 3 834
    Points : 6 477
    Points
    6 477
    Par défaut
    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...

    Tutoriels sur les UPS, e-commerce, PHP, critiques de livres...

    Pensez à consulter les FAQs et les cours et tutoriels.
    FAQ Linux - Cours et tutoriels Linux - FAQ PHP - Cours et tutoriels PHP
    Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles.

    Je n'ai rien à voir avec la société www.ovh.com !

  13. #13
    Expert confirmé Avatar de marsupial
    Homme Profil pro
    DevOp, Tech leader
    Inscrit en
    mars 2014
    Messages
    1 192
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : DevOp, Tech leader

    Informations forums :
    Inscription : mars 2014
    Messages : 1 192
    Points : 4 555
    Points
    4 555
    Par défaut
    Ne sachant pas si ce sera dans le sujet, mais l'avenir passera par là.
    Je vous recommande le numéro 14 de Open Silicium mars/avril/mai avec un bel article sur le cross compiling fatalement sous Debian GNU/Linux

    Les IoT seront ensuite pilotables depuis une application distante, et là une console dans le navigateur va certainement devenir l'idéal. En tout cas pour moi ce sera en C avec Clang.

    Messieurs vous pouvez reprendre le débat ultérieurement à l'occasion.
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

Discussions similaires

  1. [MySQL] Trop grand nombre de requetes sql ?
    Par Aloam dans le forum PHP & Base de données
    Réponses: 5
    Dernier message: 16/01/2013, 15h41
  2. Réponses: 2
    Dernier message: 25/11/2009, 14h03
  3. Trop grand nombre
    Par bibette dans le forum SAS Base
    Réponses: 4
    Dernier message: 15/10/2008, 00h50
  4. Réponses: 4
    Dernier message: 03/02/2007, 22h27

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo