HTTP2 for front-end web developers

To get websites to load in an acceptable time using HTTP1 we have developed a series of techniques; hacks really; to eke performance out of this old protocol. They are:

  • Spriting: taking multiple images, combining them into one image, and using CSS to only show part of that image in a particular place.
  • Concatenating: Taking multiple CSS or JS files and sticking them into one large file.
  • Serving assets from a cookie-less domain.
  • Sharding: creating different domains or sub-domains to host assets like images.

Avec l’arrivée de HTTP 2, ces quatre optimisations tendent à devenir inutiles, voire contre productives.

Pour les deux premières, le pipelining devient plus intelligent (donc réellement utilisable) et au besoin le serveur peut pousser les contenus sans même attendre qu’ils soient demandés par le client.

Pour les deux suivantes, le système de compression des entêtes et de multiplexage rend le retour sur investissement d’une nouvelle connexion TCP à un domaine tiers franchement contestable. Vous risquez de perdre de la performance au lieu d’en gagner.

La leçon est intéressante. Pendant quelques années les développeurs ont cherché à contourner les navigateurs, croyant pouvoir être plus smart. Le problème c’est que les navigateurs et les protocoles ont évolué entre temps pour résoudre les mêmes problèmes. Les bouts de scotch des développeurs peuvent désormais faire plus de mal que de bien. C’est toute une littérature qu’il va falloir mettre à jour.

AT&T To Match Google Fiber In Kansas City, Charge More If You Want Privacy

The company plans to charge $70/month for gigabit service, but that’s a subsidized price. Subsidized by what, you ask? Your privacy. AT&T says if you want to opt out of letting them track your browsing history, you’ll have to pay $29 more per month. They say your information is used to serve targeted advertising, and includes any links you follow and search terms you enter.

L’information n’est pas surprenante par son contenu mais par ses chiffres. Vos informations personnelles valent 30€/mois d’après AT&T, uniquement pour mieux cibler les publicités (ça laisse donc entrevoir le gain des publicités elles-mêmes, forcément supérieur)

– via Slashdot

Et que fait-on des estimations ?

Quelle est votre stratégie agile ?

  • Le plus stratégique en premier ?
  • Ce qui est techniquement plus complexe en premier ?
  • Ce qui est le plus risqué en premier ?
  • Ce qui se voit en premier ?
  • Ce qui est le plus simple en premier ?
  • Ce qui apporte le meilleur retour sur investissement en premier ?

Il n’y a pas de bonne ou de mauvaise réponse. C’est uniquement une histoire de stratégie. L’important est d’être cohérent sur une période pour mettre en œuvre cette stratégie et de ne pas faire un peu de tout à la fois.

Intéressant de noter tout de même que sauf ordre de grandeur extraordinaire (donc facile à identifier sans être bon en estimation), seule les deux dernières stratégies ont réellement besoin d’estimation avant réalisation.

Toute l’estime que je vous porte

Comme beaucoup d’ingénieurs, je suis réticent à donner des estimations.

je ne sais pas estimer

Tous les jours, je résous des problèmes nouveaux, pour lesquels je n’ai encore jamais implémenté de solution.

Si vous n’avez jamais fait d’informatique, mettez-vous bien ça dans la tête : Contrairement au maçon qui peut construire des dizaines de maisons, l’informaticien ne fait jamais deux fois la même chose. Il peut réutiliser la solution précédente à l’infini, en quelques heures. Qu’un développeur fasse deux fois exactement la même chose est le symptôme d’un problème d’organisation.

Si je passe plus de quelques heures, c’est qu’il y a un problème nouveau ou quelque chose de nouveau dans le problème, même si de haut il ressemble à un autre. Mon travail c’est uniquement de créer ce qui manque, ce qui est nouveau par rapport à d’éventuelles solutions précédentes.

Et pour ce nouveau, je vais devoir étudier le problème posé, probablement découvrir des sous-problèmes qu’on n’imaginait pas. Je ne sais pas ce quelles difficultés je vais rencontrer, quelles solutions vont devoir être appliquées, comment les mettre en œuvre, si elles vont réussir ou échouer, et encore moins si le besoin racine va effectivement être couvert à la fin de tout cela.

Il y a plein de textes qui expliquent la problématique de l’estimation mais j’ai trouvé plus d’une fois que le récit de voyage de Michael Wolfe illustre très bien les enjeux avec une analogie que tout le monde comprend.

vous non plus

J’ai croisé de nombreuses personnes qui annonçaient savoir estimer assez correctement, et quelques unes qui semblaient effectivement le faire. Vous en connaissez peut-être aussi.

En pratique à chaque fois qu’on y regarde de plus près, l’estimation n’est pas plus juste qu’une autre. Au mieux on compense les mauvaises estimations en jouant sur le contexte. L’estimation est potentiellement respectée, mais elle n’en est pas plus juste. Et quand compenser ne suffit pas, on se rassure en considérant que ça ne compte pas parce que c’est exceptionnel, qu’il y a une cause extérieure, ou en reportant la faute sur un tiers.

Même les itérations de la tant aimée méthodologie SCRUM jouent sur le même registre : Donner une cible avec un engagement permet d’avoir un peu de pression sur l’équipe. C’est de la pression dite « positive », pour avoir envie d’atteindre l’objectif.

Au final c’est de la pression tout de même, qui souvent se retrouve sur l’amplitude horaire ou sur la fatigue. Quand le management n’a pas une attention et une culture extrêmement forte sur le sujet, ça joue aussi sur une baisse de qualité ou une création de dette technique. C’est humain. À défaut c’est le périmètre qui bouge, mais l’estimation n’en est pas meilleure. Bref, on pallie la mauvaise estimation en jouant sur le contexte.

Si vraiment quelqu’un estime toujours juste à plus de 90%, sans compenser sur le contexte, c’est qu’il est en train de passer du temps à refaire ce qu’il a déjà fait. S’il travaille pour vous : virez-le et embauchez quelqu’un qui saura réutiliser plutôt que perdre du temps.

même par petits lots

Même l’estimation par petits lots itératifs n’est qu’une illusion. On estime effectivement mieux des petites tâches qu’on sait percevoir, mais c’est uniquement parce qu’on réfléchit déjà à la problématique et à sa solution au moment de donner l’estimation.

Par la suite on se trompe autant qu’ailleurs. On compense là aussi par l’amplitude horaire, le stress de la pression personnelle, la qualité ou la dette technique. C’est juste que plus la tâche est petite, plus le décalage probable est petit et donc moins il se voit de l’extérieur quand on regarde unitairement.

Vous avez déjà remarqué qu’on ne fait pas tenir 8 tâches d’une heure dans une journée ou 5 tâches d’une journée dans une semaine ? Des tâches d’une heure dans une journée, prévoyez-en 6, moins le temps pour les réunions.

Et des fois on a juste oublié un cas d’usage ou manqué une problématique. Sur un lot important on aurait assumé et dérapé un peu. Sur une petite tâche le cas manqué peut prendre plusieurs fois l’estimation de la tâche initiale. On en fait donc une nouvelle tâche, avec sa propre estimation. Là aussi, l’excuse du cas exceptionnel ou de la sortie de périmètre permet d’éviter de remettre en cause ses estimations.

Alors oui, les estimations sur des petits lots ont tendance à être plus souvent respectées mais elles n’en sont pas beaucoup plus justes. Tout ceci n’est qu’œillères et illusions.

C’est mieux – et c’est logique vu qu’on estime au fur et à mesure du projet, une fois la connaissance acquise – mais ce n’est toujours pas bon.

la mauvaise question

On peut discuter de l’utilité des estimations, de la capacité du genre humain à savoir donner des estimations absolues. On peu aussi s’enfoncer dans un projet d’opposition, scander #noestimate… mais qu’apporterait-on comme valeur ?

Je suis surtout agacé qu’on se pose surtout la mauvaise question. Au jour le jour je n’ai aucunement besoin d’estimer. J’ai besoin d’apporter de la valeur. La seule question à me poser est « qu’est-ce qui amènera à priori le plus de valeur demain si je le fais aujourd’hui ? » et mettre mes ressources dessus.

La question n’est pas simple pour autant. J’ai besoin d’évaluer si le niveau d’effort à fournir est rentable par rapport à la valeur ajoutée attendue. Ensuite j’ai besoin de prioriser les évolutions entre elles, en fonction de la valeur et du niveau d’effort.

Sauf que justement, je n’ai besoin pour ces usages que d’un ordre de grandeur : Est-ce 10, 100 ou 1000 ? Est-ce beaucoup plus ou beaucoup moins que l’autre évolution à laquelle je pense ? Tout autre détail est aussi utile qu’un parachute pour monter sur une échelle.

L’évaluation de la valeur attendue subit de toutes façons les mêmes incertitudes que le niveau d’effort à fournir. Même s’il est fait à base d’une page pleine de formules, calcul de la valeur attendue dépend parfois totalement de paramètres estimés au doigt mouillé, où même un ordre de grandeur relève plus de la conviction que de l’estimation.

le mauvais usage

Vous posez-vous vraiment la bonne question ?

En cherchant à savoir si votre projet dérape vous êtes simplement en train de regarder s’il se conforme au plan prévu, à son estimation. Vérifier la validité d’une estimation ne vous apportera aucune valeur, surtout quand on sait dès le départ qu’elle est soumise à des aléas imprévisibles.

Pire, en imposant l’estimation préalable comme indicateur, on freine l’initiative (si je le fais, on prend un risque, même si je sais qu’il faut le faire), on freine la capacité de changer (si on le fait, il faut recalculer le plan, re-estimer, négocier cette estimation, expliquer le mauvais indicateur, ça ne vaut pas le coût ici, tant pis), et on oublie notre objectif (l’indicateur est bon, tant pis si en fait on s’est rendu compte que ça ne créait pas la valeur attendue et qu’il aurait fallu faire autre chose, ça aurait remis en cause le plan).

Vous pouvez vous dire que vous saurez déjouer tout cela, rester agile et pragmatique. Vous vous mentez, du moins tant que votre question sera « où est-ce qu’on en est par rapport aux estimations ? ».

C’est encore pire si vous utilisez l’estimation comme métrique pour apprécier l’efficacité ou la compétence de l’équipe de production. Là non seulement vous comparez juste des choux et des carottes, mais en plus vous inversez votre résultat : Ce sont des équipes qui respectent toutes leurs estimations que vous devriez avoir peur. Elles masquent leurs erreurs en les compensant, volontairement ou non, et ça faussera toutes vos analyses sur la production passée ou future.

arrêter de naviguer dans le passé

Les méthodes agiles vont dans le bon sens mais il est trop facile de s’arrêter aux artefacts sans en comprendre l’objectif. Le principe n’est pas que de découper en petits lots plus faciles à estimer pour pouvoir reprendre une décision entre les différents lots.

Il y a aussi une philosophie derrière, celle de l’apport de valeur.

Seul le présent créé de la valeur. La stratégie envisage le futur, les rétrospectives tirent les leçons du passé. Si vous n’êtes ni dans un contexte de choix stratégique ni en train de tirer des leçons en rétrospective, vous ne devez que vous préoccuper de la meilleure façon d’apporter de la valeur là, maintenant, tout de suite, peu importe ce que vous aviez pu prévu ou estimé par le passé.

Que dois-je faire aujourd’hui et maintenant pour apporter le plus de valeur ?

La pertinence de l’estimation passée ne m’est jamais d’aucune utilité pour répondre à cette question. J’insiste : Jamais. Je prends en compte les difficultés et facilités dans des rétrospectives pour m’améliorer. Je les prends en compte pour évaluer l’effort à fournir sur le reste à faire, et donc l’opportunité de continuer. Que ces facilités ou difficultés aient été prévues ou non, que j’ai divisé par 2 ou multiplié par 20 mon estimation n’importe finalement aucunement.

Estimez, c’est utile, important. Ensuite oubliez-les et surtout ne les réutilisez pas pour autre chose.

(sur le même sujet We don’t need no stinking estimates)

Photo d’entête sous licence CC BY-NC-SA par Mark Notari