C'est un titre un peu provocateur, mais j'aimerais ici poser la réflexion de construire quelque chose (en particulier un logiciel mais pas que) qui soit facile de maintenir et de faire évoluer.
En s'autorisant une analogie, imaginons un habitat. Que celui-ci est tellement complexe qu'il faut être un expert en parkour pour déambuler à l'intérieur. Dans cette situation, la personne qui est à l'aise pour se mouvoir dans cet espace tire pas mal de reconnaissance. Il faut avoir un réel talent pour éviter les pièges de cet espace mal distribué / agencé.
De plus, remettre en question la construction pour la faire évoluer risque d'être difficile. Les usagers sont habitués, ils ont acquis des habitudes voire des réflexes. Changer l'habitat va bousculer ce capital de connaissance propre à celui-ci.
Alors que l'approche est louable elle peut être perçue comme des bâtons dans les roues du quotidien des utilisateurs. On peut aussi noter ici l'énergie dépensée par l'utilisateur, faire du parkour ce n'est pas une promenade de santé.
Imaginons maintenant la situation inverse : un habitat ergonomique, pensé pour l'usage.
Dans cette situation… hé bien rien, c'est un non-événement. Changer de pièce ne requiert aucun talent et aucun effort exceptionnel n'est nécessaire. L'architecte n'est ni cité ni complimenté, car - il me semble - quand ça se passe bien on ne le relève que trop rarement.
Mon propos ici est que pour les programmes c'est pareil. Bien des fois j'ai rencontré un code qui demandait une certaine technicité à décrypter, un effort, certains parlent même de charge cognitive.
Chaque bifurcation complexe dans la description du programme sont à mes yeux une occasion de poser un problème et d'y trouver une opportunité de rendre plus rentable le programme.
Après tout, si le premier utilisateur / développeur venu peut s'en servir, le faire évoluer facilement n'est-ce pas un bon signe ? C'est une bonne nouvelle aussi pour le bus factor, si c'est facile personne n'est indispensable et n'importe qui peut s'y atteler.
Il n'est pas évident, dans un contexte où tout le monde est focalisé sur la livraison (sous entendu vite) de garder les choses simples. Un raccourci est vite pris mais son coût n'est que rarement estimé.
Heureusement j'ai aussi vécu de bonnes experiences, notamment chez deezer où nous devions développer une API pour les assistants vocaux et autres objets connectés. Un gros effort a été pris pour le leader technique sur la conception. Les bases étaient posés schématiquement, quelques points (mais presque aucune réunion). Un vrai petit framework était décrit, avec ces repositories, models, entities, hydrators, router, dispatcher, factory.
J'étais parti en vacance au début de son implémentation, mais quand je suis revenu et que j'ai dû développer une nouvelle fonctionnalité sur cette base - en ayant tout oublier de sa conception - tout c'est passé limpidement. Dès que j'oubliais une dépendance, une exception claire était levé, j'étais guidé par le code lui même. Une fois les quelques exceptions prisent en compte, j'avais ma route fonctionnelle je n'avais plus qu'à me concentrer sur le métier.
Et qu'est-ce que ça coûté ? Il ne s'agit pas vraiment d'argent, mais plutôt d'efforts, surtout pour changer des habitudes et voir un peu le comment avant le quand.
Conclusion
Si les enjeux de délais sont réels, prenons les en compte. Mais il serait malheureux de garder ce point de vue juste par culture, habitude. Avoir des phases d'anticipation pragmatiques = conception (ne pas anticiper l'inenvisageable) est un bénéfice certain et devrait s'inscrire dans le cycle de production. Est-ce que cette étape est trop souvent négligée parce qu'on traduit trop souvent design pour graphisme ?