Je pense plutôt que c'est une nouvelle démonstration (si tant est qu'il en fallait encore une) de la supériorité du modèle LL de développement.
Maintenant à la retraite, j'ai passé, simultanément, moitié de ma vie professionelle dans l'industrie et moitié comme enseignant en école d'ingénieurs. Les quelques petites (très petites) réflexions qui suivent me sont venues de cette expérience, je n'ai pas prétention à généraliser.
Dans une entreprise dite "normale", réagir à un problème implique que le niveau compétent pour prendre une décision soit conscient du problème, cela peut prendre pas mal de temps. Ensuite il faut au strict minimum plusieurs séances pour en discuter. De nouveau plusieurs séances pour tenter de trouver une solution. Après quelques semaines (mois, années), une ou plusieurs solutions ayant été déterminées, il faut la/les soumettre à l'échelon supérieur, qui lui-même va le soumettre à l'échelon supérieur (non, ce n'est pas obligatoirement récursif !). Une fois cette cascade ascendante épuisée, une nouvelle cascade se déclenche, descendante celle-là, pour la mise en oeuvre de la solution. Etc. Etc.
Dans l'enseignement, c'est encore pire. Je crois que chaque enseignant connaît les interminables séances de discussions, la plupart du temps parfaitement stériles, sauf, peut-être, que l'on enrichi son vocabulaire avec des mots à la mode.
Il me semble, il m'apparaît que le LL échappe à cette infernale spirale. Composé de développeurs co-décidants, capable de dialoguer rapidement d'un bout du monde à l'autre (au fait, un globe a-t-il un bout ?), le LL est extrèmement réactif.
Sur un plan plus théorique, il y a longtemps que l'on sait que, pour les grand systèmes, les ensembles de systèmes simples interagissants sont beaucoup plus efficaces que les systèmes complexes (ici, toute référence à une architecture de noyau compact ne serait pas obligatoirement une coincidence).
[^] # Re: Rapidité étonnante
Posté par abgech . En réponse à la dépêche Linus développe un remplaçant original à BitKeeper. Évalué à 10.
Je pense plutôt que c'est une nouvelle démonstration (si tant est qu'il en fallait encore une) de la supériorité du modèle LL de développement.
Maintenant à la retraite, j'ai passé, simultanément, moitié de ma vie professionelle dans l'industrie et moitié comme enseignant en école d'ingénieurs. Les quelques petites (très petites) réflexions qui suivent me sont venues de cette expérience, je n'ai pas prétention à généraliser.
Dans une entreprise dite "normale", réagir à un problème implique que le niveau compétent pour prendre une décision soit conscient du problème, cela peut prendre pas mal de temps. Ensuite il faut au strict minimum plusieurs séances pour en discuter. De nouveau plusieurs séances pour tenter de trouver une solution. Après quelques semaines (mois, années), une ou plusieurs solutions ayant été déterminées, il faut la/les soumettre à l'échelon supérieur, qui lui-même va le soumettre à l'échelon supérieur (non, ce n'est pas obligatoirement récursif !). Une fois cette cascade ascendante épuisée, une nouvelle cascade se déclenche, descendante celle-là, pour la mise en oeuvre de la solution. Etc. Etc.
Dans l'enseignement, c'est encore pire. Je crois que chaque enseignant connaît les interminables séances de discussions, la plupart du temps parfaitement stériles, sauf, peut-être, que l'on enrichi son vocabulaire avec des mots à la mode.
Il me semble, il m'apparaît que le LL échappe à cette infernale spirale. Composé de développeurs co-décidants, capable de dialoguer rapidement d'un bout du monde à l'autre (au fait, un globe a-t-il un bout ?), le LL est extrèmement réactif.
Sur un plan plus théorique, il y a longtemps que l'on sait que, pour les grand systèmes, les ensembles de systèmes simples interagissants sont beaucoup plus efficaces que les systèmes complexes (ici, toute référence à une architecture de noyau compact ne serait pas obligatoirement une coincidence).
Bonne journée à tous.