Tu ne parles pas non plus du principal souci, à savoir les divers facteurs humains, en estimant que c'est évident de décider qu'un projet est "over engineeré". Les gens sont rarement d'accord sur le sujet et y a plusieurs raisons pour ça.
Par exemple, les gens vont avoir tendance à sur estimer leur capacité (effet dunning kruger), et donc à voir de l'over enginering la ou il y a juste de leur part un manque de compréhension.
Ou voir du coté des choses qu'on a à peine commencé à explorer, comme l'effet Ikea (https://en.wikipedia.org/wiki/IKEA_effect), et comment les gens vont préférer ce qu'ils ont montés et dans lequel ils ont investis du temps.
De surcroit, tu ne parles pas du fait que tout le monde n'a pas forcément la même idée de ce qui doit être fait, en partie parce que les spécifications sont souvent flous, et changeantes, et que certaines personnes vont avoir le sentiment qu'on va vouloir faire d'autres choses plus tard et qu'il faut prendre ça en compte
Exemple, je déploie un site statique. Je fait un script de 5 lignes qui buildent tout. Parfait. Ensuite, on veut refaire ça. Du coup, mon script commence à avoir des paramétres, et je fait un role ansible pour déployer. Et puis, on commence à utiliser parfois des submodules, et parfois pas. Etc. Résultat, maintenant, mon script fait 243 lignes.
Pour le cas de base, il est clairement trop complexe. Pour tout les cas de bases des autres sites, il est pas encore suffisant, vu que les demandes ont évolués, et que je me retrouve à refactoriser les demandes dans 1 script.
Et pourtant, je pense pas que ça soit de l'over engineering, par rapport à l'alternative d'avoir 15 scripts presque semblables, voir pire, un logiciel pour produire les 15 scripts simples.
Et tu dit qu'un logiciel compliqué ne va pas avoir de contributions, mais c'est non évident. Au contraire, si le logiciel ne réponds pas aux besoins, il ne va pas attirer des gens pour s'en occuper.
Prends par exemple apache. Le système de module le rends plus complexe qu'un logiciel sans le même système. Mais pourtant, c'est ce qui permet d'avoir des contributions externes.
Donc non, l'over engineering, c'est comme la sécurité, c'est pas un état binaire, ça dépend des besoins qui doivent être précisés.
# Un chouia simpliste ?
Posté par Misc (site web personnel) . En réponse au journal Lutter contre l'overengineering. Évalué à 10.
Tu ne parles pas non plus du principal souci, à savoir les divers facteurs humains, en estimant que c'est évident de décider qu'un projet est "over engineeré". Les gens sont rarement d'accord sur le sujet et y a plusieurs raisons pour ça.
Par exemple, les gens vont avoir tendance à sur estimer leur capacité (effet dunning kruger), et donc à voir de l'over enginering la ou il y a juste de leur part un manque de compréhension.
Ou voir du coté des choses qu'on a à peine commencé à explorer, comme l'effet Ikea (https://en.wikipedia.org/wiki/IKEA_effect), et comment les gens vont préférer ce qu'ils ont montés et dans lequel ils ont investis du temps.
De surcroit, tu ne parles pas du fait que tout le monde n'a pas forcément la même idée de ce qui doit être fait, en partie parce que les spécifications sont souvent flous, et changeantes, et que certaines personnes vont avoir le sentiment qu'on va vouloir faire d'autres choses plus tard et qu'il faut prendre ça en compte
Exemple, je déploie un site statique. Je fait un script de 5 lignes qui buildent tout. Parfait. Ensuite, on veut refaire ça. Du coup, mon script commence à avoir des paramétres, et je fait un role ansible pour déployer. Et puis, on commence à utiliser parfois des submodules, et parfois pas. Etc. Résultat, maintenant, mon script fait 243 lignes.
Pour le cas de base, il est clairement trop complexe. Pour tout les cas de bases des autres sites, il est pas encore suffisant, vu que les demandes ont évolués, et que je me retrouve à refactoriser les demandes dans 1 script.
Et pourtant, je pense pas que ça soit de l'over engineering, par rapport à l'alternative d'avoir 15 scripts presque semblables, voir pire, un logiciel pour produire les 15 scripts simples.
Et tu dit qu'un logiciel compliqué ne va pas avoir de contributions, mais c'est non évident. Au contraire, si le logiciel ne réponds pas aux besoins, il ne va pas attirer des gens pour s'en occuper.
Prends par exemple apache. Le système de module le rends plus complexe qu'un logiciel sans le même système. Mais pourtant, c'est ce qui permet d'avoir des contributions externes.
Donc non, l'over engineering, c'est comme la sécurité, c'est pas un état binaire, ça dépend des besoins qui doivent être précisés.