Discussion :

[10_GOTO_10]

La loi de Hofstadter

Mes chefs ont trouvé la parade depuis longtemps : il demandent au métier la date de dead-line. Ensuite, il faut deux mois de tests fonctionnels ? ils enlèvent deux mois. Il faut un mois de tests unitaires ? ils enlèvent un mois. Deux mois de débuggage et de mise au point ? Ils enlèvent encore deux mois. Ce qui reste, c'est pour le développement. Le développeur, c'est moi.

[Alvaten]

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.

C'est sur que parfois ca peut très bien se passer. Le problème pour moi c'est qu'il y a une certaine pression social, on entend trop souvent "quoi à 35ans tu est encore dev, tu devrai être chef d'équipe au minium ?". Pour moi il n'y a pas de honte a dire qu'on est bien là ou on est.

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

Ah ca c'est un autre problème aussi très vrai, et pas que dans l'informatique ! De mon expérience c'est jamais très bon d'avoir un chef qui commande un truc dont il ne comprend pas le fonctionnement.

[Ryu2000]

De mon expérience c'est jamais très bon d'avoir un chef qui commande un truc dont il ne comprend pas le fonctionnement.

Le pire ça restera les commerciaux, ils n'y connaissent rien et font des promesses au client...
Qu'est-ce qu'il y connait aux femmes Rick Hunter ?
Qu'est-ce qu'il y connait au métier le commercial ?

[Charvalos]

Sinon, il y en a quelques-une que j'adore et qui ne sont pas citées :

Never attribute to malice what can be adequately explained by stupidity.

Any code of your own that you haven't looked at for six or more months might as well have been written by someone else.

[Steinvikel]

Celle qui est la plus déprimante au travail, et qui n'est pas dans le sondage... c'est la loi du plus fort !

[CaptainDangeax]

La loi de Wirth est trop vraie.
Un C64 mettait moins de 2 secondes entre l'appui sur le bouton power et la disponibilité du système près à recevoir des commandes au clavier. Aucune machine actuelle ne fait ça, quel que soit le noyau ou le shell.
Mon 486 avec une contrôlleur VLB + mémoire cache mettait moins de temps à démarrer Win3.1 qu'un bousin d'aujourd'hui à charger windows 10. Attention, par charger, je veux dire sans tâche de fond qui continue à mouliner le SSD ou le disque dur après l'affichage du shell.
Toutes les autres lois sont valides, à l'exception de la loi de Moore qui se heurte à la taille minimale (quantique) du transistor.

[melka one]

Runhide

est tu conscient que ton avatar est sujet a controverse.

[Steinvikel]

C'est pas une croix maltaise, ou de templier stylisé en noir ?
Qu'a-t-elle donc de dérangeant ?

[Alvaten]

C'est pas une croix maltaise, ou de templier stylisé en noir ?
Qu'a-t-elle donc de dérangeant ?

Non la Croix de Malte est un peu différente (https://fr.wikipedia.org/wiki/Croix_de_Malte_(symbole))

Ici on est clairement par la forme et la couleur une Croix de Fer, la décoration allemande. J'imagine que le coté dérangeant vient du fait qu'on l'associe forcément aux nazies, même si elle existe en réalité depuis le 19ème. Après je vois ca plus comme de la provocation, même si personnellement ca me viendrai pas à l'idée de l'utiliser on la vois souvent chez les bikers ou les métaleux sans aucun rapport avec le III Reich.

Bon merci pour l'application d'une nouvelle loi "Plus une discussion en ligne dure longtemps, plus la probabilité d'y trouver une comparaison impliquant les nazis ou Adolf Hitler s’approche de 1" (Loi de Godwin) ca me permet de pas être trop hors-sujet

[jvallois]

Tout dépend le lieu et la saison : dans certaines zones du monde, on a quand même plusieurs mois de nuit continue

Même si la nuit dure plusieurs mois, lorsqu'elle sera finie, le jour se lèvera...

[jvallois]

Non la Croix de Malte est un peu différente (https://fr.wikipedia.org/wiki/Croix_de_Malte_(symbole))

Ici on est clairement par la forme et la couleur une Croix de Fer, la décoration allemande. J'imagine que le coté dérangeant vient du fait qu'on l'associe forcément aux nazies, même si elle existe en réalité depuis le 19ème. Après je vois ca plus comme de la provocation, même si personnellement ca me viendrai pas à l'idée de l'utiliser on la vois souvent chez les bikers ou les métaleux sans aucun rapport avec le III Reich.

Apparemment, cette croix est toujours utilisée par la bundeswher qui, me semble-t-il, n'a plus rien à voir avec les nazis !

[Ryu2000]

Bon c'est HS, mais moi ça me fait penser au logo d'Independent la marque de truck de skate :

Mais ouais c'est inspiré de la crois de fer (La croix de fer (Eisernes Kreuz) est une décoration militaire allemande qui fut établie comme un honneur militaire par le roi Frédéric-Guillaume III de Prusse en 1813 lors des guerres napoléoniennes.)

Il faut se calmer avec les symboles, par exemple depuis 1945 la svastika est ruiné alors que c'est un symbole qu'on retrouve partout et qui n'avait pas de connotation négative avant... Ça fait chier que l'intégralité des svastikas souffrent de ça, alors que les croix gammées ne représentent même pas 0,0001% des svastikas). J’espère que ce symbole sera réhabilité avec le temps, parce que ça fait chier cette histoire.

Non. C'est voulu cf la phrase suivante:

Cela fait donc 180 % du temps de développement

Je suis d'accord avec said026, je préfère dire que les 10% restants prennent 90% du temps de développement.
L'histoire des 180% c'est redondant avec la loi de Hofstadter.

Les fins de projets c'est compliqué... Ça avance moins vite. (90% c'est un peu exagéré quand même, mais c'est vrai qu'il y a un gros ralentissement vers la fin)

[Steinvikel]

Même si la nuit dure plusieurs mois, lorsqu'elle sera finie, le jour se lèvera...

Sauf si un astéroïde éradique le coin, qu'une proto-planète arrive, que la terre quitte son orbite... il y a toujours l’exception qui confirme la règle en français.

[Aspartame]

le plus souvent - trop souvent - , ce que je constate c'est l'application de la loi de la gravitation :

tout élément incompétent parachuté dans un projet finit par s'écraser .

[foetus]

Je suis d'accord avec said026, je préfère dire que les 10% restants prennent 90% du temps de développement.
L'histoire des 180% c'est redondant avec la loi de Hofstadter.

Et pourtant c'est bien la loi qui s'appelle Ninety-ninety rule en anglais (<- lien wiki en anglais) dite/ énoncée par Tom Cargill (Bell Labs)

Et si cela fait 180% c'est parce que c'est un aphorisme (je te laisse chercher) avec une signification "qu'il faut toujours plus de code et de temps qu'escompté pour finir un projet"

[Mat.M]

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 ?

ce n'est pas vraiment une loi mais plutôt un paradoxe mis en évidence par l'économiste américain Robert Solow

On peut voir les ordinateurs partout sauf dans les statistiques de productivité

[mister3957]

Y'a pas une loi qui dit que les besoins évoluent toujours mais on ne sait pas comment / dans quel sens à l'avance ? Et qu'au fur et à mesure des livrables les idées se posent plus clairement, les stupidités se voient, donc s’interprètent et cadrent mieux le projet et que c'est pas grave de jeter des trucs à la poubelle tant qu'on en retient l'intellectuel ?

Ça ferait du bien de pouvoir prouver qu'il est totalement inutile de passer des mois et des mois à faire des réunions pour pondre un cahier des charges de 600 pages sensé exprimer les besoins de production des 3 prochaines années pour assurer le business des 15 prochaines années.

Des boucliers se lèveraient, et c'est normal. Je pense à ces rédacteurs, relecteurs, valideurs. Tous ces chefs toujours plus intelligents que leur voisin ça risque de leur piquer les fesses le jour où on pourra prouver qu'ils ne servent à rien voire passent leur temps à parasiter.

[stephanerain]

Pour la Loi de Wirth je l'aurai pas formulée comme ca. C'est plutot un ensemble de truc qui débouchent là dessus.
+Vieux soft codé y'a des lustres sur une techno dépassée mais qu'on ne veut jamais mettre à jour parce que pas le temps/envie/argent.
+ les délais de plus en plus court de dev
+ on s'en fout d'optimiser, avec les pc actuels y'a plus a s'embéter avec les delete ou la gestion de la mémoire. La mémoire vive est infinie (entendue deja de la bouche d'un cp )
+ pleins d'autres joyeusetés

Après des lois on peut en rajouter plein.

Plus y'a de gens sur un projet, et moins il avancera, parce que c'est un probleme de comm comme evoqué dans une des lois citées, mais parce que forcément les gens vont intervenir sur les mêmes sources, et qu'on va perdre un temps de dingue parce que certains auront codés la même fonction mais differrement, ou que le gestionnaire de source aura mergé comme un porc .....

Mais ma préférée ca reste : "on ne change pas un code qui marche". Si ca marche il ne faut surtout pas chercher de faire mieux, c'est toujours une perte de temps, une cause de bug, et au final si on y arrive, le gain est pas toujours evident

[Pyramidev]

Mais ma préférée ca reste : "on ne change pas un code qui marche". Si ca marche il ne faut surtout pas chercher de faire mieux, c'est toujours une perte de temps, une cause de bug, et au final si on y arrive, le gain est pas toujours evident

Il peut y avoir plusieurs bonnes raisons de modifier un code qui marche.

Par exemple, quand on doit développer une nouvelle fonctionnalité qui ressemble à une fonctionnalité déjà existante, mais que le code de la fonctionnalité déjà existante n'est pas réutilisable, alors modifier le code de la fonctionnalité existante puis le réutiliser pour la nouvelle fonctionnalité est souvent ce qu'il faut faire.

Ou alors, quand on se demande comment marche une fonctionnalité existante, quand on plonge dans le code qui sert de doc et quand on tombe sur un code difficile à lire (fonctions de plusieurs centaines de lignes, noms de variables et de fonctions qui ne correspondent pas à ce qu'elles représentent, etc.), alors améliorer le code existant permettra aux prochains lecteurs de perdre moins de temps à déchiffrer le code.

Le fait que changer un code existant soit une si grande source de bogues est surtout un signe qu'il n'y a pas assez de tests unitaires.

[pierre.E]

en gros des fois je m attelle à une réalisation que je juge très difficile et oh miracle ca marche du 1er coup
inversement un truc que je juge hyper simple faisable en 10 minutes et oh desespoir j y passe une semaine