Je ne vois pas pourquoi on prendrait le client pour un neuneu attardé en essayant de trouver un moyen de se comprendre mutuellement. Développer, c'est un métier, différent de celui du client. Alors autant faire chacun notre métier, proprement.
Pour vous donner un exemple, j'ai récemment monté un cours en M2 Bio-Informatique. Avoir des étudiants biologiste impose un gros décalage de vocabulaire ("système" en bio, c'est "cellule de foie porcine cancéreuse" par exemple). Le fait d'utiliser des modèles pour communiquer et UML comme langage intermédiaire nous a permis de mener à bien un projet de semestre assez costaud.
Être capable de communiquer avec d'autres personne que des informaticiens, c'est vital!! Après, UML à pleins de défaut, et lorsque le besoin s'en fait ressentir, on peut créer un langage spécifique a un domaine donné, pour régler le problème et être encore plus efficace.
Pour ta remarque sur "les torchons et les serviettes", ce n'est pas mon point de vue. On parle de deux métiers différents, au même niveau d'expertise. Mais pas du même métier. Prends la construction d'un pont, le viaduc de Millau par exemple. Il y à une différence très net entre les spécialistes "structures" qui s'occupent de garantir que le pont ne va pas s'écrouler des spécialistes "flux" qui regardent les flux de circulations alentours et planifient l'utilisation et le nombre de contraintes que va devoir supporter le pont. 2 expertises très différentes, exprimées dans des langages très différents (calculs de structures pour les uns, flots dans l'autre cas). Mais au final, on parle bien du même viaduc, qu'il faut vendre au conseil régional pour obtenir de nouvelles subventions. Comment faire sas une vision synthétique, de plus haut niveau, coordonant tous ces dev.? Est-ce plus clair avec cette métaphore? L'idée est que la réalité est constitué par de nombreux corps de métiers ou d'expertise, et qui'l faut bien arriver a faire en sorte que tout le monde se parle. et surtout se comprenne.
Et, pour finir, je citais Graham dans le sens où la plus-value d'un expert n'est pas dans l'ecriture d'un code "basique", mais dans les trucs tricky qui nécessitent justement son expertise. Encore une fois, pas le même métier. On a besoin de gens experimentés dans leur domaine pour écrire les générateurs de code par exemple. si jamais je devais définir une transformation vers une VM Lisp, je ferais surement appel à un expert pour obtenir une projection ayant du sens, et optimisée selon son experience.
C'est toujours le même décalage: on ne fait pas le même métier. Mais normalement, rien de grave là dedans. enfin à mon sens.
[^] # Re: Voilà une bonne nouvelle: plus besoin de programmeurs
Posté par Sébastien Mosser . En réponse à la dépêche Acceleo 2.7.0 est sorti !. Évalué à 4.
Pour vous donner un exemple, j'ai récemment monté un cours en M2 Bio-Informatique. Avoir des étudiants biologiste impose un gros décalage de vocabulaire ("système" en bio, c'est "cellule de foie porcine cancéreuse" par exemple). Le fait d'utiliser des modèles pour communiquer et UML comme langage intermédiaire nous a permis de mener à bien un projet de semestre assez costaud.
Être capable de communiquer avec d'autres personne que des informaticiens, c'est vital!! Après, UML à pleins de défaut, et lorsque le besoin s'en fait ressentir, on peut créer un langage spécifique a un domaine donné, pour régler le problème et être encore plus efficace.
Pour ta remarque sur "les torchons et les serviettes", ce n'est pas mon point de vue. On parle de deux métiers différents, au même niveau d'expertise. Mais pas du même métier. Prends la construction d'un pont, le viaduc de Millau par exemple. Il y à une différence très net entre les spécialistes "structures" qui s'occupent de garantir que le pont ne va pas s'écrouler des spécialistes "flux" qui regardent les flux de circulations alentours et planifient l'utilisation et le nombre de contraintes que va devoir supporter le pont. 2 expertises très différentes, exprimées dans des langages très différents (calculs de structures pour les uns, flots dans l'autre cas). Mais au final, on parle bien du même viaduc, qu'il faut vendre au conseil régional pour obtenir de nouvelles subventions. Comment faire sas une vision synthétique, de plus haut niveau, coordonant tous ces dev.? Est-ce plus clair avec cette métaphore? L'idée est que la réalité est constitué par de nombreux corps de métiers ou d'expertise, et qui'l faut bien arriver a faire en sorte que tout le monde se parle. et surtout se comprenne.
Et, pour finir, je citais Graham dans le sens où la plus-value d'un expert n'est pas dans l'ecriture d'un code "basique", mais dans les trucs tricky qui nécessitent justement son expertise. Encore une fois, pas le même métier. On a besoin de gens experimentés dans leur domaine pour écrire les générateurs de code par exemple. si jamais je devais définir une transformation vers une VM Lisp, je ferais surement appel à un expert pour obtenir une projection ayant du sens, et optimisée selon son experience.
C'est toujours le même décalage: on ne fait pas le même métier. Mais normalement, rien de grave là dedans. enfin à mon sens.