Dans son papier "Uncertainty, risk, and information value in software requirements and architecture", Emmanuel Letier avait jeté un pavé dans la mare [1].
Invoquant la pyramide de Moslow, il admettait que sa méthode n'avait pas encore été largement testée sur le terrain, mais qu'elle était correcte. Et que c'était certainement préférable à l'inverse : une technique très largement utilisée et incorrecte.
Les nombreuses discussions suite à mon post sur mon désaccord avec Michael Azerhad m'ont fait penser à lui : de nombreux développeurs ont insisté sur l'importance de ne pas s'encombrer d'une base de données, parce que cela permet de tester viiite pour mettre en production viiite.
Peu importe finalement que cela augmente la complexité systémique (p.ex. microservices), et affaiblisse toute réflexion sur le fait que le logiciel soit correct (voir aussi mon post sur le temps et les horloges). On. en. est. plus. là.
Quelqu'un m'a même dit que j'étais ivre. C'est possible. Il est possible aussi que l'industrie soit ivre morte. Et le pire donc, c'est qu'on ne sait pas bien trancher.
On pourrait par exemple me rétorquer que mettre en production fréquemment permet de vérifier l'utilité du logiciel auprès des utilisateurs. Ou que les tests unitaires visent à éviter les bugs [2].
La méthode d'analyse des besoins KAOS, à laquelle Emmanuel a largement contribué, invite à décomposer des arbres d'objectifs en sous-objectifs. Son père fondateur, Axel van Lamsweerde, aimait indiquer que les étudiants inversent souvent la relation WHY/HOW.
Je vous laisse donc choisir la pyramide qui convient, ou m'en proposer une autre [3].
J'ai cette hypothèse personnelle que les logiciels d'aujourd'hui tiennent plus de l'amusement startupien que d'une nécessité vitale pour la société, à l'inverse des systèmes créés au 20ème siècle. Peut-être ceci explique-t-il cela ?
#SoftwareEngineering #Databases
les critères d'acceptation des papiers à ICSE (Intl. Conference on Software Engineering) mettaient trop l'accent à son goût sur l'évaluation de terrain, sans se soucier du reste. ↩︎
ce qui est fort différent d'avoir un logiciel correct. Éviter les bugs c'est très local, ces critères là sont systémiques. ↩︎
a minima, c'est un exercice de pensée intéressant. Par exemple "utile => correct" est suspect. Je peux trouver un logiciel utile même s'il a quelques bugs, ma conclusion suggère d'ailleurs que c'est une explication du revirement sur software engineering depuis la première bulle internet. On sait par ailleurs que "correct => utile" est strictement faux. Il manque un raisonnement sur les risques, en vrai. ↩︎