Vous vous demandiez peut-être à quoi je passais mon début d’année (plutôt que de vous écrire des articles de 3 pages de long) ? Et bien en dehors de ma récente promotion (une fois nos expérimentations d’organisation stabilisées je vous en parlerai, soyez patients), je le consacre à la finalisation d’un projet de plusieurs mois, réalisé par un padawan de talent et supervisé par mes soins.

Sont pas beaux mes padawans? Tenue obligatoire en clientèle!

Entre 2 anomalies à corriger, nous rédigeons la documentation et préparons le voyage de l’application de l’environnement de développement, et de notre responsabilité, à celui de production, et à la responsabilité de l’exploitation. Au passage c’est toujours pendant ce genre de transition que l’idée du devops revient me faire des yeux doux. Ou encore le concept de livraison continue. Malheureusement ici je n’ai pas réussi à convaincre le métier et l’IT de bosser en mode Agile. Mais ce n’est pas le sujet du jour, revenons à nos moutons !

La documentation technique terminée, elle est relue par le directeur d’étude (respect, ce n’est pas souvent que ça arrive). Et ce dernier s’étonne : quasiment pas de règles de gestion, un schéma en étoile simpliste, un cube à la DSV vide, des dimensions sans surprises techniques. Ok on trouve bien quelques calculs MDX, et ok la partie ETL fait pas loin d’une centaine de packages, mais ce n’est que parce qu’on a fait un bon travail et bien tout découpé en flux de données unitaires. En dehors de ça la solution semble étonnement vide pour 3 mois de développement.

Minimaliste mais plein de goût, comme au resto gastronomique!

Et bien pour tout vous dire, j’en suis assez fier. Parce que pour arriver à cette apparente simplicité, ce « vide » dans la solution, cela nous a demandé des efforts considérables. Un projet informatique est soumis à une certaine forme d’entropie. Plus on avance, plus des éléments viennent se rajouter, des fonctionnalités, des données, des exceptions, des contournements, et si on n’y fait pas attention, sans rien toucher au périmètre initial de l’application, la solution est tout de même devenue un plat de spaghettis indémêlables avant même la livraison du lot 1.

Lutter contre cette tendance demande un effort constant. Dès qu’on se relâche, on se retrouve avec des règles de gestion implémentées dans des vues (ou pire, dans la DSV du cube), parce que c’est rapide, plutôt que de faire les choses proprement et d’ouvrir une énième fois l’ETL, modifier les métadonnées, les flux, et tout re-tester après.

Mais il ne faut pas se leurrer : tout ça c’est de la dette technique, et rien de pire pour une solution informatique de commencer sa vie encore plus endettée qu’un étudiant américain ! Alors ne relâchez pas la lutte, pensez marathon plutôt que sprint (rien à voir avec SCRUM ;)), pensez Lean, et faîtes un cadeau au vous de dans 6 mois qui devra bosser sur le lot 2 ou corriger une anomalie: laissez-lui une solution toute propre, il vous remerciera!