Home Home Posts Rants about IT DevOps Stuff I'm working on

Faut-il embaucher un développeur inexpérimenté ?

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
115
articles
February 17, 2012

Lorsqu’on est attentif à ce qui se dit dans les communautés comme les sites de Stack Exchange, ou encore par les leaders, tels que Joel Spolky, en matière de l’organisation du travail au sein des entreprises de développement, on entend se répéter l’un des points clés en matière d’embauche : il est impératif d’avoir les salariés les plus compétents, dans la limite des capacités financières de l’entreprise.

Ceci est vrai dans le sens où une entreprise de développement qui constamment cherche à avoir les développeurs les moins coûteux en se disant que c’est un moyen de réduire les coûts se met le doigt dans l’œil : non seulement ses produits seront d’une qualité désastreuse, et il faudra être très audacieux pour convaincre, souvent par tromperie, les clients de payer pour ça, mais aussi ces développeurs vont coûter actuellement plus cher à long terme.

Ce dernier point est relativement simple à expliquer. Au cours de sa carrière, un développeur intéressée va croître très fortement à la fois ses compétences et, pas sans lien, sa productivité. Il apprend à utiliser de nouveaux outils (ou des outils qu’il connaissait depuis le début mais dont il ne pouvait s’en servir efficacement, faute de maîtrise), il apprend les patterns qu’il applique, il respecte les règles de style, permettant à son code d’être relu plus facilement, il applique les méthodologies permettant de rendre son code plus sûr, il fait le refactoring régulier, etc. Parallèlement, son salaire augmente, mais à une vitesse moindre.

Donnez à un développeur débutant une tâche compliquée qu’un professionnel pourra accomplir en cinq heures. Ce développeur débutant restera dessus pendant des jours, voire des semaines, pour au final aboutir à une solution d’une qualité fortement inférieure, qui nécessitera des semaines supplémentaires pour le QA ou les développeurs qui seront amenés à travailler sur ce code par la suite. Cependant, ce développeur débutant est payé peut-être seulement deux fois moins que le professionnel.

Ainsi, un développeur inexpérimenté est plus coûteux qu’un professionnel lorsqu’il s’agit de travailler sur des projets de moyenne ou de grande taille.

Plus le projet est grand, plus le fait d’avoir un développeur inexpérimenté dans l’équipe sera pénalisant financièrement. Mais cela signifie-t-il qu’on ne peut pas embaucher de développeurs inexpérimentés du tout ? Car si oui, comment vont-ils acquérir de l’expérience ?

En effet, le travail quotidien au sein du département IT d’une entreprise de développement ne se limite pas aux tâches compliquées. Il s’agit plutôt d’une multitude de tâches, allant des plus simples à celles qu’on a intérêt de confier, de par leur statut business critical, à des salariés les plus expérimentés en la matière.

Le fait qu’il y a une multitude de tâches simples permet, justement, d’embaucher les développeurs débutants. Il ne s’agit pas là des projets de petite taille, bien que ceux-ci existent marginalement : généralement, le département IT se voit confier soit des projets allant d’un site e-commerce à des systèmes de grande échelle. Il s’agit en revanche des solutions qui peuvent servir dans la vie quotidienne des autres développeurs, soit des solutions aux problèmes ponctuels. Les confier aux développeurs moins expérimentés est bénéfique sur les trois points de vue :

  • Financièrement, il n’y a pas de grande différence entre un développeur qualifié et non qualifié lorsqu’il s’agit de résoudre un problème simple. Les deux peuvent le faire, sans que le premier possède une qualité de nature à le rendre manifestement plus productif.

  • De point de vue de l’apprentissage des nouveaux développeurs, travailler dans une équipe de professionnels est certes très formateur, mais à partir d’une certaine différence de niveau, le développeur inexpérimenté va juste avoir tendance à s’éclipser, laisser faire ses collègues, et ne plus s’intéresser vraiment au projet. Les petits projets en revanche ont plus de chance d’intéresser la personne, tout en lui donnant une satisfaction personnelle d’avoir accompli, à elle seule, le projet.

  • De point de vue de la productivité, la présence d’un développeur inexpérimenté dans une équipe est particulièrement pénalisante.

Je souhaite décrire ci-dessous deux de ces problèmes qui auraient pu être confiés à une personne ayant pas ou peu d’expérience professionnelle. Mais avant cela, je pense qu’il est utile de préciser plusieurs règles qui s’imposent à une entreprise de développement souhaitant embaucher un développeur pas ou peu qualifié :

  • Il n’est pas souhaitable de mélanger dans une même équipe les personnes dont la qualification est très différente. Si un nouveau développeur ne possède quasiment aucune connaissance en la matière, mettez-le avec les « débutants avancés ». S’il a un niveau moyen, mettez-le avec les professionnels. S’il est un professionnel, il peut travailler dans une équipe d’experts.

  • Un développeur pas ou peu qualifié ne peut être embauché que dans une entreprise qui compte déjà assez de salariés professionnels. Si le core competency de l’entreprise est le développement, autant faire en sorte qu’il soit fait par des gens qui s’y connaissent un minimum.

Ces réserves étant faites, passons aux exemples.

Exemple 1 : Guid utility

Cet utilitaire a été crée pour faire deux choses :

  • Fournir les GUIDs, chose qui peut servir des fois lorsqu’il s’agit d’inclure un nouveau GUID dans le code source,

  • Permettre de générer les en-têtes pour les fichiers C#, ces en-têtes comportant le GUID de l’auteur du fichier et son nom.

S’est ajoutée par la suite une troisième fonctionnalité, à défaut de pouvoir être mise dans une autre application et à défaut d’être si importante pour mériter une création d’une application à part :

  • Génération des mots passe aléatoires, ceci pouvant être utilisé dans les contextes où le mot de passe ne doit pas être enregistré du tout par exemple, ou encore lorsque le mot de passe n’a pas à figurer dans Passwords Manager.

Capture d'écran d'un utilitaire de génération des mots de passe

Capture d'écran d'un utilitaire de génération des mots de passe

Avec uniquement cent six lignes IL, ce n’est clairement pas une application compliquée. Cependant, elle présente des points intéressants pour un développeur C# débutant :

  • Il était nécessaire de baser le code sur les bibliothèques existantes développées en entreprise. Par exemple, la gestion des mots de passe était assurée déjà par les bibliothèques de Passwords Manager, ou encore la récupération de la liste des utilisateurs se faisait via un composant de gestion des utilisateurs.

  • La liste des utilisateurs pouvant prendre une à deux secondes pour se charger, il était indispensable de faire ce chargement en asynchrone.

  • Les indicateurs des touches du clavier devaient apparaître lors de l’appui sur Ctrl, puis disparaître après quelques secondes.

Formateur, sans être simpliste, ce projet se présente donc comme un candidat parfait dans le cadre de stage de courte durée ou de l’arrivée d’un salarié inexpérimenté dans l’entreprise. Un autre avantage, c’est que ce projet peut être repris par la suite par la même personne qui souhaite apprendre comment effectuer le refactoring, le data binding, ou encore comment l’architecturer d’une façon à permettre une extensibilité d’une source qui fournit la liste des utilisateurs.

Exemple 2 : Analyse des logs

Ce problème vient de se poser avant la migration vers le nouveau site de Pelican Design & Development. Il était souhaitable de connaître quelles pages du site ont été consultées le plus d’une part à l’extérieur, d’autre part à partir des machines de l’entreprise-même. Le nouveau site n’ayant rien en commun avec l’ancien, tous les liens auraient été rompus, et il s’agissait de déterminer la liste des redirections à établir pour les pages qui pouvaient être utilisées. Le site comportait l’ensemble des logs IIS pour les dernières années.

Une telle mission peut très bien être confiée à une personne inexpérimentée. Comment aurait-elle procédé ? Il n’y a pas là de bonnes ou mauvaises approches, semble-t-il. Je connaissais vaguement qu’il existait un outil de parsing des logs IIS. Si je n’avais été pas au courant, j’aurais probablement essayé de faire bêtement mon propre utilitaire très basique en C# permettant de charger les données vers la base de données, pour ensuite l’analyser selon les moyens ordinaires.

Une personne différente aurait peut-être cherché sur Google : « parse iis logs ». Sans surprise, on tombe sur le site de Scott Hanselman qui parle de LogParser, et sans grande difficulté on trouve la page de téléchargement. Mais après avoir regardé la documentation, je préfère plutôt importer les données dans la base de données et utiliser Microsoft SQL Management Studio qui m’y est plus familier pour analyser les données.

La recherche « iis logs to microsoft sql server » donne en premier résultat l’article de Knowledge Base de Microsoft Support qui indique qu’il faut :

  • Créer une table SQL via une commande fournie dans l’article-même,

  • Faire un bulk insert des données.

L’article précise, en outre, qu’il faut supprimer les lignes commençant par le caractère « # ». L’article renvoie vers un utilitaire de Microsoft chargé de le faire. Pas besoin, PowerShell est là pour ça, et en plus permet de combiner tous les fichiers en un fichier unique :

foreach($i in ls -name *.log)
{
    get-content $i
        | where {$_ -notlike "#*"}
        | out-file -encoding oem -append All.log
}

Lors de l’importation du fichier, le premier souci rencontré : il n’est pas possible d’importer les données dans la base de données avec le schéma donné dans l’article de Knowledge Base, car le format du log est différent (W3C Extended en l’espèce). La requête peut être alors réécrite ainsi :

create table [dbo].[MainLogs]
(
    [date] date null,
    [time] time(0) null,
    [s-ip] varchar(40) null,
    [cs-method] varchar(10) null,
    [cs-uri-stem] varchar(1024) null,
    [cs-uri-query] varchar(1024) null,
    [s-port] int null,
    [c-username] varchar(50) null,
    [c-ip] varchar(50) null,
    [cs(User-Agent)] varchar(1024) null,
    [sc-status] int null,
    [sc-substatus] int null,
    [sc-win32-status] bigint null,
    [time-taken] int null
)

Désormais, l’import avec :

bulk insert [dbo].[MainLogs] from 'c:\All.log'
with (fieldterminator = ' ', rowterminator = '\n')

se fait sans souci. On obtient alors les données brutes qu’il faut désormais analyser.

Reste le plus simple : formuler les requêtes précises pour dissocier les IP distants des IP de l’entreprise, puis afficher les pages dans l’ordre allant des URI les plus visités à ceux qui n’étaient tapés qu’une fois, analyser les résultats et les présenter.

Cette mission s’avère donc tout à fait adaptée à des développeurs débutants qui souhaitent élargir leurs horizons, en peaufinant ses connaissances en SQL, mais aussi en apprenant l’utilisation de PowerShell ou d’outils similaires.