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

Affichage des résultats du sondage: Quelles sont les lois qui impactent votre travail le plus souvent ?

Votants
93. Vous ne pouvez pas participer à ce sondage.
  • Loi de Murphy

    53 56,99%
  • Loi de Brooks

    32 34,41%
  • Loi de Hofstadter

    54 58,06%
  • Loi de Conway

    17 18,28%
  • Loi de Postel ou principe de robustesse

    14 15,05%
  • Loi de Pareto

    32 34,41%
  • Principe de Peter

    34 36,56%
  • Principe de Kerckhoffs

    13 13,98%
  • Loi de Linus

    16 17,20%
  • Loi de Moore

    5 5,38%
  • Loi de Wirth

    22 23,66%
  • Principe du 90-90

    43 46,24%
  • Principe d'optimisation de Knuth

    15 16,13%
  • Loi de Norvig

    9 9,68%
  • Autres (à préciser)

    1 1,08%
  • Pas d'avis

    2 2,15%
Sondage à choix multiple
  1. #1
    Chroniqueur Actualités
    Avatar de Michael Guilloux
    Homme Profil pro
    Analyste
    Inscrit en
    juillet 2013
    Messages
    2 352
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 30
    Localisation : Côte d'Ivoire

    Informations professionnelles :
    Activité : Analyste
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : juillet 2013
    Messages : 2 352
    Points : 75 834
    Points
    75 834
    Billets dans le blog
    2
    Par défaut Trolldi : les célèbres lois de l'informatique et du développement logiciel
    Trolldi : les célèbres lois de l'informatique et du développement logiciel
    quelles sont celles qui impactent votre travail le plus souvent ?

    Comme dans tout autre domaine, le monde du développement logiciel comporte des règles, principes et lois que les développeurs et autres professionnels de l'informatique ont souvent tendance à citer dans leurs discussions ou observer dans leur travail quotidien. Ces lois, règles ou principes sont énoncés expressément par des célébrités du monde ou tirés des livres et déclarations de ces dernières et reconnus en tant que tels par la communauté IT. Ci-dessous, une liste de lois, règles et principes du monde IT, avec dans certains cas, des interprétations dont elles font l'objet.

    La loi de Murphy

    La loi de Murphy est un adage énonçant que « tout ce qui est susceptible de mal tourner tournera mal ». Selon une variante plus détaillée de la loi : « S'il existe au moins deux façons de faire quelque chose et qu'au moins l'une de ces façons peut entraîner une catastrophe, il se trouvera forcément quelqu'un quelque part pour emprunter cette voie. »

    On peut interpréter la loi de Murphy comme une règle de conception : on ne considère pas la loi de Murphy comme vraie, mais on conçoit tout système comme si la loi était vraie. En particulier, un équipement doit être à l'épreuve non seulement des accidents les plus improbables, mais aussi des manœuvres les plus stupides de la part de l'utilisateur. Elle justifie donc les principes de la conception défensive préconisant de planifier et d'éliminer d'emblée les possibilités de mauvaise utilisation.

    La loi de Brooks

    La loi de Brooks — d'après Frederick Brooks — est une prédiction sur la productivité des projets informatiques : « Ajouter des personnes à un projet en retard accroît son retard ». Le postulat est que la plupart des tâches ne sont pas partitionnables et que les nouveaux arrivants vont faire perdre du temps aux équipes en place en temps de communication. Ce temps perdu étant proportionnel à n(n-1) (où n est le nombre de personnes impliquées). Le paramètre taille d'une équipe influe comme une loi de rendement décroissant dans la productivité en informatique. Une analogie culinaire est qu'en étant 300 dans une cuisine pour faire un œuf au plat il ne sera pas possible de servir le plat 300 fois plus vite.

    La loi de Hofstadter

    La loi de Hofstadter (ou Loi de glissement de planning) est une loi empirique concernant la difficulté de la planification dans le domaine de la recherche et du développement. Elle est régulièrement constatée dans le domaine du développement de logiciel. Elle affirme : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. »

    Derrière une telle formulation, la loi de Hofstadter rend compte d'une difficulté universelle : il est presque impossible de prévoir le temps qui sera nécessaire à l'accomplissement d'une tâche complexe. Cette impossibilité est mise en exergue par le caractère auto-référentiel de la phrase qui se cite elle-même : de ce fait, elle introduit un « raisonnement en boucle ».

    La loi de Conway

    La loi de Conway est un adage attribué à Melvin Conway qui stipule que « les organisations qui définissent des systèmes ... sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation. » Elle s'appuie sur le fait que pour fonctionner, un composant logiciel qui a de multiples auteurs nécessite à ceux-ci de communiquer fréquemment. C'est ainsi que la structure des interfaces logicielles d'un système sera le reflet des limites sociales de l'organisation qui l'a produite, au travers desquelles la communication est plus difficile.

    Une variante de la loi de Conway, proposée par Eric Raymond, un militant de l'open source qui a cofondé l'Open Source Initiative, est que « si vous avez quatre équipes travaillant sur un compilateur, vous aurez un compilateur à quatre étapes ».

    Loi de Postel ou principe de robustesse

    « Soyez tolérant [libéral] dans ce que vous acceptez, et pointilleux [conservateur] dans ce que vous envoyez ». Ce principe, attribué à John Postel, est l'un des principes fondateurs de l'approche qui sous-tend le protocole TCP, et se veut une proposition pour augmenter la résilience et la robustesse du code.

    Loi de Pareto

    La loi de Pareto, ou encore loi des 80-20, est un phénomène empirique constaté dans certains domaines : environ 80 % des effets sont le produit de 20 % des causes. C'est le principe derrière la douloureuse vérité que 80 % des bogues proviennent de 20 % du code. Une autre application de cette loi est que 80 % du travail réalisé dans une entreprise est effectué par 20 % du personnel. Le problème est qu'on n’a pas toujours une idée précise de quel 20 % il s'agit.

    Principe de Peter

    Le principe de Peter est une loi empirique relative aux organisations hiérarchiques. Selon ce principe, « dans une hiérarchie, tout employé a tendance à s'élever à son niveau d'incompétence », avec pour corollaire : « avec le temps, tout poste sera occupé par un employé incapable d'en assumer la responsabilité ». Autrement dit, le principe stipule que la promotion à un poste est basée sur la performance du candidat dans son rôle précédent plutôt que dans le rôle qu'il va occuper.

    Principe de Kerckhoffs

    Le principe de Kerckhoffs stipule qu'en cryptographie, « un système doit être sécurisé même si tout ce qui le concerne, à l'exception d'un petit élément d'information - la clé - est connu par le public. » Autrement dit, la sécurité d'un cryptosystème ne doit reposer que sur le secret de la clé.

    La loi de Linus

    En informatique, la loi de Linus, nommée en l'honneur de Linus Torvalds, et formulée par Eric Raymond, concerne le développement de logiciel. La loi indique qu’« avec suffisamment d'yeux, tous les bugs sont superficiels » ; ou plus formellement : « avec un groupe de bêta-testeurs et de co-développeurs suffisamment large, presque tous les problèmes seront rapidement analysés et le correctif sera évident pour l'un d'entre eux ». Présenter le code à une multitude de développeurs avec l'objectif d'avoir un consensus sur son acceptation est une forme simple de la revue de logiciel. La loi de Linus fait généralement partie de la philosophie de base des adeptes du mouvement open source et du logiciel libre.

    Loi de Moore

    Dans sa version la plus populaire, la loi de Moore stipule que le nombre de transistors dans les microprocesseurs double tous les deux ans. Mais il existe des pseudo lois de Moore, variables et sans lien avec les énoncés réels de Moore, qui sont largement diffusées comme celle selon laquelle la puissance des ordinateurs va doubler tous les deux ans.

    Loi de Wirth

    La loi de Wirth est une loi empirique qui stipule que « les programmes ralentissent plus vite que le matériel accélère ». Ou bien : le nombre d'instructions nécessaires à l'interprétation de programmes plus sophistiqués demande des ordinateurs plus rapides.

    Autrement dit, alors que le matériel devient de plus en plus rapide, les programmes n'accélèrent pas pour autant. Au contraire, ils deviennent de plus en plus gros et lents, les développeurs justifiant cette lenteur excessive comme compensée par la loi de Moore. La loi de Moore devient ainsi une excuse à la production de bloatware. Les logiciels ont une lenteur ressentie constante bien que la puissance processeur de leur matériel augmente.

    Le principe du 90-90

    Le principe stipule que « le développement des premiers 90 % du code représentent 90 % du temps de développement. Les 10 % restants prennent 90 % du temps de développement. » Cela fait donc 180 % du temps de développement. Ce principe cherche à mettre en évidence le fait que les projets logiciels ont en général tendance à dépasser largement le temps de développement prévu. Ce principe non seulement exprime l'allocation approximative de temps aux parties faciles et difficiles d'un projet de programmation, mais aussi explique le retard de nombreux projets par l'incapacité d'anticiper les parties difficiles. En d’autres termes, la réalisation d’un projet nécessite toujours plus de temps et plus de codage que prévu.

    Le principe d'optimisation de Knuth

    Le principe formulé par Donald Knuth stipule que « l'optimisation prématurée est la source de tous les maux. » Ce principe est considéré comme la règle numéro un de l'optimisation : l'optimisation ne doit intervenir qu'une fois que le programme fonctionne et répond aux spécifications fonctionnelles. L'expérience montre qu'appliquer des optimisations de bas niveau du code avant que ces deux conditions ne soient réalisées revient le plus souvent à une perte de temps et s'avère néfaste à la clarté du code et au bon fonctionnement du programme. Cependant cette citation, tronquée, est très souvent mal interprétée. On propose donc une version complète du principe d'optimisation de Knuth : « On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux. »

    Loi de Norvig

    En juillet 1999, un article de presse indiquait que l'utilisation des PC avait encore doublé aux USA, atteignant 50 % des foyers américains. Les gens voyaient cela comme un signe supplémentaire de l'inévitable ascension des PC, mais Peter Norvig le voyait plutôt comme un avertissement indiquant que « le verre était à moitié vide » et a formulé ce qui suit, appelé loi de Norvig : « Toute technologie dépassant un taux de pénétration de 50 % ne doublera plus jamais (dans un nombre quelconque de mois) [son taux de pénétration, NDLR]. »

    Source : Tim Sommer

    Et vous ?

    Quelles sont les lois qui impactent votre travail le plus souvent ? Et comment ?
    Votre loi préférée a-t-elle été omise ? Si oui, de quelle loi s'agit-il ? Que dit-elle et comment vous impacte-elle ?
    Êtes-vous d'accord ou pas avec chaque loi énoncée ici ? Avez-vous une expérience (amusante) avec l'une d'entre elles ?

    Voir aussi :

    Trolldi : toi aussi joue à Fortnite et gagne 10 millions de dollars en un an, une bonne façon de gagner sa vie ?
    Trolldi : après les emplois humains, les robots voudraient-ils prendre la place de nos animaux de compagnie ? Lovot souhaite vous rendre heureux
    Best of Trolldi : quels ont été vos trolldi préférés en 2018 ? Voici les 10 trolldi les plus lus de 2018
    Trolldi : Google et l'ONU sont parmi les pires auteurs d'erreurs liées aux MdP en 2018, d'après les résultats d'une enquête
    Trolldi : comment certains auteurs et développeurs voient-ils les langages de programmation ? Petite compilation de citations dans l'industrie
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté Avatar de Cincinnatus
    Homme Profil pro
    Développeur d'applications métier
    Inscrit en
    mars 2007
    Messages
    544
    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 : 544
    Points : 1 481
    Points
    1 481
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    Loi de Norvig

    « Toute technologie dépassant un taux de pénétration de 50 % ne doublera plus jamais (dans un nombre quelconque de mois) [son taux de pénétration, NDLR]. »
    Soit t = taux de pénétration d'une technologie, cette loi dit donc que lorsque t dépasse 50%, il ne peut plus doubler.
    Autrement dit, si t1 = 0.500000000000001, t ne peut atteindre 2 fois t1, soit 1.000000000000002, par exemple, soit plus de 100%.

    En clair, un taux de pénétration ne peut dépasser 100%. Ce ne serait pas une évidence ?

  3. #3
    Membre averti
    Homme Profil pro
    Développeur informatique
    Inscrit en
    avril 2013
    Messages
    103
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Bâtiment

    Informations forums :
    Inscription : avril 2013
    Messages : 103
    Points : 362
    Points
    362
    Par défaut
    Citation Envoyé par Cincinnatus Voir le message
    Soit t = taux de pénétration d'une technologie, cette loi dit donc que lorsque t dépasse 50%, il ne peut plus doubler.
    Autrement dit, si t1 = 0.500000000000001, t ne peut atteindre 2 fois t1, soit 1.000000000000002, par exemple, soit plus de 100%.

    En clair, un taux de pénétration ne peut dépasser 100%. Ce ne serait pas une évidence ?
    C'est le Captain Obvious du monde de l'informatique.
    Le pire c'est que je vois pas où il veux en venir avec son histoire de verre vide et son "avertissement"......que se passera t'il quand l'autre moitié du verre seras plein.......
    "-Sarah Connord?
    -Non. C'est à côté!"

  4. #4
    Membre actif
    Homme Profil pro
    Consultant informatique
    Inscrit en
    octobre 2012
    Messages
    82
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Suisse

    Informations professionnelles :
    Activité : Consultant informatique
    Secteur : Finance

    Informations forums :
    Inscription : octobre 2012
    Messages : 82
    Points : 276
    Points
    276
    Par défaut
    Citation Envoyé par vanskjære Voir le message
    C'est le Captain Obvious du monde de l'informatique.
    Le pire c'est que je vois pas où il veux en venir avec son histoire de verre vide et son "avertissement"......que se passera t'il quand l'autre moitié du verre seras plein.......
    Il veut dire par là que la croissance ne peut que ralentir et à terme être nulle.

  5. #5
    Membre éclairé
    Homme Profil pro
    Développeur backend junior - Symfony
    Inscrit en
    janvier 2018
    Messages
    325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : Développeur backend junior - Symfony
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2018
    Messages : 325
    Points : 778
    Points
    778
    Par défaut
    Pour le taux de pénétration d'un produit, est-ce que, dans l'idée, ce genre de principe peut être appliqué dans l'économie (vis à vis de la question de la croissance) ?

    On cherche à toujours avoir de la croissance, même quand elle est pratiquement impossible à obtenir (cf. les pays riches qui ont fini leur développement et font parti des pays à "croissance lente" et qui, par définition, ne peuvent que très difficilement avoir des taux de croissance réellement important).

  6. #6
    Nouveau membre du Club Avatar de Runhide
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2017
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2017
    Messages : 35
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par Cincinnatus Voir le message
    Soit t = taux de pénétration d'une technologie, cette loi dit donc que lorsque t dépasse 50%, il ne peut plus doubler.
    Autrement dit, si t1 = 0.500000000000001, t ne peut atteindre 2 fois t1, soit 1.000000000000002, par exemple, soit plus de 100%.

    En clair, un taux de pénétration ne peut dépasser 100%. Ce ne serait pas une évidence ?
    #Après la nuit, le jour se lève.

  7. #7
    Membre éclairé
    Homme Profil pro
    Développeur backend junior - Symfony
    Inscrit en
    janvier 2018
    Messages
    325
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Aisne (Picardie)

    Informations professionnelles :
    Activité : Développeur backend junior - Symfony
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2018
    Messages : 325
    Points : 778
    Points
    778
    Par défaut
    Citation Envoyé par Runhide Voir le message
    #Après la nuit, le jour se lève.
    Tout dépend le lieu et la saison : dans certaines zones du monde, on a quand même plusieurs mois de nuit continue

  8. #8
    Membre averti
    Profil pro
    Inscrit en
    juin 2006
    Messages
    150
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 150
    Points : 395
    Points
    395
    Par défaut
    Citation Envoyé par Cincinnatus Voir le message
    En clair, un taux de pénétration ne peut dépasser 100%. Ce ne serait pas une évidence ?
    Tout dépend de ce que tu comprend par «taux de pénétration», regarde le nombre de SIM/Smartphone par rapport a la population, on est largement au dessus de 100%

  9. #9
    Nouveau membre du Club Avatar de Runhide
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2017
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2017
    Messages : 35
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par Mimoza Voir le message
    Tout dépend de ce que tu comprend par «taux de pénétration», regarde le nombre de SIM/Smartphone par rapport a la population, on est largement au dessus de 100%
    Dans ce cas on par sur le postulat X(personnes) * N(carte sim). Ou X est la population et N se situant entre 0 et 4 sims (plus de 4 portables pour une personne est très rare).

    À quelques chose près on est sur le même rapport.

  10. #10
    Membre expérimenté Avatar de Uranne-jimmy
    Homme Profil pro
    Bioinformatique
    Inscrit en
    décembre 2012
    Messages
    778
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Bioinformatique
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : décembre 2012
    Messages : 778
    Points : 1 459
    Points
    1 459
    Par défaut
    Il ne faut pas confondre taux de pénétration et proportion de la population équipé.
    Imaginez le taux de pénétration comme une accélération, multiplier par deux son accélération ne veut rien dire par rapport à la vitesse.
    Pour le dire autrement, le taux de pénétration est l'augmentation de la proportion de la population équipé en fonction du temps.
    Expert en recherche google caféinomane

  11. #11
    Nouveau membre du Club Avatar de Runhide
    Homme Profil pro
    Étudiant
    Inscrit en
    mai 2017
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2017
    Messages : 35
    Points : 29
    Points
    29
    Par défaut
    Citation Envoyé par Uranne-jimmy Voir le message
    Il ne faut pas confondre taux de pénétration et proportion de la population équipé.
    Imaginez le taux de pénétration comme une accélération, multiplier par deux son accélération ne veut rien dire par rapport à la vitesse.
    Pour le dire autrement, le taux de pénétration est l'augmentation de la proportion de la population équipé en fonction du temps.
    Sujet intéressant, je cite wikipédia :

    pénétration du marché.

    Il s'exprime en pourcentage et s'obtient par le rapport suivant :

    Demande actuelle du produit / Demande potentielle du produit.
    Il peut être calculé pour l'ensemble des entreprises fournissant un type de produit (exemples : pourcentage des ménages équipés d'un PC, d'un compte en banque, etc.), ou pour chacune d'entre elles. Dans ce dernier cas, le total des taux de pénétration du marché peut être supérieur à 100 % puisqu'un individu donné peut posséder des produits ou services similaires venant de divers fournisseurs.

  12. #12
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    7 703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 7 703
    Points : 13 288
    Points
    13 288
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message
    « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. »
    C'est une des raisons qui fait que c'est hyper compliqué de réaliser un cahier des charges (et en plus il y a des dates de livraison avec des fonctionnalités qui doivent être implémentées).

    J'aime pas le concept de "cahier des charges", c'est une chose importante pour que le client soit assuré d'avoir un produit qui répond à une liste d'exigences, mais à part ça c'est chiant. Le client a mal exprimé son besoin, les développeurs ont mal compris l'expression de ces besoins, les besoins changent pendant le développement.
    Il faudrait une méthode plus agile où régulièrement on montre les progrès au client pour qu'il puisse ré-orienter le besoin (le client peut dire "j'avais demandé ça, mais en fait j'en ai pas besoin, par contre je n'ai pas demandé ça et j'en ai besoin maintenant").

    C'est impossible d'établir un cahier des charges parfait, comment tu peux savoir exactement ce dont le client aura besoin dans 2, 3 ans ?
    Et c'est chaud de dire dans 6 mois on livre une Beta 0.014 qui implémentera Fonction Principale 1, Fonction Principale 2, Fonction Secondaire 1, etc.
    Keith Flint 1969 - 2019

  13. #13
    Membre éprouvé Avatar de Charvalos
    Homme Profil pro
    Développeur Web
    Inscrit en
    juin 2010
    Messages
    349
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : juin 2010
    Messages : 349
    Points : 1 216
    Points
    1 216
    Par défaut
    Citation Envoyé par Ryu2000 Voir le message
    Il faudrait une méthode plus agile où régulièrement on montre les progrès au client pour qu'il puisse ré-orienter le besoin (le client peut dire "j'avais demandé ça, mais en fait j'en ai pas besoin, par contre je n'ai pas demandé ça et j'en ai besoin maintenant").
    Et comme ça, au bout de 10 ans de développement, l'application ne sera toujours pas terminé parce que le client change d'avis comme il change de chemise...
    "Non, je ne dois rien à personne
    Et je ne méprise personne".


    Je ne réponds pas aux message techniques par MP !

  14. #14
    Nouveau Candidat au Club
    Homme Profil pro
    Étudiant
    Inscrit en
    août 2011
    Messages
    0
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : août 2011
    Messages : 0
    Points : 0
    Points
    0
    Par défaut 90-90
    Une petite coquille s'est glissée dans le principe des 90-90 :

    Le développement des premiers 90 % du code représentent 10 % du temps de développement. Les 10 % restants prennent 90 % du temps de développement.

    +1 pour le principe d'optimisation de Knuth

  15. #15
    Membre émérite
    Inscrit en
    juin 2009
    Messages
    910
    Détails du profil
    Informations forums :
    Inscription : juin 2009
    Messages : 910
    Points : 2 736
    Points
    2 736
    Par défaut
    Citation Envoyé par Michael Guilloux Voir le message

    Le principe d'optimisation de Knuth

    Le principe formulé par Donald Knuth stipule que « l'optimisation prématurée est la source de tous les maux. » Ce principe est considéré comme la règle numéro un de l'optimisation : l'optimisation ne doit intervenir qu'une fois que le programme fonctionne et répond aux spécifications fonctionnelles. L'expérience montre qu'appliquer des optimisations de bas niveau du code avant que ces deux conditions ne soient réalisées revient le plus souvent à une perte de temps et s'avère néfaste à la clarté du code et au bon fonctionnement du programme. Cependant cette citation, tronquée, est très souvent mal interprétée. On propose donc une version complète du principe d'optimisation de Knuth : « On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux. »
    J'ai un prof d'algo qui se basait énormément sur les travaix de knuth, et qui résumait sa pensée ainsi :
    1. Make it work
    2. Make it well
    3. Make it fast.


    En clair, l'objectif premier d'un programme est de fonctionner, sinon il n'a pas raison d'être.
    Ensuite, il faut qu'il soit maintenable, sinon il n'a pas de raison de subsister
    Enfin il peut être rapide. Mais s'il ne fonctionne pas, ou alors qu'il est déjà peu maintenable, aucune chance d'aboutir à quelque chose de potable.


    ça tombe sous le sens. En pratique, avec ma petite expérience, on me laisse rarement le temps de bien finir l'étape "Make it well"...

  16. #16
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    7 703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 7 703
    Points : 13 288
    Points
    13 288
    Par défaut
    Citation Envoyé par Charvalos Voir le message
    Et comme ça, au bout de 10 ans de développement, l'application ne sera toujours pas terminé parce que le client change d'avis comme il change de chemise...
    Ouais mais le client peut utiliser l'application pendant ce temps là.
    Parce que si tu dis "dans 2 ans je te livre exactement ce qu'il y a dans le cahier des charges" quand tu vas le livrer il va dire "putain mais c'était de la merde ce cahier des charges pourquoi j'ai signé ça à l'époque ?" et le logiciel ne sera pas utilisé.
    Keith Flint 1969 - 2019

  17. #17
    Expert confirmé
    Homme Profil pro
    Responsable des études
    Inscrit en
    juillet 2014
    Messages
    2 423
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Aude (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Responsable des études
    Secteur : Santé

    Informations forums :
    Inscription : juillet 2014
    Messages : 2 423
    Points : 5 240
    Points
    5 240
    Par défaut
    Citation Envoyé par said026 Voir le message
    Une petite coquille s'est glissée dans le principe des 90-90 :

    Le développement des premiers 90 % du code représentent 10 % du temps de développement. Les 10 % restants prennent 90 % du temps de développement.
    Non. C'est voulu cf la phrase suivante:
    Cela fait donc 180 % du temps de développement
    J'aimerais bien aller vivre en Théorie, car en Théorie tout se passe bien.

  18. #18
    Membre éprouvé Avatar de Alvaten
    Homme Profil pro
    Développeur Java / Grails
    Inscrit en
    novembre 2006
    Messages
    324
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 31
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Java / Grails
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : novembre 2006
    Messages : 324
    Points : 1 016
    Points
    1 016
    Par défaut
    J'aime beaucoup le "Principe de Peter", et même si elle est exagérée c'est quand même assez vrai. Ca me parait logique que si on te promue pour te récompenser car tu fait du bon boulot à un poste, tu va devoirs repartir à zéro au nouveau poste et donc y être moins compétant, au moins au début, et ca peut même durer à long terme.
    J'ai connu des gens super à un poste qu'on a promu pour qu'au final il se rendent compte que le poste ne leur convenait pas du tout. Difficile dans ce cas de faire du super boulot.

    edit : oui merci

  19. #19
    Membre extrêmement actif
    Avatar de Ryu2000
    Homme Profil pro
    Étudiant
    Inscrit en
    décembre 2008
    Messages
    7 703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : décembre 2008
    Messages : 7 703
    Points : 13 288
    Points
    13 288
    Par défaut
    Citation Envoyé par Alvaten Voir le message
    J'aime beaucoup la "loi de Brooks"
    Là tu parles du Principe de Peter.
    Au lieu de changer de poste on devrait juste augmenter les salaires...
    Mais après je pense que c'est parfois jouable qu'un développeur devienne chef de projet (selon ce qu'on entend par "chef de projet").
    Selon la méthode, le chef de projet est un des développeurs de l'équipe qui a des responsabilités en plus.

    Parfois il y a des chefs de projets qui n'ont jamais été développeur, c'est un peu dommage.
    Keith Flint 1969 - 2019

  20. #20
    Expert éminent
    Avatar de transgohan
    Homme Profil pro
    Développeur Temps réel Embarqué
    Inscrit en
    janvier 2011
    Messages
    3 147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Maine et Loire (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur Temps réel Embarqué

    Informations forums :
    Inscription : janvier 2011
    Messages : 3 147
    Points : 9 338
    Points
    9 338
    Par défaut
    Pas mal de lois que je ne connaissais pas mais dont je me rend compte qu'elles s'appliquent à mes projets et à mon entreprise.
    C'est très intéressant comme Trolldi.

    Citation Envoyé par AoCannaille Voir le message
    J'ai un prof d'algo qui se basait énormément sur les travaix de knuth, et qui résumait sa pensée ainsi :
    1. Make it work
    2. Make it well
    3. Make it fast.
    [...]
    ça tombe sous le sens. En pratique, avec ma petite expérience, on me laisse rarement le temps de bien finir l'étape "Make it well"...
    Dans l'embarqué c'est plutôt :
    1. Make it work
    2. Make it fast
    3. Make it well (qu'on a jamais le temps)


    Voir j'ai même eu des chefs qui disaient que la vitesse d'exécution était plus important que le fait que cela fonctionne...
    J'aimerai pas être le client.

    « Toujours se souvenir que la majorité des ennuis viennent de l'espace occupé entre la chaise et l'écran de l'ordinateur. »
    « Le watchdog aboie, les tests passent »

Discussions similaires

  1. QUID de Delphi Perso pour les Associations Loi 1901 ?
    Par DarkChamallo dans le forum Delphi
    Réponses: 3
    Dernier message: 02/02/2007, 11h58

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