Plusieurs gens des ressources humaines, gestionnaires, utilisateurs, n'ont aucune idée de la complexité qui se cache derrière la programmation des ordinateurs. Ils croient qu'ils peuvent caser les programmeurs ça et là (d'une tâche à l'autre) et ils ne comprennent pas ce qu'ils font. Je vois souvent les gens des ressources humaines choisir leurs programmeurs en se basant sur le Langage (Syntaxe), et non pas sur ce qui compte vraiment. C'est comme engager un employé en se basant sur l'école où il a étudié plutôt que sur les sujets qu'il a étudiés!
Heureusement, cet article donnera aux non-programmeurs une meilleure idée de ce qu'est la programmation -- et ce qu'ils devraient considérer lors de l'embauche de programmeurs.
Il existe plusieurs langages programmation. Les non-programmeurs croient que le langage est important pour la programmation. C'est comme engager un mécanicien automobile américain pour faire des rénovations sur votre maison parce qu'il «parle la bonne langue.»
Un langage de programmation (comme le C, C++, Basic, FORTRAN) possède environ 50 commandes différentes (do-while, if-then-else, for, etc.) et environ 50 symboles qui définissent les actions (+, -, *, /, =, etc.). Environ 60% à 80% de ces symboles et commandes sont en communs avec les autres langages de programmation. La structure de base d'un langage a beaucoup plus en commun avec les autres langages (que de différences). Lorsque vous apprenez un langage, vous apprenez les concepts de la plupart d'entre eux -- même si les langages plus modernes (C++) sont plus complexes que les anciens (comme le FORTRAN). Tous les noms de commandes et les règles d'un langage de programmation sont connus collectivement comme la «Syntaxe» de ce langage.
La portée d'une syntaxe est faible. Un programmeur qui connaît un langage (par exemple le Basic ou le Pascal), peut programmer dans un nouveau langage en une journée ou deux (par exemple en FORTRAN ou en C). Pour être passablement bon avec ce nouveau langage, une ou deux semaines seront nécessaires (ils peuvent tout de même créer du code pendant cette période d'apprentissage). Chaque langage possède des particularités et des petites cachettes qui peuvent prendre un mois ou deux à maîtriser (avant qu'ils ne cessent de faire des erreurs qui leur coûtent un ou deux jours de travail) -- mais ils ne sont probablement que 10% à 20% moins productifs que ce qu'ils deviendront plus tard (en tant que programmeur moyen). S'ils deviennent des «gourous» d'un langage et qu'ils le connaissent de fond en comble (ce qui peut prendre plusieurs années), alors ils ne seront que 10% à 20% plus productifs qu'un programmeur moyen travaillant dans le même langage. (Les commandes de la syntaxe ne font pas une grosse différence en ce qui concerne la productivité). Pour utiliser pleinement une syntaxe, les «gourous» doivent écrire du code que les autres ne sont pas en mesure de maintenir -- parce qu'ils utilisent des excentricités et des artifices qui sont trop uniques pour un langage (la plupart des programmeurs «moyens» ne connaissent pas ces artifices). C'est mieux pour les experts de programmer comme s'ils n'étaient que des programmeurs «moyens» (alors la majorité de leurs pairs sera capable de comprendre et maintenir leur code) plutôt que de programmer comme des «experts».
Alors tout cela signifie que la maîtrise de la syntaxe des langages n'est pas ce qui importe. Fondamentalement la compréhension d'une syntaxe n'est qu'une affaire de jours ou de semaines. Les langages connus d'un programmeur sont peu révélateurs (comparativement aux autres défis d'un langage qui augmentent le temps d'apprentissage).
Une «routine» est un tout petit programme destinée à ne faire qu'une «chose», mais bien faite. Par exemple, dessiner une ligne ou un caractère à l'écran, ou encore afficher une image complète ou un menu, ou encore un millier d'autres fonctions. Un programme est constitué d'une grande quantité de routines (des milliers ou dizaines de milliers).
Une librairie est un ensemble de routines (toutes destinées à effectuer une tâche en commun). Ces librairies rendent les programmeurs plus productifs, parce qu'ils n'ont pas à ajouter toutes ces fonctionnalités à leur programme eux-mêmes. Plusieurs langages ont non seulement une syntaxe, mais en plus un ensemble de «librairies».
L'apprentissage de l'ensemble des librairies est souvent plus long que l'apprentissage de la syntaxe. Par exemple, le C est livré avec un ensemble de routines (librairie) pour la manipulation des chaînes de caractères (une chaîne de caractères est un regroupement de lettres, mots, phrases ou paragraphes). Ces routines (appelées Input/Ouput ou STDIO) peuvent manipuler des chaînes de caractères en des centaines de manières différentes, pour l'affichage à l'écran, la saisie au clavier, etc. Supposons que cette librairie, à elle seule, renferme 50 routines différentes, elles deviennent des «extensions» du langage; alors le programmeur (qui désire utiliser cette librairie) doit, non seulement apprendre le C, mais également cette librairie -- ce qui double la complexité du C, uniquement avec cette librairie. Des semaines sont nécessaires pour maîtriser cette librairie, et plusieurs autres librairies sont livrées avec le C, et d'autres encore s'ajoutent selon l'environnement de développement.
Les environnements de développement -- Les compagnies qui vendent des outils ajouteront très souvent des fonctionnalités (librairies) au langage pour ajouter de la valeur à leurs outils. Ainsi Microsoft a ses propres librairies pour leur version du C, de même pour Symantec, Metrowerks, Borland et les autres. Les librairies des environnements sont souvent «uniques» (mais semblables). Ces librairies conçues sur mesure (et les autres complexités des environnements) peuvent être aussi complexe que l'apprentissage d'une nouvelle syntaxe (incluant les librairies standards d'un langage). On parle ici de temps d'apprentissage mesuré en jours pour être capable de fonctionner dans l'environnement de développement et de semaines pour devenir productif.
De plus, les compagnies qui développent leurs propres programmes conçoivent leur propre ensemble de routines et de librairies. Ces librairies fabriquées sur mesure (uniques pour chaque compagnie ou application) et le reste du code spécifique à la compagnie, sont souvent plus complexe à apprendre (et de loin) qu'une nouvelle syntaxe. On parle ici de temps d'apprentissage mesuré en semaines pour être capable de se débrouiller et de mois pour devenir productif.
C'est beaucoup plus coûteux de former des programmeurs pour travailler sur ces librairies que de leur apprendre une syntaxe. Certains programmeurs ne travailleront jamais avec les «librairies standards» -- alors même s'ils sont des experts en C, ils ne sont qu'à mi-chemin dans leur apprentissage pour ce que vous voulez leur faire faire (si vous désirez qu'ils travaillent avec les librairies standards) -- et ils sont encore moins prêts si vous désirez leur apprendre les librairies de votre produit. Les librairies pèsent beaucoup plus dans la balance que les langages lorsque vient le temps d'engager des programmeurs -- cependant la majorité des gestionnaires et des gens des ressources humaines ne savent pas cela. Ce qui est le plus important pour les compagnies, ce N'EST PAS la syntaxe ou les librairies qu'un programmeur maîtrise, mais la qualité de ce programmeur en tant qu'individu (sa vitesse d'apprentissage), cela transparaît difficilement dans un curriculum vitae.
Disciplines / Spécialités Il existe également des champs d'expertise (ou disciplines) -- pensez aux spécialités en médecine. Le seul fait qu'un Docteur soit un bon médecin ne fait pas de lui un bon dentiste, chirurgien ou psychiatre. Ce sont tous des champs d'expertise (ou disciplines). Tout comme la médecine, l'informatique a elle aussi ses champs d'expertise.
Des disciplines telles que les réseaux et communications, les pilotes de périphériques, les bases de données, les graphiques, les interfaces homme-machine, etc. ont chacune des centaines (voir des milliers) de problèmes qui leur sont uniques. Le seul fait de connaître un langage ne signifie pas que vous serez en mesure de travailler dans une discipline quelconque. En réalité, la productivité d'une personne sera, et de loin, beaucoup plus affectée par la discipline ou le champ d'expertise, que par le langage ou même le système d'exploitation utilisés.
Malheureusement la majorité des gestionnaires et gens des ressources humaines ne savent pas cela. Pire encore, les hauts-gestionnaires voient les programmeurs comme des ressources génériques (ils peuvent en remplacer facilement une par une autre). Ils vont placer une personne travaillant sur les pilotes de périphériques (qui programme en assembleur) sur un problème d'interface homme-machine (programmé en C), et ils croient qu'ils obtiendront de bons résultats -- ces mêmes personnes ne se risqueraient pas à troquer leur médecin pour un vétérinaire.
Un système d'exploitation (OS) (comme le MacOS, Unix ou Windows) possède plusieurs (des douzaines) de librairies complexes, chaque librairie pouvant avoir des centaines de procédures (également appelées des fonctions) et des douzaines de structures de données. Ces librairies de systèmes d'exploitation (appelées API) sont de loin beaucoup plus complexes (prises individuellement) que les librairies des langages, et elles sont très nombreuses. Elles sont souvent regroupées selon une spécialité ou un problème qu'elles permettent de résoudre (et ils existent des tas de ces spécialités).
On m'a déjà dit qu'un OS comme le MacOS ou Windows renfermait de 15,000 à 30,000 routines différentes pouvant être utilisées. Pensez-y un instant, comparez cela à une librairie standard de langage (quelques centaines de routines) ou à une syntaxe (50 commandes) pour avoir une bonne idée du problème. Certaines compagnies vont mettre un programmeur Windows à la place d'un programmeur Macintosh -- parce que les programmeurs Mac disponibles ne connaissent pas la syntaxe (langage) qu'ils ont besoin. Si ça vous parait insensé, ne vous en faites pas, le monde des affaires l'est souvent.
Il existe plusieurs similarités entre les OS. (Les premiers Windows possédaient une architecture empruntée au Mac). Mais le temps d'apprentissage de toute la complexité des différents OS se mesure en mois ou en années, sans compter tous les comportements «spéciaux» qu'un programme peut avoir dans un OS donné. Si un programmeur change de plate-forme (OS), mais demeure dans son champ d'expertise, il pourra faire le saut sans trop de problèmes (puisque les similarités entre les champs d'expertise sont plus grandes que les différences entre les plates-formes). Mais si vous déplacez un programmeur général, pour travailler sur un programme complexe, vers une autre plate-forme, ça peut prendre des semaines, sinon des mois avant qu'il ne devienne vraiment productif -- le grand nombre de librairies (et routines) qu'il a besoin d'apprendre peut être écrasant, sans oublier tous les petites particularités spécifiques à une plate-forme.
Il y a deux manières totalement différentes de penser en programmation. L'une s'appelle la programmation procédurale et l'autre la programmation orientée-objets (OOP ou OOD pour Object Oriented Design, conception orientée-objets). Ce sont là deux paradigmes (façon de penser) complètement différents.
Les programmeurs OOD peuvent habituellement faire de la programmation procédural sans problème -- cependant l'opposé n'est pas vrai. La plupart des programmeurs procéduraux qui débutent dans l'utilisation d'un langage orientée-objets, ont tendance à programmer de l'ancienne manière -- ce qui donne un code objets très mauvais (qui doit être jeté et réécrit). Des mois (même des années) sont nécessaires aux programmeurs procéduraux pour être en mesure de penser en «objets».
L'expérience dans l'utilisation d'un langage orienté-objets ne garantie pas qu'un programmeur comprend l'OOD/OOP. Le C++ et Java sont des langages orientés-objets -- mais rappelez-vous, les programmeurs n'ont pas à penser en OOD pour programmer avec ces syntaxes (ils doivent penser ainsi pour les programmer correctement).
Le C++ n'est fondamentalement que le langage C avec des extensions pour l'objet (afin de le rendre plus orienté-objets). C'est un compromis de syntaxe paresseux, qui permet non seulement les erreurs de conception, mais les encourage. Smalltalk, ObjectiveC et Java sont beaucoup plus orientés-objets (et plus simples). Plusieurs programmeurs en C n'utilisent le C++ qu'en tant que version améliorée du C, plutôt que comme une version orientée-objets du C. Ces gens diront qu'ils connaissent le C++ parce qu'ils utilisent sa syntaxe, mais en réalité plusieurs d'entre eux ne comprennent pas le concept orienté-objets.
Alors le seul fait qu'une personne mentionne le C++ dans son curriculum vitae ne signifie pas du tout qu'elle comprend le concept orienté-objets. Une personne qui connaît bien ce concept peut s'en rendre compte en posant quelques questions : qu'est-ce que le polymorphisme, l'encapsulation, l'héritage, le camouflage des données ? Si un programmeur C++ ou Java ne peut expliquer ces concepts, alors ils ne sont que des programmeurs procéduraux qui utilisent une «nouvelle» syntaxe (et non des programmeurs orientés-objets). Dans certains cas le passé d'un programmeur est suffisant pour savoir s'il connaît le concept OOD ou non. S'il a fait dix ans de programmation procédurale (C, Pascal, FORTRAN, etc.) et 6 mois de Java ou C++, j'ai des doutes quant à sa connaissance de la programmation orientée-objets. S'il utilise depuis longtemps des langages OOP (Pascal Objet, C++, Smalltalk, etc.), les chances sont bonnes pour qu'il maîtrise bien ce concept.
Les Frameworks ne sont fondamentalement que des librairies orientées-objets. Le code (procédures) est groupé en objets (dans l'OOP) -- et les ensembles d'objets sont regroupés en Frameworks. Ces Frameworks représentent souvent des squelettes de programmes fonctionnels, et tous ce qu'un programmeur a besoin de faire, c'est d'ajouter quelques fonctionnalités pour obtenir une application complète. (Plutôt que d'écrire un programme, ils n'ont qu'à modifier un programme existant pour qu'il fonctionne de la manière désirée). Les Frameworks (et les autres outils) rendent un programmeur beaucoup plus productif que l'ancienne programmation procédurale. Voilà pourquoi l'OOP/OOD est un concept si important.
Le hic c'est qu'un Framework peut contenir des centaines de classes, celles-ci possédant des douzaines de méthodes (fonctions). Ainsi l'apprentissage d'un Framework peut être aussi complexe que l'apprentissage d'un nouveau programme sur un tout nouveau système (et plus encore s'ils n'ont jamais travaillé avec des Frameworks ou faits de la programmation orientée-objets).
Les non-programmeurs ne comprennent pas cette complexité -- alors ils n'ont pas conscience du temps d'apprentissage (ou du surplus de travail) associé à la maîtrise d'un Framework. MFC, MacApp, OWL de Borland et PowerPlant sont tous des Frameworks. Si certains ont déjà programmé dans un Framework, alors le changement vers un autre Framework n'est pas si difficile (quelques semaines d'effort) -- et plus spécifiquement dans certains cas précis (par exemple, OWL et MFC ont emprunté leur architecture de MacApp). Mais si certains n'ont jamais programmé dans un Framework, alors des mois peuvent être nécessaires avant d'être efficace.
Imaginez un Framework qui vous permettrait de n'écrire qu'une seule fois un programme, et de le distribuer sur plusieurs plates-formes. Ce Framework serait une énorme librairie située entre les programmeurs et les systèmes d'exploitation (au milieu, d'où le terme Middle dans Middleware), et disponible sur plusieurs plates-formes -- afin que le code puisse être déménagé d'une plate-forme à l'autre au besoin. C'est ce qu'on appelle middleware, Java et OpenStep (le YellowBox d'Apple) sont des middleware (1).
(1) Le terme middleware est également utilisé dans la terminologie des bases de données -- il représente les multiples sections qu'ont certaines bases de données -- le mariage entre les sections s'appelle middleware. Ce terme est spécifique dans certaines spécialités (comme les bases de données) et sera probablement (heureusement) écrasé par une signification plus large (signifiant un logiciel ou pseudo OS qui se situe entre le programmeur et le système d'exploitation).
L'apprentissage du Java, en ce qui concerne la syntaxe, est un projet d'une fin de semaine pour la majorité des programmeurs. C'est très facile, plus encore si vous connaissez déjà un autre langage de programmation orienté-objets (comme le C++). Mais le C++ n'est qu'un langage possédant peu de librairies ou Framework -- le Java a un ensemble riche et complexe de Frameworks. Java est un langage plus simple que le C++ (c'est donc plus facile d'écrire du code Java et il y a de loin beaucoup moins d'erreurs). Cela accroîtra la productivité. Mais les grosses librairies de Java le rendent plus long à maîtriser (ce n'est pas difficile, ça prend plus de temps). Les différentes versions de Java (1.0, 1.1, 1.2) ont toutes des Frameworks différents, et il y a des Frameworks additionnels (AWT, JFC, AFC, etc.) qui ajoutent des fonctionnalités aux fonctionnalités intrinsèques à Java (et les autres Frameworks). Il existe également des Frameworks commerciaux qui ajoutent des fonctionnalités à Java. Finalement il existe une multitude de possibilités pour vous (compagnie ou individu) pour ajouter vos propres petits Frameworks à Java, et les faire coopérer avec les autres Frameworks (c'est ce qu'on appelle JavaBeans). Toutes ces possibilités rendront les programmeurs beaucoup plus productifs qu'aujourd'hui par l'utilisation du Java (comparativement au C++ et les autres langages) -- et il y aura plusieurs Frameworks communs pour le Java.
Le côté peu reluisant de tous ces Frameworks de Java, c'est que les programmeurs ont un tas de choses à apprendre. En fait, l'apprentissage du Java sera aussi complexe que l'était celle d'un tout nouveau système d'exploitation dans la passé (avec une toute nouvelle syntaxe). Cela signifie également que Java aura la pente d'apprentissage la plus abrupte de tous les langages. 90% des gens qui disent connaître le Java aujourd'hui, ne connaissent en réalité que la syntaxe, et non tous les Frameworks. Enfin, les compagnies ajouteront leurs propres librairies et plusieurs tierces-parties ajouteront leurs fonctionnalités, ce qui augmentera encore le temps d'apprentissage.
Le bon côté, c'est qu'une fois le Java maîtrisé (avec les Frameworks), vous pouvez créer des programmes qui peuvent tourner sur n'importe quelle plate-forme. Toutes ces librairies signifient qu'il y a des tonnes et des tonnes de choses que les programmeurs n'ont pas à écrire -- ils n'ont qu'à se connecter à ces librairies, ajouter un peu de code «collant» (pour permettre à ces librairies de fonctionner avec leurs programmes) et voilà -- une méga-application instantanée.
OpenStep n'est qu'un Framework (middleware) spécialisé qui permettra aux programmeur qu'ils l'utiliseront d'écrire à la fois pour le Mac et Windows (et probablement sur le Sun, les gros systèmes d'IBM et d'autres plates-formes dans le futur, c'est à voir). Ce qui est intéressant, c'est qu'OpenStep permet aux programmeurs d'écrire en Java -- alors c'est fondamentalement un Framework (une librairie géante de routines), qui agit comme une extension de Java (mais uniquement sur les plates-formes supportées par le YellowBox/OpenStep). Ce Framework OpenStep est actuellement plus riche et plus rapide que tout autre Framework Java (pour l'instant). Ainsi Apple a une opportunité de marier Java et OpenStep -- mais ils devront le faire avec des alliances, on risque d'attendre longtemps.
J'espère avoir bien expliqué la complexité reliée à l'embauche des programmeurs (et ce que les programmeurs doivent savoir).
La syntaxe n'a que peu d'importance -- malgré toute l'attention que leur porte les gens des ressources humaines et les gestionnaires. Les programmeurs peuvent maîtriser une syntaxe en très peu de temps (un jour, ce qui a peu de valeur). Ce qui prend beaucoup de temps (et d'argent) c'est la maîtrise d'un système, d'une spécialité ou d'un Framework -- ou une toute nouvelle méthodologie ou paradigme (comme la programmation orientée-objets).
L'habileté d'un programmeur d'apprendre et de s'adapter est de loin plus important pour une compagnie que les syntaxes qu'il connaît. Une compagnie devrait s'intéresser aux syntaxes, uniquement si elle recherche un consultant à court terme.
Java est un langage et un ensemble de Frameworks, qui se dit être LE langage multi plates-formes, ainsi lorsqu'un programmeur le connaît, il n'a pas à connaître les spécificités d'un système d'exploitation en particulier (et les applications tournent sur toutes les plates-formes).
Si vous comprenez ces concepts, alors vous en savez plus que la majorité des gens des ressources humaines avec lesquels j'ai travaillé.