Hackathon ou code cochon?

Un week-end plein de (proto)types sales… ou le début d’applications innovantes?

Quand on m’a présenté le concept de hackathon, voici tout de suite ce qui m’est venu à l’esprit: une réunion de geeks (ou hackers) qui s’enferment durant tout un week-end pour coder ensemble une application au finish (d’où l’idée de marathon de hackers).

En somme des “nolife” en t-shirts avec tête de mort ou gros pingouins, dans une cave, mangeant des chips ou cacahuètes et des pizzas, buvant de la bière ou de la boisson à base de taurine, des écouteurs sur les oreilles, devant des écrans au fonds sombres et tapant une quantité de code incompréhensible dans une invite de commande qui leur répond par des codes à la Matrix.

Peut-être partagez-vous la même image d’un tel événement sur base du nom un rien barbare: “Hackathon”.

Il faut dire que j’ai toujours eu comme secret souhait d’être associé au terme hacker. J’ai fait mes études accompagné de certaines personnes qui m’ont fortement donné le goût de la découverte du fonctionnement des applications, je pense à Grégoire D., David J., Fabien P et Antony L. grâce à qui j’ai découvert LaTeX, et surtout le langage Python. Et je dirais qu’à côté d’eux je faisais pâle figure, sans jeu de mots :-)

Durant un week-end, j’ai souhaité me téléporter 12 ans en arrière. Je me revois dans la salle du département informatique en train de coder George, le conducteur automatique de train, ou encore un prometteur Meeting Scheduller, en écoutant, ô révolution de l’époque, de la musique au format MP3 tel que “Don’t Give Up” de Bryan Adams, “Freestyler” de Bomfunk MC’s ou encore “Why does my heart feel so bad?” de Moby. Bref, j’étais “chaud boulette” à l’idée de revivre ces sensations. Je m’imaginais aussi être un papy (de 36 ans) parmi les participants.

Le Hackathon auquel j’ai participé, le Hackathon eGov Wallonia, avait un thème particulier: pirater les données ouvertes. Déjà on peut se poser demander quel est l’intérêt de pirater quelque chose qui est ouvert. Ensuite s’il y a bien quelque chose qui semble imperméable à la technologie c’est bien l’administration. On imagine aisément l’eGov comme étant une initiative de l’administration publique qui vise à remplacer ses vielles applications COBOL par des applications web capables de tourner sur Mosaic et affichant ô bonheur une interface pleine de GIF animés “Nouveauté” ou “Cliquez ici” ou encore une boîte aux lettres avalant une enveloppe. Oui, je sais, ça sent le vécu, j’ai fait de tels magnifiques sites web en 1996.

Je résume ici le déroulement de ce hackathon.

Lors de l’étape des pitchs,des porteurs d’idées ont eu 3 minutes pour convaincre les participants de rejoindre leur initiative. J’ai présenté une idée, #MakeMeAPI, qui permet, sur base de mots clés, de trouver les sources d’information à combiner entre elles.

Lors de l’étape des votes, chaque participant a choisi 3 idées auxquelles il souhaitait contribuer; les 8 idées ayant le plus de votes ont été sélectionnées pour implémentation. #MakeMeAPI a été sélectionnée.

Lors de l’étape de constitution des équipes, chaque porteur de projet sélectionné devait trouver ses “hackers”. Grâce à un marketing improvisé, j’ai recruté 2 développeurs parmi les indécis et un collègue m’a rejoint. La team #MakeMeAPI était constituée.

Lors de l’étape de réalisation, les projets ont été développés sur les serveurs mis à notre disposition (phpMyAdmin, ssh/sftp). #MakeMeAPI partant “from scratch”, on a choisi le langage (PHP) et le framework web (Laravel). J’avais le rôle de porteur de projet, je n’ai donc pas tenté d’imposer Python d’autant que j’étais en minorité (1 contre 3). Après 2 jours de codage intensif, nous avons pu présenter un prototype fonctionnel.

Lors de l’étape de présentation, les réalisations du week-end ont été présentées à l’ensemble des participants ainsi qu’au jury. Je dois avouer avoir trop peu préparé cette présentation, car je modifiais encore le code à 3 minutes du début des présentations.

Lors de la dernière étape, le jury a primé les idées avec 3 prix. #MakeMeAPI n’a reçu aucun prix mais était en ballotage pour au moins l’un d’entre eux ;-)

Mon expérience lors de ce hackathon a été très enrichissante. Tout d’abord, les organisateurs étaient à la hauteur. Par exemple, même si des chips étaient présents, ce n’était que pour le cocktail de bienvenue et nous n’avons eu de pizzas que le premier jour. Les participants étaient pour la plupart, bien loin de l’image des hackers telle que décrite ci-dessus. Je n’étais pas un papy car bon nombre des participants étaient dans ma tranche d’âge (peut-être le thème eGov Wallonia y était pour quelque chose). Enfin, les idées portées n’avaient rien à voir avec le caractère “nolife” mais concernaient plutôt le partage, la mobilité, la culture, etc.

Au bout du week-end bon nombre des idées sélectionnées ont été implémentées. Mais à quel prix? Et c’est là que le concept de dette technique prend tout son sens. La dette technique d’une application peut s’expliquer de la façon suivante: lors du développement de l’application, pour de bonnes et mauvaises raisons (manque de temps, fin de budget, etc.) l’équipe de développement est amenée à enfreindre quelques règles de bonne pratique. Cependant, tôt ou tard, elle devra appliquer la bonne pratique pour amener le code de l’application à un niveau de qualité adéquat. Appliquer cette bonne pratique a posteriori engendre un coût (mobilisation de ressources sur une fonctionnalité déjà réalisée), que l’on nomme dette technique. Pour des applications développées en un seul week-end, la dette technique n’est évidemment pas énorme compte tenu que le nombre de lignes de code produit est faible. Par contre, elle est bien présente.

Il serait donc intéressant de pouvoir mesurer cette dette technique lors du hackathon et primer les initiatives ayant la dette technique la plus faible. En effet, il y a eu une telle énergie produite pour réaliser ces prototypes et la majorité d’entre eux n’aura pas de lendemain. Qui va reprendre une idée commencée dans un autre hackathon? L’équipe de développement ne sera pas la même, le jury va avoir l’impression de réchauffé, etc. Favoriser les bonnes pratiques permet un code réutilisable, et un prix spécifique permettrait d’encourager cela.

Pour conclure, je dirai que de tels événements bien que ne favorisant pas toujours la production de code de haute qualité, favorisent la rencontre et l’échange entre passionnés. Les prototypes produits ne sont pas toujours les plus propres et ne sont pas toujours réutilisables mais démontrent qu’un bonne dose de créativité permet de réaliser des prouesses en très peu de temps.