Professionnellement, j'assiste mes développeurs dans la conception d'une application permettant la location de véhicule.

Il y a quelques temps, notre responsable fonctionnel a décidé que notre application devait dorénavant vérifier qu'il y avait bien à minima 18 ans entre la date de naissance du locataire du véhicule et la date d'obtention du permis de conduire.

S'il n'y avait pas ces 18 années d'écard, l'application devait refuser la souscription du contrat de location.

Évidemment, l'ajout de cette contrainte étant parfaitement logique, personne n'a soulevé la moindre objection, d'autant que le développement à réaliser ne posait absolument aucun problème.

Cependant, à notre grande surprise, lors de la mise en production, nos clients n'ont pas été du tout content.

En effet, pour certains des locataires déjà présent en base de données, la date de naissance et/ou la date d'obtention du permis avait été mal renseigné, et il n'était donc plus possible pour eux de louer à nouveau un véhicule.

Et ensuite, il est très possible d'avoir obtenu son permis avant 18 ans, soit parce que c'était possible à l'époque, soit parce qu'il a été passé dans un autre pays.

Sous des dehors vertueux, cette contrainte était donc en réalité trop restrictive et nous avons donc été finalement obligé de la désactiver.

L'autre exemple concerne atoum, mon framework de tests unitaires simple, moderne et intuitif pour PHP 5.3+.

Hier, j'ai fais en sorte que les méthodes de test ne contenant aucune assertion figurent dans le rapport généré par atoum lorsqu'il est utilisé en ligne de commande.

L'un de mes développeurs avait en effet été pertubé, avec raison, par le fait que cette information ne soit pas remontée, et j'ai donc fait en sorte de résoudre le problème.

Là encore, il n'y avait aucun obstacle technique et la modification semblait parfaitement logique.

Et pourtant, elle a posé un problème à l'un des utilisateurs de atoum, qui utilise Mockery et uniquement Mockery pour réaliser des assertions dans certaines de ses méthodes de test.

Or, atoum n'a aucune connaissance des assertions exécutées par Mockery, et en conséquence, il considére que les méthodes de test dans lesquelles il est utilisé ne contiennent aucune assertion.

En conséquence, le rapport généré est donc pollué par des messages qui n'ont pas lieu d'être.

Je suis donc obligé de revoir ma copie et de trouver une solution pour pouvoir désactiver en fonction des besoins le listage des méthodes de test vides.

Dans les deux cas, malgré l'expérience des différents acteurs et la sécurité offerte par les tests, les modifications effectuées ont eu des effets très inattendus qui ont rendu obligatoire à minima une nouvelle évolution ou bien carrèment un retour en arrière.

Cependant, dans les deux cas, le code a été mis à la disposition de l'utilisateur final très rapidement et ce dernier a donc pu faire un retour tout aussi rapidement.

Et comme le contexte était encore frais dans les esprits des développeurs, il a été très facile d'effectuer la correction ou de réfléchir à une solution potentielle.

Pour connaître l'impact d'une modification sur les utilisateurs d'un logiciel, il ne faut donc pas jouer à Madame Irma en essayant de les deviner, mais bien mettre le logiciel le plus rapidement possible à la disposition de ses utilisateurs, même s'il ne couvre pas l'ensemble de leur besoin fonctionnel.

Cela permet d'avoir leur feedback très rapidement et donc d'agir dans les meilleurs délais et à moindre coût pour éventuellement ajuster le tir.

Bref, il faut être agile et appliquer le précepte release early, release often !.