Pour comparer : le cp de GNU coreutils (et tous les cp proprios qui ont précédés) développé sur des dizaines d'années permet la célébre méthode du cpOld à laquelle tout le monde pense en 10 min.
Blague à part, git continue d'évoluer (depuis 20 ans), comme le noyau Linux. Plus de fonctionnalités, amélioration de la CLI, perfs, etc.
Et pourquoi pas 10j pour avoir les fonctionnalités principales, mais 10 mois voire bien plus pour avoir tous les fonctionnalités (règle des 80/20 ?).
Une règle au doigt mouillé c'est que dans beaucoup de projets informatiques, il faut 10 jours pour avoir une version qui fait juste le cœur du concept de la façon la plus brute qui soit (en mode « preuve de concept »), dix semaines pour une version utilisable en pratique, dix mois pour une version agréable à utiliser (sans gros contournements ni grosse fonction marquante) et dix ans pour un produit peaufiné aux petits ognons (ou obsolète s'il n'a pas été suivi).
J'adore.
Une version encore plus pessimiste que la regle de Brooks :
A programming systems product takes about nine times as much effort as the component programs written separately for private use. I estimate that productizing imposes a factor of three; and that designing, integrating, and testing components into a coherent system imposes a factor of three; and that these cost components are essentially independent of each other.
# Qui veut voir mon mythe?
Posté par devnewton 🍺 (site web personnel) . Évalué à 10 (+17/-0).
10 jours pour l'écriture du code… mais après 10 ans de réflexion sur la gestion de version.
Une leçon à retenir pour ceux qui pensent que les devs ne font que pisser de la ligne de code.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Qui veut voir mon mythe?
Posté par Benoît Sibaud (site web personnel) . Évalué à 9 (+6/-0).
Pour comparer : le cp de GNU coreutils (et tous les cp proprios qui ont précédés) développé sur des dizaines d'années permet la célébre méthode du cpOld à laquelle tout le monde pense en 10 min.
Blague à part, git continue d'évoluer (depuis 20 ans), comme le noyau Linux. Plus de fonctionnalités, amélioration de la CLI, perfs, etc.
Et pourquoi pas 10j pour avoir les fonctionnalités principales, mais 10 mois voire bien plus pour avoir tous les fonctionnalités (règle des 80/20 ?).
[^] # Re: Qui veut voir mon mythe?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 8 (+6/-0).
Une règle au doigt mouillé c'est que dans beaucoup de projets informatiques, il faut 10 jours pour avoir une version qui fait juste le cœur du concept de la façon la plus brute qui soit (en mode « preuve de concept »), dix semaines pour une version utilisable en pratique, dix mois pour une version agréable à utiliser (sans gros contournements ni grosse fonction marquante) et dix ans pour un produit peaufiné aux petits ognons (ou obsolète s'il n'a pas été suivi).
La connaissance libre : https://zestedesavoir.com
[^] # Re: Qui veut voir mon mythe?
Posté par Thomas (site web personnel) . Évalué à 2 (+1/-0).
J'adore.
Une version encore plus pessimiste que la regle de Brooks :
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.