D'un autre côté, toute l'informatique était plus simple avant.
J'aime bien cette phrase. J'ai fait le même constat.
Mais, plutôt que de me dire «l'informatique est devenue compliquée et il faut s'y faire», j'ai tenté de répondre à la question «pourquoi?»
Il n'y a pas qu'une seule réponse. Mais ce que j'ai constaté — et de plus en plus — c'est que les gens, dont les développeurs, ont de moins en moins la capacité à comprendre l'énoncé d'un problème et ont de moins en moins la capacité à résoudre un problème complexe autrement qu'en mettant en place des solutions compliquées (j'utilise complexe et compliquée à dessein). J'ai fait ce constat en observant les gens autour de moi (mais pas seulement), ainsi que les logiciels mis en place et en faisant bilan sur bilan tout au long de ma vie.
L'informatique est-elle donc plus compliquée? ou plus complexe?
Est-elle plus compliquée? Impossible de répondre sans généralisation excessive. Mais si elle est plus compliquée, c'est peut-être aussi parce que ceux qui sont derrière n'ont pas la capacité à trouver une solution logique et optimisée à un problème complexe. J'insiste sur le fait que «complexe» et «compliqué» ne sont pas inter-dépendants.
Est-elle plus complexe qu'avant? Certainement. Mais si c'est le cas, est-ce que cela justifie des solutions si compliquées, que seuls des experts de haut niveau soient à mêmes de les comprendre et de les maîtriser?
Parfois il est des problèmes qui ne doivent pas être résolus. Je veux dire par là que, lorsqu'on définit un projet, une limite claire et incontestée doit être tracée entre les problèmes inhérents au projets, c-à-d auxquels le projet lui-même fournit une solution et ceux qui sont hors-sujet. Or c'est précisément définir ce qui est hors-sujet la tâche la plus ardue et la tentation est grande. Vouloir résoudre des problèmes qui n'entrent pas dans le cadre du projet rend la solution finale non seulement complexe mais compliquée.
Pendant l'évolution d'un projet, grande est la tentation à ajouter des fonctionnalités. Mais avec l'ajout de fonctionnalités, si elle n'a pas été planifiée scrupuleusement depuis le début, il arrive que certaines d'entre elles remettent en cause la raison même de l'existence du projet. Ceci n'est qu'un exemple de ce que j'ai observé. Il en résulte des projets tentaculaires, des monstres voraces en ressources ou que sais-je encore.
Dans mon expérience personnelle, par exemple, j'ai rarement vu des projets qui prenaient en compte les aspects sociaux et humains. Il n'est pas rare d'entendre «C'est à l'utilisateur de s'adapter» ou «Il faut vivre avec son temps», qui vont à l'encontre des bases de l'analyse des systèmes d'information. Et ce sont des phrases de ce type qui sont invoquées lorsque des utilisateurs, réfractaires aux changements, provoquent la lassitude et l'agacement des intégrateurs. Et c'est cet agacement qui provoque l'erreur classique consistant, in fine, de guerre lasse, à appliquer cette sentence à tous ceux qui s'y opposent, fourrant dans le même sac opposants légitimes et crétins réfractaires-tout-court. On pourrait comparer cette situation à la loi de Godwin dans les discussions: classer les opposants à un projet dans une catégorie revient à tomber dans le cliché du nazisme dans une discussion qui s'éternise et qui finit par lasser. Dans tous les cas, c'est l'incompréhension et la frustration qui gagnent.
Je ne dis pas que systemd répond à ce paradigme mais je retrouve dans les litanies d'opposition à systemd des arguments que j'ai moi-même observés depuis le début de ma carrière, bien avant qu'on parle de systemd. C'est suffisant pour moi à considérer que ceux qui s'opposent à ce projet ont probablement de bonnes raisons de le faire. Ceci ne signifie pas qu'il n'y a pas, dans le tas, de crétins sectaires et conservateurs mais ranger, improprement, tous les contestataires dans cette catégories est une grave erreur de jugement.
[^] # Re: Mwai
Posté par FantastIX . En réponse au journal Laisser systemd de côté dans Debian. Évalué à 7. Dernière modification le 29 novembre 2014 à 15:32.
J'aime bien cette phrase. J'ai fait le même constat.
Mais, plutôt que de me dire «l'informatique est devenue compliquée et il faut s'y faire», j'ai tenté de répondre à la question «pourquoi?»
Il n'y a pas qu'une seule réponse. Mais ce que j'ai constaté — et de plus en plus — c'est que les gens, dont les développeurs, ont de moins en moins la capacité à comprendre l'énoncé d'un problème et ont de moins en moins la capacité à résoudre un problème complexe autrement qu'en mettant en place des solutions compliquées (j'utilise complexe et compliquée à dessein). J'ai fait ce constat en observant les gens autour de moi (mais pas seulement), ainsi que les logiciels mis en place et en faisant bilan sur bilan tout au long de ma vie.
L'informatique est-elle donc plus compliquée? ou plus complexe?
Est-elle plus compliquée? Impossible de répondre sans généralisation excessive. Mais si elle est plus compliquée, c'est peut-être aussi parce que ceux qui sont derrière n'ont pas la capacité à trouver une solution logique et optimisée à un problème complexe. J'insiste sur le fait que «complexe» et «compliqué» ne sont pas inter-dépendants.
Est-elle plus complexe qu'avant? Certainement. Mais si c'est le cas, est-ce que cela justifie des solutions si compliquées, que seuls des experts de haut niveau soient à mêmes de les comprendre et de les maîtriser?
Parfois il est des problèmes qui ne doivent pas être résolus. Je veux dire par là que, lorsqu'on définit un projet, une limite claire et incontestée doit être tracée entre les problèmes inhérents au projets, c-à-d auxquels le projet lui-même fournit une solution et ceux qui sont hors-sujet. Or c'est précisément définir ce qui est hors-sujet la tâche la plus ardue et la tentation est grande. Vouloir résoudre des problèmes qui n'entrent pas dans le cadre du projet rend la solution finale non seulement complexe mais compliquée.
Pendant l'évolution d'un projet, grande est la tentation à ajouter des fonctionnalités. Mais avec l'ajout de fonctionnalités, si elle n'a pas été planifiée scrupuleusement depuis le début, il arrive que certaines d'entre elles remettent en cause la raison même de l'existence du projet. Ceci n'est qu'un exemple de ce que j'ai observé. Il en résulte des projets tentaculaires, des monstres voraces en ressources ou que sais-je encore.
Dans mon expérience personnelle, par exemple, j'ai rarement vu des projets qui prenaient en compte les aspects sociaux et humains. Il n'est pas rare d'entendre «C'est à l'utilisateur de s'adapter» ou «Il faut vivre avec son temps», qui vont à l'encontre des bases de l'analyse des systèmes d'information. Et ce sont des phrases de ce type qui sont invoquées lorsque des utilisateurs, réfractaires aux changements, provoquent la lassitude et l'agacement des intégrateurs. Et c'est cet agacement qui provoque l'erreur classique consistant, in fine, de guerre lasse, à appliquer cette sentence à tous ceux qui s'y opposent, fourrant dans le même sac opposants légitimes et crétins réfractaires-tout-court. On pourrait comparer cette situation à la loi de Godwin dans les discussions: classer les opposants à un projet dans une catégorie revient à tomber dans le cliché du nazisme dans une discussion qui s'éternise et qui finit par lasser. Dans tous les cas, c'est l'incompréhension et la frustration qui gagnent.
Je ne dis pas que systemd répond à ce paradigme mais je retrouve dans les litanies d'opposition à systemd des arguments que j'ai moi-même observés depuis le début de ma carrière, bien avant qu'on parle de systemd. C'est suffisant pour moi à considérer que ceux qui s'opposent à ce projet ont probablement de bonnes raisons de le faire. Ceci ne signifie pas qu'il n'y a pas, dans le tas, de crétins sectaires et conservateurs mais ranger, improprement, tous les contestataires dans cette catégories est une grave erreur de jugement.