La bonne façon d'adopter la nouvelle technologie

Pourquoi même les ingénieurs en logiciel expérimentés sont-ils attirés par les nouvelles technologies brillantes comme les mites à une flamme? Un récit personnel de l’apprentissage à la dure: vous devez trouver un équilibre entre votre curiosité et les objectifs de votre entreprise.

En 2015, je dirigeais une équipe d’ingénieurs qui créaient une application Web pour les étudiants. Comme les accords avec de nouvelles écoles ont été conclus en mai, nous avons eu trois mois pour nous préparer à la montée du trafic chaque août.

Nous n'avions que quelques milliers d'utilisateurs au cours de notre première année, donc personne ne se souciait de la mise à l'échelle. Nous avons construit l'application en PHP avec une interface Angular et une base de données MySQL.

Notre architecture d'application à la fin de l'année 1

Alors que nous nous préparions à tripler notre base d'utilisateurs au cours de l'année 2, nous avons commencé à nous demander comment bien notre application évoluerait. J'ai commencé à découvrir tous les derniers outils, j'ai embauché un ingénieur DevOps expérimenté et nous avons mis en place un plan de test de charge.

Après deux mois et demi de déconner avec Docker, Azure Service Mesh et une poignée d'outils de pointe , nous avons réalisé que nous n'allions pas atteindre notre échéance d'août. Nous avons reculé et réfléchi à nouveau au problème. J'ai commencé à demander conseil à certains de mes mentors et je me souviens d'un moment où l'un d'eux m'a appelé:

«Vous n'avez pas besoin de tout cet outillage compliqué!» il m'a dit. «Il suffit de lancer un autre serveur dessus.»

Pourquoi les nouvelles technologies sont-elles si attrayantes?

Comme beaucoup d’ingénieurs, j’ai sauté sur l’opportunité de profiter de tous les nouveaux outils les plus intéressants. Après des mois d'efforts inutiles, j'ai finalement réalisé que la solution était simple et que nous avions déjà les outils dont nous avions besoin. Nous avons étendu nos API horizontalement et verticalement notre base de données, ce qui a pris environ deux semaines.

Notre architecture d'application au début de l'année 2

C'était évidemment le bon choix avec le recul, mais pourquoi n'était-ce pas? t-il évident au début? Pourquoi même les ingénieurs en logiciel expérimentés sont-ils attirés par les nouvelles technologies brillantes comme les mites à une flamme?

1. La nouvelle technologie promet de résoudre d'anciens problèmes

La gestion d'un grand nombre de serveurs est difficile. Ça a toujours été dur. Cela a finalement été plus facile lorsque nous sommes passés au cloud, et maintenant Kubernetes promet de continuer à le rendre plus facile. La nouvelle technologie promet de résoudre les problèmes plus rapidement, plus efficacement ou avec plus de souplesse que tous les «vieux trucs ennuyeux». Si vous ne lisez que le matériel marketing, vous pourriez penser qu’il n’y a même pas de compromis.

2. Nous attirons l'attention sur l'utilisation des «derniers et meilleurs»

Tous les articles que j'ai lus en 2015 parlaient de la qualité de Docker. Ils ont insisté sur le fait qu'il remplacerait les VPS dans quelques années seulement. Les entreprises qui ont été les premiers à avoir adopté le programme ont reçu beaucoup de presse positive pour le faire. Je voulais aussi ce genre d'attention.

3. Les candidats à l'emploi affluent vers les nouvelles technologies

Malheureusement, le cycle de battage médiatique alimenté par Hacker News incite les ingénieurs à penser qu'ils doivent travailler avec les dernières technologies pour rester pertinents. Cela semble particulièrement vrai pour les développeurs d'entrée de gamme; Je ne peux pas vous dire combien de récents diplômés de bootcamp m'ont demandé si nous utilisons le nouveau framework X ou Y. J'en ai même essayé de me convaincre de déplacer toute notre base de données relationnelle vers une blockchain.

4. We Want to Be Cool Too

"C'est amusant de plonger et de" moderniser tout "- et vous pouvez certainement en apprendre beaucoup au cours du processus (peut-être au détriment de l'entreprise)." – David LeBlanc

Je ne me souciais pas de remplir mon CV, mais je me souviens avoir pensé: «Cela fera une belle histoire pour une conférence.» Je grince des dents à cette déclaration maintenant parce qu'essayer et échouer d'implémenter Docker à un stade précoce de démarrage en 2015 est probablement mon plus grand échec de gestion à ce jour.

The Risk in Adopting Too Early

Il y a quelques années, j'ai découvert le cycle du battage médiatique technologique :

«Le cycle du battage médiatique postule une période d'hyperbole marketing et l'adoption d'une grande nouveauté – jusqu'à ce que la réalité s'affirme et montre clairement que la nouvelle chose n'est pas aussi magique que annoncé. La «nouvelle chose» tombe alors en disgrâce et est ensuite entièrement rejetée ou languit jusqu'à ce qu'une base de connaissances suffisante pour son utilisation réussie évolue. " – Dick Dowdell

Cycle de battage médiatique de la technologie

De nombreux ingénieurs font l'erreur d'adopter la technologie à son apogée initiale – quand elle est la plus à la mode et dont on parle le plus. Le problème est que la technologie immature aura de nouveaux mécanismes de défaillance inconnus que les solutions existantes n'ont pas.

Les équipes de génie logiciel perdront beaucoup de temps à rechercher des bogues subtils, à trouver des cas de pointe non documentés et à réécrire le code pour s'adapter à la nouvelle technologie . C’est ce qui nous est arrivé lorsque nous avons essayé d’adopter Docker il y a six ans. Nous n'avions pas les ressources nécessaires pour lutter contre toutes les fonctionnalités et options non documentées, et l'API continuait de changer avec chaque version.

Même si ces problèmes ne vous dissuadent pas, les premiers utilisateurs courent le risque de fermer complètement l'entreprise . Je me souviens de plusieurs amis qui ont sauté sur RethinkDB tôt, pour être déçus quand l'entreprise derrière elle a fermé ses portes en 2016 . Bien qu'il soit revenu en tant que projet géré par la communauté, il n'est jamais bon d'avoir la base de données de votre application dans les limbes.

Conseils d'adoption de la technologie

Donc, si la nouvelle technologie ajoute tant de risques inutiles, pourquoi ne sommes-nous pas tous en train d'exécuter un Version des années 1990 de Java? Comment éviter d’être si loin derrière qu’il n’y ait pas de voie de mise à niveau? Quand nous commençons un nouveau projet, ne devrions-nous pas utiliser les derniers outils technologiques?

Comme pour tout problème intéressant, la réponse est: "Cela dépend."

J'ai commencé à développer quelques règles de base pour l'adoption nouvelle technologie dans les équipes de génie logiciel. N'hésitez pas à les apporter et à les modifier dans votre organisation ou à créer votre propre ensemble de règles.

1. Donner aux gens le temps d’expérimenter

Je suis fermement convaincu que donne aux employés le temps d’apprendre de nouvelles choses au travail . Cela leur donne un exutoire créatif, les maintient engagés et vous permet de piquer des choses qui ne seraient jamais priorisées par l'entreprise. Si un ingénieur passe son temps d'apprentissage à prouver qu'un nouvel outil technologique peut être utilisé dans notre application, je lui prêterai une grande considération.

«Une nouvelle technologie doit être validée avant d'être utilisée sur un produit… Vous devez produire des résultats. Sinon, vous placez un produit sur le chemin de la mort. » – Andrew Orsich

2. Avoir une pile technologique par défaut

L'un des crimes des microservices était qu'ils encourageaient les entreprises à créer différentes parties de leur application dans différents langages de programmation . Alors que les ingénieurs expérimentés peuvent aimer changer de langue chaque semaine, cela ajoute une surcharge cognitive et rend plus difficile l'intégration de nouveaux développeurs. Vous verrez également apparaître des silos en fonction des programmeurs qui souhaitent travailler dans quelles langues. Choisissez une pile technologique par défaut et ne vous élargissez que lorsque vous vraiment en avez besoin.

3. Gardez votre noyau fiable

Lorsque vous choisissez d'expérimenter de nouvelles technologies, pensez d'abord à limiter vos paris à des fonctionnalités moins critiques. Il est difficile d’adopter une nouvelle base de données de pointe lorsque vous créez une plate-forme basée sur SQL, mais il n’est pas si difficile d’essayer une nouvelle bibliothèque d’interfaces utilisateur sur un site marketing temporaire. Une fois que vous avez fait la démonstration de la nouvelle technologie dans des rôles moins critiques, vous pouvez décider de l’adopter dans votre application principale.

Niveau de risque lié à l'adoption de nouvelles technologies dans toute votre application

4. Souvenez-vous des objectifs commerciaux

Les meilleurs ingénieurs avec lesquels j'ai travaillé ont toujours gardé à l’esprit le «pourquoi». Ils ont réduit les délais sur les parties de l'application à faible valeur commerciale et ont passé des semaines à perfectionner les modèles de données de base. En tant que gestionnaire ou chef d'équipe, vous devez vous rappeler pourquoi l'entreprise a besoin de cette technologie. Si un nouvel outil entre sur le marché, vous devrez décider de la valeur commerciale qu’il ajoute et du coût de son adoption.

Conclusion

Les nouvelles technologies ne sont pas mauvaises. J'adore expérimenter de nouveaux frameworks et langages de programmation, mais en tant que leader, vous devez trouver un équilibre entre votre curiosité et les objectifs de votre entreprise. Il est facile de se laisser emporter par le battage médiatique entourant les nouveaux outils non éprouvés, vous devez donc élaborer des normes qui vous aideront à décider quand essayer quelque chose de nouveau. Si vous avez élaboré un ensemble de règles pour votre organisation, j'aimerais en entendre parler. Contactez Twitter pour poursuivre la conversation.