"A life without a struggle on your part to make yourself EXCELLENT is hardly a life worth living."

Firefox avait beaucoup de fonctionnalités intéressantes. La navigation par onglets, des outils de débogage et des corrections de bugs réguliers. Chrome en avait également. Mais quand je l'ai vu démarrer presque instantanément au lieu des cinq secondes qu'il a fallu à Firefox, j'ai immédiatement basculé sur Google et je n'ai jamais regardé en arrière. Comme cela sera expliqué plus tard par les ingénieurs de Google, la vitesse était une priorité fondamentale.

Une fois que votre logiciel (ici Firefox) est lent, il est plus difficile, à postériori, de refactorer le code pour le rendre plus rapide.

Les développeurs de Firefox ont tenté de corriger le temps de démarrage de cinq secondes en 2010 via le bug #627591. Ils ont résolu de nombreux problèmes mais pas suffisamment pour justifier un deuxième essai de la part de beaucoup d'utilisateurs.

(source: There are called opportunies, de Fabien Sanglard)

A l'inverse, l'équipe derrière Google Chrome avait mis en place dès le début du projet un test automatisé dans le pipeline d'intégration continue (CI) pour s'assurer que les performances ne faiblissaient pas après chaque modification de code :

Nous surveillons attentivement les performances de démarrage à l'aide d'un test automatisé qui s'exécute pour presque chaque modification du code. Ce test a été créé très tôt dans le projet, lorsque Google Chrome n'a presque rien fait, et nous avons toujours suivi une règle très simple: ce test ne peut jamais être plus lent.

Parce qu'il est beaucoup plus facile de résoudre les problèmes de performances au fur et à mesure qu'ils sont créés que de les résoudre ultérieurement, nous sommes rapides pour corriger ou annuler les régressions. En conséquence, notre très grande application démarre aussi vite aujourd'hui que l'application très légère avec laquelle nous avons commencé.

(source: IO in Google Chrome)

La répétition fait le maitre. C'est tout aussi vrai en informatique (source de la vidéo).

Ne pas aller jusqu'au bout des choses sur un petit périmètre.

Et par là j'entends intégration continue (Continuous Integration), déploiement continu (Continuous Deployment), 100% de test automatique des tests-unitaires jusqu'au tests systèmes (end-to-end), documentation générée, changelogs, infrastructure as code, limites, quotas, pas de "single point of failure" (spof) — , architecture multi-tenant...

C'est de-facto être incapable de réaliser tout cela, dans les temps, sur un projet d'envergure.

‍