Ce qui me fait flipper dans ce débat, c'est votre absence de recul absolument affligeant. Effectivement, quand on passe sa vie a écrire du code la tête dans le guidon, une démarche MDA, ca sert à rien.
Mais quand on travaille dans la vraie vie, on se rend compte rapidement:
a) que les gens qui prennent des décisions ne comprenne foutrement rien à du code. Ils VEULENT des "boiboites" pour monter en abstraction et comprendre ce qui se passe dans la technique. Donc vu qu'on est obligé de les avoir les boiboites, autant les opérationaliser
b) qu'il y à une énorme différence entre maitrise d'œuvre et maitrise d'ouvrage. Écrire du code, c'est un métier. Écrire du joli code, c'est presque un autre métier. Mais cela "reste" de la maitrise d'œuvre. Et il devient très difficile ne ne pas tenir compte du phénomène d'outsourcing. Graham disait (je paraphrase affreusement, mais je ne retrouve plus mon bookmark avec la source) "apprenez Java, et vous serez comme les 20.000 indiens qui candidate chez moi. Apprenez Lisp en plus de Java, pensez différemment, et je vous engagerais". C'est un peu le même principe. Il y à une forte tendance dans le marché actuel pour de la maitrise d'ouvrage (gestion de projet, gestion d'équipes, conduite de projet, gouvernance technique ...). Pour la maitrise d'œuvre, très peu de grands comptes embauchent encore en interne. La plupart externalise (que ce soit via des consultants ou de l'out-sourcing).
c) Avez vous simplement entendu parler de ligne de produit ou d'usines logicielle? Tant qu'on se contente de se construire des outils "dans son coin", où qu'on utilise comme gouvernant des personnes aux compétences techniques, la maitrise du code est suffisante. Mais pour les autres cas (qui sont beaucoup plus nombreux que vous semblez le croire), vous ne pouvez pas vous permettre de "bricoler", car vous devez :
- démontrer a la direction que ce machin va se vendre
- démontrer au marketing qu'on pourra l'adapter facilement au client
- démontrer à vos différents sous-projet l'avancée globale du produit.
Bref ... on parle ici d'"ingénierie du logiciel", pas de développement. Pensez à une compagnie qui vend un back-end de réservation de voyage. au niveau modèle, quel que soit l'agence de voyage qui vous achète le système, c'est "presque" pareil. Toute la valeur ajoutée est dans l'adaptation de votre système a votre client, tant au niveau front-end (site web, ...) que dans le back-end (compagnies partenaires, accord hôtels / loueurs de voiture pour construire des 'packs', ...).
Alors autant on apprécie l'expérience d'experts en développement (qui sont d'ailleurs utilisé pour écrire les transformations), autant votre réaction tombe juste "a coté": Ce n'est pas le même métier. alors si on vous laisse faire le votre, laissez nous faire le notre.
[^] # 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é à 8.
Mais quand on travaille dans la vraie vie, on se rend compte rapidement:
a) que les gens qui prennent des décisions ne comprenne foutrement rien à du code. Ils VEULENT des "boiboites" pour monter en abstraction et comprendre ce qui se passe dans la technique. Donc vu qu'on est obligé de les avoir les boiboites, autant les opérationaliser
b) qu'il y à une énorme différence entre maitrise d'œuvre et maitrise d'ouvrage. Écrire du code, c'est un métier. Écrire du joli code, c'est presque un autre métier. Mais cela "reste" de la maitrise d'œuvre. Et il devient très difficile ne ne pas tenir compte du phénomène d'outsourcing. Graham disait (je paraphrase affreusement, mais je ne retrouve plus mon bookmark avec la source) "apprenez Java, et vous serez comme les 20.000 indiens qui candidate chez moi. Apprenez Lisp en plus de Java, pensez différemment, et je vous engagerais". C'est un peu le même principe. Il y à une forte tendance dans le marché actuel pour de la maitrise d'ouvrage (gestion de projet, gestion d'équipes, conduite de projet, gouvernance technique ...). Pour la maitrise d'œuvre, très peu de grands comptes embauchent encore en interne. La plupart externalise (que ce soit via des consultants ou de l'out-sourcing).
c) Avez vous simplement entendu parler de ligne de produit ou d'usines logicielle? Tant qu'on se contente de se construire des outils "dans son coin", où qu'on utilise comme gouvernant des personnes aux compétences techniques, la maitrise du code est suffisante. Mais pour les autres cas (qui sont beaucoup plus nombreux que vous semblez le croire), vous ne pouvez pas vous permettre de "bricoler", car vous devez :
- démontrer a la direction que ce machin va se vendre
- démontrer au marketing qu'on pourra l'adapter facilement au client
- démontrer à vos différents sous-projet l'avancée globale du produit.
Bref ... on parle ici d'"ingénierie du logiciel", pas de développement. Pensez à une compagnie qui vend un back-end de réservation de voyage. au niveau modèle, quel que soit l'agence de voyage qui vous achète le système, c'est "presque" pareil. Toute la valeur ajoutée est dans l'adaptation de votre système a votre client, tant au niveau front-end (site web, ...) que dans le back-end (compagnies partenaires, accord hôtels / loueurs de voiture pour construire des 'packs', ...).
Alors autant on apprécie l'expérience d'experts en développement (qui sont d'ailleurs utilisé pour écrire les transformations), autant votre réaction tombe juste "a coté": Ce n'est pas le même métier. alors si on vous laisse faire le votre, laissez nous faire le notre.