Programmer: de la création ou un job d'usine?
Written by Fneuch on 22.1.07Hier soir, je discutait avec un compétiteur (un bon gars d'une autre firme qui fut jadis sous ma responsabilité quand j'étais au ministère)!
Lorsqu'à un moment donné la conversation bifurque et on se met à discuter sur la dichotomie de la vision des directeurs en informatique et celle des personnes sur le terrain, les fameux programmeurs! (Je suis avant tout programmeur, ne le prenez pas mal.)
Mon interlocuteur me dit au sujet des directeurs :
leur jobs c'est de parler et d'essayer de protéger leur "savoir-faire" à tout prix... Je crois qu'ils n'ont pas encore compris le pouvoir du réseau et des gens qui collaborent ensembles pour produire du code de qualité. Ils pensent encore que la production de code c'est comme la manufacture certain ne comprendrons peut-être jamais la différence a moins qu'ils aient produit du code.
Produire du code est un exercice purement créatif et on ne peut pas le gérer comme un usine pour fabriquer des chaussures ou des canapés.
Et il a raison sur plusieurs points. Effectivement, il n'est pas donné à tous les directeurs de comprendre le domaine informatique. Qu'il est important le pouvoir du réseau afin de faire évoluer de façon vertigineuse les applications produites de nos jours. Et il a un peu raison tant qu'à moi, la production de code n'est pas une manufacture!
Vous vous en doutez un peu, là ou je me dissocie c'est la phrase que j'ai mis en gras. J'avais un collègue (le fameux Alex) qui tenait le même discours à la virgule près... (S'il me lit présentement, il va commencer à grincer des dents pour la suite, salut Alex!) Et comme je vous ai dit, je suis à peu près d'accord sur le concept que la programmation au sens large du terme fait partie d'un processus de création... Mais où je ne suis pas d'accord, c'est que la programmation, dans le sens de produire du code, N'EST PAS un processus purement créatif.
Je ne dit pas qu'il y a une recette miracle... Ne montez pas sur vos grand chevaux! Je ne dit pas, comme pensent plusieurs, que la création d'un système informatique devrait être simple et qu'on peut tout réutiliser, tout définir en composant qui fait que tu réutilise la même poutine à chaque application.
Néanmoins, si on considère que la création d'un système informatique est de représenter et exploiter un domaine d'affaire existant (connu par le client), 2 applications bien conçues devraient abordées des règles et des traitements de façon similaire. On ne crée donc pas, on concrétise un concept du client.
Si on considère aussi le fait que normalement, toute entreprise devrait avoir ses règles d'identification visuel qui permettent d'harmoniser l'interface des applications, de favoriser l'apprentissage aux employés, de visualiser plus rapidement les changements apportés aux processus représentés par le système. Est-ce qu'on peut dire qu'on crée une interface pour un système ou si on affiche simplement de façon standard le domaine d'affaire du client?
Et s'y on ajoute à cela l'idee que le processus de persistance des données (les sauvegarder dans une BD par exemple) existe depuis que l'informatique existe, nous n'avons donc rien à y creer.
Je peux comprendre qu'un gestionnaire s'attendent à ce que la créativité soit au minimum puisque dans les trois "layers" (je hais utiliser le terme couche pour parler de la séparation persistance/règle affaire/affichage, trop confondu, très galvaudé) d'une application nous avons des choses qui sont déjà définis et par le fait même devrait être réutilisable ou devrait donner toujours le même résultat, un peu comme dans un moule...
Si en plus on connait l'existence des designs/patterns, des framework, des gestionnaire de sources open source (beaucoup de code existe déjà, cherché), etc. La création ne se situe pas vraiment du cote de la programmation, mais plus du point de vue architecturale du système... Et c'est la le gros problème, on passe trop vite d'une notion de fonctionnel a une notion de réalisation...
Je n'ai jamais fait partit d'un processus de création d'une voiture, mais de ce que j'en connais, ce processus est le même que la création d'un système informatique. Le dessinateur en fait un draft (une image, un beau dessin), un responsable dit tout ce qu'il veut que la voiture aie ou fasse (lecteur CD, 9 litres au 100 km, etc), bref tout ce qui est fonctionnel... Pensez-vous que le tout ce dirige directement à l'usine? Jamais! La voiture passe des mois sur la planche a dessins d'un ingenieur/architecte qui va tout déterminer jusqu'au boulon près...Une fois que lui a terminé, là tu peux envoyer la voiture sur la chaine de montage et elle va toujours avoir le même résultat!
À cela, mon interlocuteur me répond que c'est différent en programmation car le processus de création et de production de l'application est le même, ce qui complexifie les choses pour les gens habitués à avoir un processus formel et rigide... Ok, peut-être, je ne suis pas à 100% d'accord avec cela, mais je doit l'avoué qu'il est rare qu'on veulent faire la même application plus d'une fois comme dans une usine! Donc oui, de ce point de vue mon exemple n'était pas bon...
J'enchaine donc dans la discussion en lui signifiant qu'il avait raison dans un sens, mais la créativité en programmation, on ne peut peux pas la laisser à n'importe qui. On ne peux pas laisser tous les programmeurs d'un même projet avoir leur «trippe» de création indépendamment l'un de l'autre, ton projet va être le bordel... Imaginez-vous si vous laisser les programmeurs faire leurs classes comme ils veulent, leurs paquetages comme ils l'entendent, et implémentent le framework de leur choix... Oubliez ça, votre application sera un bordel! On ne peut donc pas affirmer que la programmation est un processus de création!
Prenons donc un autre exemple pour démontrer mon point de vue!
Imaginez un spectacle par exemple (domaine artistique donc très créatif), il n'y a qu'une ou 2 personnes responsables de la créations, de la mise en scène de la pièce. Si vous n'êtes que le pauvre petit artiste, la seule chose que t'as le droit, c'est de donner ton opinion quand c'est le temps. Pis encore là, ça depend du réalisateur, c'est pas tous les metteurs en scènes et auteurs qui l'acceptent! Et pourtant, ce sont tous des artistes, des représentants du monde de la création...
C'est ce que je veux dire, la programmation c'est pas une notion de création! La production d'un système informatique est un processus de création, pas la programmation! Et d'un point de vue organique, il n'y a qu'un ou 2 metteurs en scène/auteur/designer industrielle, appelle le comme vous voulez, le concept est le même... Il y en a un qui pensent et qui "créer" le système: ses balises (ou commencent et finit le système), sa représentation du domaine d'affaire, sa vision des besoins fonctionnels, son idée de solution aux problèmes complexes qui ont été identifié lors de l'analyse, etc.
Bref, c'est lui le maitre d'oeuvre organique/technique (prenez le comme vous voulez). Ensuite lorsqu'il délègue pour la réalisation, l'ouvrier (dans le cas d'une manufacture), l'artiste (dans le cas d'une pièce de théâtre ou d'un film) ou le programmeur (dans le cas d'un système informatique) doit le réaliser...
Pas tout a fait comme un automate, parce qu'en soit, a partir de ce moment, le maitre d'œuvre fait de la gestion de personnelle: il doit prendre leurs idées, leurs commentaires, leurs expériences et orchestrer le tout dans le but de faire un produit qui correspond à ce que veux avoir le client-payeur... Et prenez le de toute les façons que vous voulez, une fois que la création est faite par le maitre d'œuvre, si celui-ci décide que l'ouvrier/artiste/programmeur n'a pas son mot à dire, c'est plate mais c'est ça... (Inquiétez-vous pas c'est pas mon style... lol)
Il est vrai qu'entre chaque auto, il y a des différences, entre chaque pièce de théâtre ou film, il y a des différences, et qu'entre chaque système informatique, il y a des différences, mais dans tous les cas, le processus de création est toujours le même. (différent d'un domaine à l'autre, mais toujours le même par domaine). Quand on fait un film, ça prends toujours un auteur pour le script qui écrit une introduction, une intrigue et une conclusion, un réalisateur et un ou des artistes pour le faire. Dans la création d'un auto, ça prends le dessin du concept, la conception de l'ingénieur et la réalisation par les ouvrier... En informatique, ça fonctionne aussi sauf que techniquement, on part de quelque choses d'existant, de connu : le domaine d'affaire de l'utilisateur!
Même dans les films ils récupèrent... Ils reprennent des idées qui ont déjà été inventé et les adaptes au gout du jours, les améliorent et font de l'argent avec. Tout a été vu et inventé déjà, ou est le concept de création? (Je ne parle pas de ceux qui sont en recherche...)
Mon interlocuteur m'interpelle donc (pauvre lui, j'y laisse pas beaucoup le temps de parler, christy que je suis mémère) en me disant qu'il est d'accord avec 90% de ce que je veux dire, mais soulève quelques points que je doit lui donné. Nous avons beaucoup de convention et de structure pour augmenter le niveau de faciliter du programmeur, pour l'aider dans la création. Et par la suite me pose une question :
la définition d'algorithme revient a qui? Au gestionnaire ou alors au programmeur?
Et bien ma réponse est la suivante : ça dépend du niveau d'algorithme...
Laisseriez-vous le soins aux programmeurs d'implémenter un algorithme de calcul de la température en fonction du facteur vent/humidex/beton/etc? Non, ce genre d'algorithme fait partie du domaine d'affaire, donc du client!
Laisseriez-vous aux programmeurs le soins de définir l'algorithme de construction à utiliser pour la création des objets primordiales du domaine d'affaire (le design pattern builder ou factory)? Non, ça ça fait partie de la job de l'architecte parce que ça à un impacte sur la conception du système, en fonction du mécanisme de déploiement/persistance/de l'utilisation d'une technologie ou d'une autre (EJB, JSF, Hibernate, BC4J, etc) etc.
Laisseriez-vous la création d'un algorithme pour la validation d'une règle d'affaire unitaire? Fort probablement...
Le concept est : Laisseriez-vous a un acteur le loisir de choisir l'émotion qu'incarne le personnage qu'il joue pour toutes les répliques? Non, si le texte qu'a écris l'auteur implique que tu dois tuer quelqu'un, je suis pas sure qu'il va accepter que tu dises je vais te tuer en riant...
Voilà ou je ne suis pas d'accord avec l'idée que de la programmation c'est de la création pure... Je ne dit pas qu'il n'y a pas de création! Loin de là, sauf que la création se limite à certaines personnes.
Je laisserais plus de latitude a un programmeur sénior et expérimenter qu'a un junior au même titre que si nous étions réalisateur nous écouterions probablement plus Tom Hanks quand il nous suggère une émotion pour une réplique que Pierre-Jean Jacques qui en est à ses débuts au grand écran. Et c'est normale!
Pauvre transmeta (mon interlocuteur), je ne lui ai pas beaucoup le loisir de s'exprimer hier soir. Je vous ai fait un résumé de notre conversation, imaginez le temps que ça nous a pris en lisant le billet... lol, je suis volubile désolé. Après ça, il était l'heure de se mettre au lit.
Je lui ai donc demandé l'autorisation de publié le tout ici, de cette façon, il aurait amplement le loisir de justifier son point de vue que j'ai hate de lire!
Et vous, qu'en pensez-vous? est-ce que la programmation est un processus de création pure? Où si vous pensez comme moi qu'un programmeur est comme un acteur? Quelqu'un qui traduit dans un langage différent (parler français ou parler java, c'est parler!) ce que lui dit le réalisateur afin de mettre au grand écran le meilleur système en informatique de l'année, le système qui va faire courir les foules et qui va faire plaisir au bailleur de fonds (le client).
J'ai hâte de lire vos commentaires!
