【Pourquoi la technologie de certaines grandes entreprises est-elle aussi à la ramasse ?】
A : Cette ancienne version de la bibliothèque open source A a un problème de plantage.
B : Passe à la nouvelle version de A.
A : Je suis passé à la nouvelle version de A, mais elle ne compile pas avec l’ancienne version de GCC.
B : Passe à la nouvelle version de GCC.
A : Je suis passé à la nouvelle version de GCC, mais elle est incompatible avec la bibliothèque open source B.
B : Passe à la nouvelle version de B.
A : Je suis passé à la nouvelle version de B, et les performances ont baissé.
B : Active le multithreading.
A : Le multithreading a provoqué des variations de latence et des problèmes de synchronisation.
B : Passe au nouvel algorithme de correction de la latence.
A : Depuis que je suis passé au nouvel algorithme de correction de la latence, ça plante de temps en temps.
B : Sinon…
On ferait peut-être mieux de voir si on peut corriger les plantages de l’ancienne version de cette bibliothèque open source A.
Aujourd’hui, dans les entreprises informatiques qui ont atteint une certaine taille, leurs projets logiciels sont devenus bien trop vastes et complexes pour les capacités des ingénieurs. Ils ne peuvent que les réparer avec d’infinies précautions. Parfois, une grosse modification locale déclenche une réaction en chaîne. Les risques et le coût des changements importants sont difficiles à maîtriser ; sans bénéfices considérables, personne n’ose modifier quoi que ce soit à la légère. Les anciens employés voient encore plus clairement les problèmes que vous, et savent même parfois comment les résoudre. Mais s’ils ne passent pas à l’action, c’est parce qu’ils ne savent pas qui devra porter le chapeau en cas de pépin. En matière de technologie, qui peut garantir qu’il n’y aura aucun problème à 100 % ?
Alors, les projets technologiques des grandes entreprises sont-ils condamnés ?
Pas forcément. Il faut parfois attendre le bon moment. Voici quelques occasions typiques :
1. Une révolution des plateformes technologiques de base. Par exemple, l’essor de l’Internet mobile a entraîné le passage du PC au téléphone. On a alors pu abandonner beaucoup d’anciens codes et repartir de zéro sur mobile.
2. Un concurrent libère soudain tout son potentiel et développe une technologie qui lui donne un avantage concurrentiel. On est alors forcé de le rattraper ; on peut traiter un cas désespéré comme s’il avait encore une chance, et tolérer n’importe quel problème causé par les modifications.
3. De grands bouleversements dans le personnel : la direction comme les équipes de terrain sont entièrement renouvelées. Plus personne n’est capable de maintenir l’ancien code, et il faut bien repartir de zéro.
A : Cette ancienne version de la bibliothèque open source A a un problème de plantage.
B : Passe à la nouvelle version de A.
A : Je suis passé à la nouvelle version de A, mais elle ne compile pas avec l’ancienne version de GCC.
B : Passe à la nouvelle version de GCC.
A : Je suis passé à la nouvelle version de GCC, mais elle est incompatible avec la bibliothèque open source B.
B : Passe à la nouvelle version de B.
A : Je suis passé à la nouvelle version de B, et les performances ont baissé.
B : Active le multithreading.
A : Le multithreading a provoqué des variations de latence et des problèmes de synchronisation.
B : Passe au nouvel algorithme de correction de la latence.
A : Depuis que je suis passé au nouvel algorithme de correction de la latence, ça plante de temps en temps.
B : Sinon…
On ferait peut-être mieux de voir si on peut corriger les plantages de l’ancienne version de cette bibliothèque open source A.
Aujourd’hui, dans les entreprises informatiques qui ont atteint une certaine taille, leurs projets logiciels sont devenus bien trop vastes et complexes pour les capacités des ingénieurs. Ils ne peuvent que les réparer avec d’infinies précautions. Parfois, une grosse modification locale déclenche une réaction en chaîne. Les risques et le coût des changements importants sont difficiles à maîtriser ; sans bénéfices considérables, personne n’ose modifier quoi que ce soit à la légère. Les anciens employés voient encore plus clairement les problèmes que vous, et savent même parfois comment les résoudre. Mais s’ils ne passent pas à l’action, c’est parce qu’ils ne savent pas qui devra porter le chapeau en cas de pépin. En matière de technologie, qui peut garantir qu’il n’y aura aucun problème à 100 % ?
Alors, les projets technologiques des grandes entreprises sont-ils condamnés ?
Pas forcément. Il faut parfois attendre le bon moment. Voici quelques occasions typiques :
1. Une révolution des plateformes technologiques de base. Par exemple, l’essor de l’Internet mobile a entraîné le passage du PC au téléphone. On a alors pu abandonner beaucoup d’anciens codes et repartir de zéro sur mobile.
2. Un concurrent libère soudain tout son potentiel et développe une technologie qui lui donne un avantage concurrentiel. On est alors forcé de le rattraper ; on peut traiter un cas désespéré comme s’il avait encore une chance, et tolérer n’importe quel problème causé par les modifications.
3. De grands bouleversements dans le personnel : la direction comme les équipes de terrain sont entièrement renouvelées. Plus personne n’est capable de maintenir l’ancien code, et il faut bien repartir de zéro.