Vous n’êtes pas Google (You Are Not Google)
(blog.bradfieldcs.com)De nombreux ingénieurs logiciels ne sont pas rationnels dans leurs choix technologiques. Lorsqu’ils choisissent une nouvelle technologie, ils le font souvent sans besoin réel ni définition claire du problème, simplement parce qu’elle est utilisée par des géants de la tech comme Google ou Amazon. Par exemple, MapReduce ou Hadoop ont été créés pour le traitement de données à très grande échelle, mais des entreprises qui n’ont pas un tel volume de données les adoptent malgré tout, et se retrouvent au contraire avec des coûts d’I/O inutiles et une perte de fonctionnalités. Il s’agit simplement d’un phénomène de « culte du cargo » technologique.
L’article propose une checklist appelée UNPHAT pour éviter ce type d’imitation non critique :
Understand – Comprendre pleinement le problème.
eNumerate – Énumérer différentes options possibles.
Paper – Lire les articles ou livres blancs sur lesquels repose la technologie.
Historical context – Examiner le contexte historique de son développement.
Advantages – Comparer de façon équilibrée les avantages et les inconvénients.
Think – Réfléchir par soi-même à la réelle adéquation de cette technologie au problème.
L’article donne aussi des exemples de technologies comme Cassandra, Kafka ou SOA(Service-Oriented Architecture), adoptées sans recul dans des situations qui ne correspondent pas à leurs cas d’usage réels. Par exemple, Kafka a été conçu pour LinkedIn, qui traite des millions de messages par seconde, mais on le retrouve parfois dans de petites entreprises qui n’ont que quelques dizaines de transactions par jour.
L’auteur souligne également que même Google a cessé d’utiliser MapReduce lorsqu’il a jugé que ce n’était plus adapté. En fin de compte, l’important n’est pas la technologie elle-même, mais la compréhension précise du problème que vous cherchez à résoudre, puis le choix de la technologie qui y répond réellement.
Enfin, l’auteur mentionne que Pólya, Hamming, Rich Hickey et d’autres répètent le même message depuis longtemps, et que l’essentiel est simple :
« Réfléchissez. Et comprenez le vrai problème. »
15 commentaires
Je suis tombé dessus par hasard via les recommandations de Google, mais cet article est écrit avec un point de vue beaucoup trop geek. D’un point de vue business, ce qu’il raconte n’est pas du tout juste. Pourquoi ?
Il est facile de trouver des spécialistes des gros outils utilisés par la Big Tech.
Beaucoup de gens les apprennent pour entrer dans la Big Tech, et beaucoup se mettent à les étudier simplement parce que la Big Tech les a choisis. Il est donc naturellement facile de trouver des personnes qui s’y connaissent, ainsi que des profils expérimentés ou des experts. Mais qu’en est-il d’un outil inconnu ? Il ne s’agit pas de dire que personne ne l’a étudié en profondeur, mais il sera de toute façon bien plus difficile de trouver ce type de profil qu’un expert d’un outil de la Big Tech.
Les gros outils utilisés par la Big Tech disposent d’une documentation et de références abondantes
Pour les gros outils largement utilisés, il existe énormément de ressources pour résoudre les problèmes, ainsi que beaucoup de résultats dans Google. Dans la majorité des cas, les problèmes ont déjà été rencontrés par d’autres, et une simple recherche permet de les identifier facilement. En revanche, pour un outil peu connu, il est difficile de trouver des références, et si un problème survient, il est fort probable qu’il faille passer beaucoup de temps à en déterminer la cause. Or, tout cela a un coût. Ce problème vient-il vraiment du petit outil nouvellement introduit ? Ou bien est-ce qu’on se trompe en attribuant à cet outil un problème venant d’ailleurs ?
Au contraire, ce sont justement les grandes entreprises de la tech qui peuvent effectuer ce type de transition plus facilement. Avec des volumes de traitement de données énormes, un léger gain d’I/O peut représenter un bénéfice considérable. Et puis, il y a aussi beaucoup de gens prêts à étudier un outil simplement parce qu’il a été adopté par la Big Tech. En revanche, dans les entreprises de petite ou moyenne taille, un léger gain d’I/O n’apporte pas un avantage si important étant donné des volumes de données relativement modestes, alors que les problèmes évoqués plus haut, eux, sont très sérieux. Il y a aussi moins de gens disposés à apprendre une solution adoptée par des entreprises de taille moyenne. C’est pourquoi, pour un dirigeant de PME, il est souvent plus rentable d’imiter les outils de la Big Tech plutôt que de raisonner comme un geek sur ce genre de sujet.
En lisant l’article original, je vois qu’il a été écrit en 2017.
Huit ans ont passé depuis, et il est surprenant de constater que ce contenu reste toujours d’actualité.
Je suis largement d’accord avec ce qui est dit plus haut !
Cela dit, je pense aussi que si l’on fait de l’overengineering dans de petites entreprises, c’est parfois parce que des personnes qui visent les grandes entreprises veulent acquérir de l’expérience avec ce genre d’outils dans une petite structure.
Bien sûr, le ou la dirigeant·e n’apprécie probablement pas trop ça, haha
Est-ce que 80 % de la raison pour laquelle des petites entreprises finissent par utiliser telles quelles des solutions conçues pour répondre aux besoins des grands groupes, ce n’est pas justement ça ? C’est normalement le rôle du CTO de garder ça sous contrôle, mais il arrive que le CTO lui-même envisage de partir vers un grand groupe.
Quand on n’a pas grand-chose à faire, on finit par s’occuper avec des trucs inutiles haha.
Même les problèmes simples, on peut les compliquer pour donner l’impression qu’on a vraiment fait quelque chose. Et puis il y a aussi beaucoup de gens qui pensent que si c’est simple, c’est que ça n’avait rien de compliqué… hahahaha
On a parfois tendance à construire gros dès le départ, par peur de devoir plus tard refactorer à grande échelle quelque chose de petit...
Je pense que cela s’applique aussi à K8s. Ça me rappelle le livre « Comment coder de façon à rendre la maintenance difficile ». Haha
Au final, il faut comprendre à la fois le problème que les technologies cherchent à résoudre et le contexte dans lequel elles ont émergé. Les exemples cités dans l’article sont les suivants.
Il faut, à mon avis, bien examiner si les problèmes qu’elles cherchent à résoudre sont réellement alignés avec celui que j’essaie de résoudre.
Oh, je comprends tout à fait. Cela me rappelle que, lorsque je faisais du mentorat auprès d’étudiants ou de profils juniors, je leur conseillais souvent d’essayer de comprendre l’histoire des technologies.
On voit souvent des gens oublier que la technologie est un outil, pas un objectif.
À partir du moment où des critères comme « c’est validé par la big tech » ou « c’est beaucoup utilisé en ce moment » deviennent déterminants dans le choix d’une technologie, une hausse inutile des coûts suit naturellement.
En Corée, le cargo cult autour de Spring est très fort.
Parce qu'il est plus facile de recruter avec Spring...
En Corée, Spring relève moins du culte que...
d’un hybride entre l’incompétence du gouvernement et la flemme des développeurs..
Je suis tout à fait d’accord. Au final, Spring n’est lui aussi qu’un outil pour résoudre des problèmes.
Brainstorming, cartes mentales, recherche en deep learning, le temps de travail diminue, alerte en juillet, avec un effet à long terme.