Expédiez-le ou mourez (avec ou sans qualité, cependant ?)

L’une des idées qui m’intriguent est la mentalité "expédier ou mourir". En ce qui concerne son nom, il existe des variantes, mais l’idée derrière la phrase est simple :

Si vous avez une idée, faites-la passer du concept au produit le plus rapidement possible.

Bien sûr, l’idée de passer du concept à un produit peut aussi s’appeler « du concept au cash », mais il n’y a jamais de garantie que vous allez générer du cash, n’est-ce pas ? Il y a cependant une garantie que vous pouvez l’intégrer dans un produit tangible.

Et dans les cercles de développement de logiciels, il y a toujours beaucoup de choses qu’une personne peut argumenter pour ou contre l’idée. De prime abord, les deux avantages et inconvénients qui me viennent immédiatement à l’esprit sont :

1. Pro. Faire quelque chose rapidement qui fonctionne et qui [potentiellement] génère des revenus.
2. Con. Faiblesse de l’architecture, de la maintenance, de l’évolutivité, de la testabilité, etc.

En bref, il peut y avoir un compromis entre la rapidité avec laquelle vous pouvez livrer quelque chose pour un marché et l’architecture derrière le projet. Parfois il y en a, parfois il n’y en a pas. D’une manière générale, cependant, je pense qu’il est prudent de supposer le premier.

En outre, certains peuvent voir le premier comme la solution de facilité, certains peuvent voir le second comme un exercice de YAGNI ou, encore plus simplement, que le problème peut être résolu chaque fois qu’il se présente.

Mais qu’est-ce que cela a à voir avec quoi que ce soit en ce moment?

L’expédier ou mourir ?

La raison pour laquelle je passe du temps à écrire à ce sujet est que c’est quelque chose auquel moi, et je soupçonne que d’autres dans notre domaine, réfléchissent au moins un peu. Tout cela est bien beau quand on en parle dans l’abstrait, mais permettez-moi d’essayer de le rattacher à quelque chose d’un peu plus réaliste.

Il était une fois…

Il y a quelques années, le développement front-end consistait à encapsuler le contenu dans des éléments en ligne ou au niveau des blocs et à les styliser avec du CSS de base ?

Nous avions des outils avancés pour travailler avec notre code backend, mais le front-end était relativement simple à part peut-être les normes de codage appliquées par l’entreprise ou l’équipe avec laquelle nous travaillions.

Mais alors…

Nos appareils ont évolué (ce que, pour mémoire, je considère comme une bonne et même chose naturelle en technologie). Parallèlement à cette avancée, nous avons maintenant des outils de construction spécifiquement pour le développement frontal qui sont tout aussi avancés à certains égards que ceux que nous utilisons pour les logiciels backend.

Bien sûr, nous en avons qui sont des "développeurs full stack", mais je suis heureux d’admettre que je suis beaucoup plus à l’aise de travailler côté serveur que côté front-end. Si je travaille sur le front-end, j’ai tendance à m’en tenir aux outils avec lesquels je suis familier et à essayer de rester dans les garde-corps définis par la voie dans laquelle j’opère.

Cela aide à maintenir un développement ciblé, rapide et cohérent d’un projet à l’autre.

D’accord, alors quel est le point ?

En soi, cette section pourrait être un long article, mais je ne suis pas intéressé à aller aussi loin. Au lieu de cela, je vais prendre une seule tranche du fonctionnement actuel du développement frontal et voir si je ne peux pas l’utiliser pour clarifier mon point de vue.

Devenir impertinent

Prenons par exemple ce que CSS est devenu. Nous avons des langages au-dessus des langages (comme Sass qui se trouve au-dessus ou s’ajoute au CSS de base).

Et nous avons des processeurs qui compilent, minifient, peluchent et nous empêchent de voir notre travail avant que certaines erreurs et avertissements ne soient corrigés pour des raisons de qualité. (Je ne considère pas cela comme une mauvaise chose, mais cela montre le niveau croissant de complexité – ou peut-être de maturité – de notre outillage frontal).

Le développement front-end est beaucoup trop facile, rendons-le plus complexe afin que nous puissions nous sentir plus intelligents parmi ceux de nos pairs qui traitent apparemment des aspects plus "critiques" de l’entreprise. N’oubliez pas qu’il s’agit d’un concours.

Cet article a une version humoristique de l’ensemble.

Un degré raisonnable de qualité

Pour être clair, je ne dis pas que c’est une mauvaise chose, mais je dis que les choses qui étaient autrefois reléguées au côté serveur ou aux langages compilés s’étendent maintenant à toute la pile de développement d’une application Web.

Pour être aussi clair que possible: je suis pour la qualité. Expédier des choses sans aucun degré peut être considéré comme un exercice d’irresponsabilité.

Mais je crois aussi qu’il y a un équilibre à trouver entre écrire le code le plus optimal, fonctionnel et performant possible sous les contraintes de temps et de budget.

Je ne crois pas, peu importe à quel point nous essayons de nous l’imposer, que nous vivons dans une utopie de développeur où nous pouvons optimiser, concevoir et mettre en œuvre des systèmes vierges dans chaque projet.

Il semble cependant que nous ayons fait de notre mieux pour le créer, n’est-ce pas ?

Mais à un moment donné, ne vaut-il pas la peine de se demander si tous les outils que nous créons et toutes les choses que nous ajoutons à nos projets suppriment ce qui nous a fait entrer dans l’industrie en premier lieu ? Certes, pour certains d’entre nous, c’est probablement différent. Est-il juste de demander qu’avoir une idée, écrire du code pour lui donner vie et la voir résoudre un problème est ce qui nous a amenés dans le giron ?

À ce stade, cependant, nous avons introduit tellement d’outils que la mise en place d’un environnement de développement pour une application Web s’exécutant de la base de données jusqu’au navigateur est une tâche intimidante.

Tant de choses doivent se produire avant que nous soyons réellement prêts à commencer à écrire du code qu’il peut devenir fastidieux et même un peu épuisant de simplement prendre les premières mesures pour le faire.

Un avis personnel et définitif

Je gravite vers l’application de pratiques et d’outils orientés objet solides dans de nombreux projets sur lesquels je travaille avec mon équipe et que j’expédie pour d’autres parce que je sais, par expérience, le temps, les dollars et les données qui peuvent être perdus de quelque chose n’est pas t adressé de toutes parts.

Cela ne veut pas dire que l’expédition rapide de quelque chose annule tout cela. Mais le processus et l’organisation du code derrière un projet sont quelque chose que j’ai beaucoup de mal à ignorer, à tel point qu’il est presque paralysant d’expédier quelque chose qui n’a pas été testé et approuvé au plus haut degré possible (et même alors, il y a problèmes).

D’un autre côté, cependant, il y a une partie de moi qui veut expérimenter une idée ou deux derrière la mentalité "expédier ou mourir" juste voir à quelle vitesse quelque chose peut être construit, expédié et générer n’importe quel type de revenu, peu importe à quel point il est vierge la base de code est.

Et peut-être que je vais essayer ça avec quelques projets à venir.