La complexité robuste est atteinte grâce à des boites noires qui obéissent à un modèle de comportement simple.
Peu importe le module, la couche logicielle, l’application, le système informatique, la voiture, la machine à laver, la prise électrique (le summum de la boîte noire) : toute leur complexité est "cachée" derrière une interface que l’utilisateur peu conceptualiser avec le minimum de mémoire de travail : il pourra alors se concentrer sur ce qu’il a à faire lui. La robustesse est atteinte par la très grande prévisibilité de l’interface proposée.
Or l’ergonomie générale en informatique, aussi bien celle destinée à l’utilisateur final (ihm graphique ou non) que celle destinée aux collègues (api), n’est pas au mieux de sa forme...
Une des causes est l’abandon de l’objectif de stabilité, et de normalisation le cas échéant, des interfaces. Cela devient un vrai gros problème car, dans le monde industriel (pas l’informatique moderne), il y a toujours un effort minimum de normalisation pour s’assurer que tous les acteurs d’un même domaine parlent la même langue, associée à un bagage technique commun. Il s’agit toujours d’une langue qui est une abstraction de la réalité. C’est la condition nécessaire du développement d’une expertise technique reconnue, au lieu des gate-keepers, instauration des monopole et marchés de niche.
Une autre cause, c’est le « pissage de code » sans effort de modélisation et conception en amont. C’est induit par le monde commercial/pro qui réclame de pondre du résultat facilement évaluable. Là où la conception c’est lâcher le clavier, poser le stylo et réfléchir. Difficile pour le manager pressé de savoir si son équipe est alors en train de se tourner les pouces ou pas... (avec toutes ces méthodes de travail typées « agiles », TDD, CI/CD, etc., où la primauté va à la production de "livrables" identifiables). Il fut un temps où l’informatique était encore influencée par le monde universitaire et ses méthodes académiques...
Enfin, nous avons de plus en plus affaire à des intégrateurs qui se prennent pour des codeurs. Avec des codes de plus en plus spécialisés, là où l’idée géniale de Posix, entre autres, c’est bien de produire des briques génériques dont les combinaisons exponentielle produisent des résultats spécifiques attendus (ce qui nécessite, encore une fois, un travail de modélisation et de conception). D’où de facto, les dépendances à rallonge...
[^] # Re: Robustesse
Posté par Nicolas (site web personnel) . En réponse au lien "Trente ans d’open source... pour en arriver là". Évalué à 10.
Complexité ≠ Robustesse.
La complexité robuste est atteinte grâce à des boites noires qui obéissent à un modèle de comportement simple.
Peu importe le module, la couche logicielle, l’application, le système informatique, la voiture, la machine à laver, la prise électrique (le summum de la boîte noire) : toute leur complexité est "cachée" derrière une interface que l’utilisateur peu conceptualiser avec le minimum de mémoire de travail : il pourra alors se concentrer sur ce qu’il a à faire lui. La robustesse est atteinte par la très grande prévisibilité de l’interface proposée.
Or l’ergonomie générale en informatique, aussi bien celle destinée à l’utilisateur final (ihm graphique ou non) que celle destinée aux collègues (api), n’est pas au mieux de sa forme...
Une des causes est l’abandon de l’objectif de stabilité, et de normalisation le cas échéant, des interfaces. Cela devient un vrai gros problème car, dans le monde industriel (pas l’informatique moderne), il y a toujours un effort minimum de normalisation pour s’assurer que tous les acteurs d’un même domaine parlent la même langue, associée à un bagage technique commun. Il s’agit toujours d’une langue qui est une abstraction de la réalité. C’est la condition nécessaire du développement d’une expertise technique reconnue, au lieu des gate-keepers, instauration des monopole et marchés de niche.
Une autre cause, c’est le « pissage de code » sans effort de modélisation et conception en amont. C’est induit par le monde commercial/pro qui réclame de pondre du résultat facilement évaluable. Là où la conception c’est lâcher le clavier, poser le stylo et réfléchir. Difficile pour le manager pressé de savoir si son équipe est alors en train de se tourner les pouces ou pas... (avec toutes ces méthodes de travail typées « agiles », TDD, CI/CD, etc., où la primauté va à la production de "livrables" identifiables). Il fut un temps où l’informatique était encore influencée par le monde universitaire et ses méthodes académiques...
Enfin, nous avons de plus en plus affaire à des intégrateurs qui se prennent pour des codeurs. Avec des codes de plus en plus spécialisés, là où l’idée géniale de Posix, entre autres, c’est bien de produire des briques génériques dont les combinaisons exponentielle produisent des résultats spécifiques attendus (ce qui nécessite, encore une fois, un travail de modélisation et de conception). D’où de facto, les dépendances à rallonge...