Archives pour la catégorie Technical Leadership

image

Les vidéos de l’ALM Summit sont disponibles

image

Les vidéos de l’ALM Summit 3 qui a eu lieu du 28 Janvier au 1er février au conference center de Microsoft à Redmond sont disponibles sur Channel 9 :

http://channel9.msdn.com/Events/ALM-Summit/ALM-Summit-3

Les sessions de ce summit sont organisées autour de 4 tracks :

Je vous recommande de passer un peu de temps à consulter les enregistrements de certaines de ces sessions, elles sont très souvent d’excellente qualité.

Je n’ai pour ma part pas encore eu le temps d’en visionner la majorité d’entre elles, mais je reviendrais vers vous lorsque cela sera le cas afin de vous recommander celle que j’ai trouvé les plus pertinentes.

image

Forcer les developpeurs a mettre des commentaires de changesets pertinents

Ecrire des commentaires de checkins pertinents fait parti  des tâches simples que l’on a du mal à faire comprendre et accepter des équipes.

Les tâches non liées à l’écriture de code mais qui sont là pour faciliter la maintenance des applications (via dans le cas présent une meilleure traçabilité des modifications effectuées) sont il est vrai souvent considérées par les développeurs comme des tâches moins importantes, moins prioritaires, des tâches de seconde classe.

Par fainéantise, ou par désintérêt on se retrouve le plus souvent avec ce type de commentaire :

image

Des commentaires (lorsqu’ils sont présent ce qui n’est pas le cas pour le changeset 7817) qui n’ont aucune valeur.

Le problème est important puisque cela conduit à ce genre de choses :

image

Un historique de fichier inutilisable  où on ne sait pas ce qui s’est passé sauf à passer beaucoup de temps à faire des compare entre chaque changeset.

Lors d’une discussion avec un responsable ALM, celui-ci m’indiquait qu’il n’arrivait pas à arriver à ce type de résultat :

image Un résultat certes imparfait mais quand même de qualité, avec des information utiles qui pourront être consultées dans le futur.

Pour parvenir à cela, et bien évidemment après avoir expliqué à l’équipe en quoi il est important de placer des commentaires pertinents, j’ai été obligé de passer en mode “dictateur”, et TFS propose une solution simple pour y arriver : les alertes.

Afin “d’encourager” les membres d’une équipe il suffit de se créer une alerte sur tous les checkins lié à un Team Project :

image

Une fois le mail d’alerte reçu, sachez qu’il est possible de directement répondre à ce mail afin de communiquer avec le développeur. – Je vous invite à consulter cet ancien post qui décrit le process -.

Ainsi vous pouvez réagir très rapidement à ces mauvais commentaires en demandant au développeur fautif de modifier à posteriori son commentaire afin qu’il soit pertinent.

Après avoir reçu plusieurs mails de rappel à l’ordre demandant de corriger le problème, les plus récalcitrants rentrent ainsi dans le bon chemin sur une période de temps assez courte (environ 1 mois dans mon cas).

image

The Siren of Shame

J’aime utiliser des gadgets en entreprise. L’objectif de ceux-ci est d’apporter un côté ludique qui permet de faciliter le travail de l’équipe tout en dédramatisant les choses.

C’est donc avec grand plaisir que j’ai découvert la “Siren Of Shame”.

Ce gadget est en réalité constitué de deux parties :

  • L’élément visible qui est le gyrophare USB qui s’installe en 1 clic de souris
  • Un outil de monitoring qui est capable de se connecter aux principaux serveur d’intégration continue du marché (TFS, Team City, Cruise Control.net, etc.)

L’objectif est simple : alerter de manière visuelle et sonore dès qu’une build est cassé pour la réparer au plus vite.

image

L’installation du logiciel se fait de manière très simple et la configuration est également aisée. En 5 minutes, le système est fonctionnel et nous sommes capables de tester les différents styles de lumière (gyrophare tournant, fondu de lumière, etc.) et de définir jusqu’à quand nous souhaitons avoir les signaux sonores et lumineux (signal pendant un laps de temps défini ou jusqu’à ce que la build soit réparé, etc.).

L’outil propose de plus 3 fonctionnalités intéressantes :

  • Un tableau de bord permettant de voir l’état de toutes les builds
  • Un outil de réputation qui permet d’avoir une liste triée des développeurs selon un ratio nb de buils/nb de builds échouées
  • Un graphique simple d’analyse de l’état d’une build

image

Un outil donc fort simple, qui fait uniquement ce qu’on lui demande sans trop de fioritures.

Avant de vous décrire mon retour d’expérience du système (cela fait un mois que nous l’avons à présent adopté), je vais vous retracer l’historique de la mise en place du serveur de build dans le service afin de bien décrire l’intérêt d’utiliser ce type de gadget et l’effet obtenu.

Pourquoi un serveur de build ?

Une de mes premières actions lors de mon arrivée à Log’in Space il y a maintenant 1 an a été d’analyser l’environnement de développement pour voir comment il était possible de rendre l’équipe plus efficace.

Le service développement fait très fréquemment des releases des différents produits, la création d’une version prenait alors environ 1h lorsqu’il n’y avait de problèmes, et durait beaucoup plus lorsque un problème de compilation non détecté avait lieu.

Les développeurs avaient l’habitude d’effectuer leur checkin après avoir terminé sans forcément faire de getlatest réguliers. Le code présent sur le source control était différent de celui présent sur les postes de développement et de temps en temps il arrivait que le responsable de la release ait une surprise en essayant de compiler le résultat final…

Afin de résoudre ce problème et être beaucoup plus réactif en cas de problème (ie. ne plus être devant le fait accompli mais réagir dès qu’il y a un problème) un serveur de build sous Team Build a été mis en place.

La première étape a été de simplement automatiser la création d’une version, puis de mettre en place de l’intégration continue (plus proche actuellement de la compilation continue). Ainsi chaque développeur est abonné aux alertes proposées par TFS, et est ainsi notifié de la réussite ou de l’échec de la build déclenché par son check-in. De plus l’automatisation a permis de réduire le temps de création d’une version à 15min.

Il s’agit d’un progrès dans le sens où l’on est beaucoup plus réactif mais il me restait à arriver à sensibiliser l’équipe sur le fait de vraiment prêter attention à avoir un code correct et fonctionnel dans le source control, afin d’avoir le plus rarement possible un code invalide.

Et cet objectif a été atteint grâce à la sirène. Les membres de l’équipe souhaitant éviter que la sirène ne s’allume, ils pensent à présent bien aux risques apportés par leur check-in avant de faire leur commit ! La sirène est en effet mise en avant et bien visible de tous, il n’est donc pas nécessaire qu’elle s’allume pour que tout le monde ait conscience de sa présence.

Encore un (tout petit pas) de franchi vers une meilleure qualité logicielle et vers moins de stress pour l’équipe !

Il reste bien évidemment de gros progrès à accomplir  comme l’intégration de l’exécution de tests automatisés par exemple, mais il s’agit d’une évolution qui va dans le bon sens.

Les + et les -

Les +

  • Outil simple à mettre en œuvre, qui fait uniquement ce qu’on lui demande
  • Une API est disponible pour piloter la sirène dans d’autres contextes que l’intégration continue

Les –

  • Lorsque deux builds échouent “en même temps”, les signaux s’arrêtent lorsqu’une des builds a été réparé et non lorsque l’ensemble des builds ont été réparés
  • Très légers bugs dans l’affichage des changesets liés aux builds lors de check-in très rapprochés

Les risques Sourire

J’ai pu identifier deux risques durant ce premier mois d’utilisation.

Le premier concerne les prestataires intervenants sur un de nos projets. L’un deux a eu la bonne idée de casser et de réparer la build entre midi et deux. L’équipe étant en train de déjeuner la sirène a été d’une totale inefficacité ! Il peut être intéressant de garder le système d’alertes afin d’avoir un réel suivi des builds.

Second risque : Si vous mettez Kool & The Gang au bureau afin de mettre un petit d’ambiance, il se peut qu’un membre de votre équipe vous propose d’allumer le gyrophare en cassant une build histoire d’avoir une ambiance son et lumière Smile (oui, oui c’est du vécu…)

image

Les évènements Microsoft sont-ils uniquement des évènements marketing ?

Des évènements purement marketing ?

Je suis toujours surpris de constater qu’il existe toujours un certain nombre de personnes qui pensent que les évènements à destination des développeurs organisés par Microsoft sont crées uniquement à des fins marketing et qu’elles sont donc par définition inintéressantes pour des développeurs.

J’ai de nouveau rencontré ce type de remarque récemment en commentaire d’un de mes posts où j’évoque l’évènement Build qui débutera la semaine prochaine.

image

Je vais donc profiter de l’occasion pour préciser ce que je pense de ce type d’évènements. Ayant eu l’opportunité de participer aux Tech’Ed Europe 2003/2004/2005/2006 et à la PDC 09 je commence à avoir un certain recul sur ces évènements internationaux.

Commençons par enfoncer des portes ouvertes, OUI ce sont des évènements organisés par Microsoft, donc OUI seules les technologies et produits Microsoft sont présentés. Cela est dommage car ces évènements ne permettent donc pas de manière simple d’avoir un positionnement de ceux-ci par rapport à la concurrence.

Autre inconvénient de ce type de conférence et de présentation, l’objectif pour Microsoft est de présenter ces technos et produits et de donner les bonnes pratiques liées à l’utilisation de ceux-ci et en aucun cas d’aider les développeurs à devenir de meilleurs développeurs contrairement à d’autres conférences comme la NDC par exemple. Seules les sessions dédiées à l’ALM peuvent parfois rentrer dans cette catégorie.

Mais ce ne sont pas pour autant des conférences marketing inintéressantes techniquement bien au contraire ! Il y a toujours des sessions intéressantes et qui ne sont pas forcément lié directement à un argument de vente.

Je me souviens par exemple d’une session au Tech’Ed 2003 où le speaker à redéveloppé le contrôle DataGrid d’ASP.net quasi feature complete en une heure from scratch sans aucun “tust” (très éprouvante pour arriver à assimiler l’immense volume de notions présentées), d’une session de Juval Lowy sur l’API System.Transactions introduite avec le framework 2.0 où il présentait son framework qui permet de manipuler n’importe quel objet serializable de manière transactionnelle, d’une session sur le cryptage level 800 par Rafal Luckawiecki, etc.

Idem pour la PDC 09, même si comme je l’indiquais dans mon bilan de l’évènement, je n’avais pas retrouvé de sessions techniques d’un niveau aussi élevé que certaines  sessions de level 400 proposées aux Tech’Ed, il n’en reste pas moins qu’assister à un panel de discussion dédié aux langages avec comme intervenants Herb Sutter, Anders Heiljsberg, Eric Meijer, Don Box, et d’autres, à une session sur le garbage collector présentée par Patrick Dussud ou encore une session sur Rx par Eric Meijer et Bart de Smet reste une occasion intéressante et épanouissante techniquement.

Eric Meijer

Pourquoi s’y rendre quand on peut télécharger les vidéos des sessions ?

La raison est simple : le networking !

Microsoft mets à disposition depuis quelques années les vidéos de ces évènements en ligne temporairement ou “définitivement”. Participer sur place en IRL à ce type d’évènements permet :

  • de confronter ses idées et opinions par rapports à ce qui est présenté avec les autres attendees.
  • de bénéficier du retour d’expérience des autres attendees sur l’utilisation d’une techno sur de vrais projets
  • de créer ou maintenir son networking avec les microsoftees de sa section locale et ainsi parfois avoir des informations complémentaires ou “des bruits de couloir” lorsque l’on est sous NDA (contrat de confidentialité) avec l’éditeur.
  • de maintenir son networking de manière générale avec “l’écosystème” .net (partenaires, communautés, SSII, éditeurs, etc.)

Autre raison de s’y rendre toute bête mais qui a en son importance, vous avez votre planning définitivement bloqué et vous êtes ainsi sûr de faire votre veille technique pendant la semaine que dure la conférence. Au lieu de s’éparpiller et de visionner quelques vidéos par-ci par-là durant son temps libre, vous avez la possibilité d’effectuer votre veille technique à la carte durant une semaine non-stop.

En conclusion

Assister à un des évènements internationaux du type Tech’Ed, PDC ou Build est, à mon avis, un très bon moyen d’effectuer sa veille technique avec généralement des sessions de qualité.

Si votre objectif est d’assister à une conférence orientée sur la technique en étant indépendant de tels ou tel éditeur et d’avoir une vision plus générale des choses afin de devenir un meilleur développeur alors il vaut mieux vous orienter vers une conférence de type NDC par exemple.

Sur ce, rendez-vous dans quelques jours pour voir ce que donne la Build !

image

La revue de code “du pauvre” avec TFS 2010 et Outlook 2010

Pour faire suite au post de la semaine dernière sur la mise en place de revue de code “simple” avec une petite équipe grâce à TFS 2010, je vous propose quelques astuces pour configurer Outlook 2010 en ce sens.

Première étape, j’ai créé une règle afin de ne pas polluer mon inbox dès qu’un développeur fait un checkin. Pour cela, une simple règle de redirection vers un dossier en fonction du sujet du mail suffit :

image

Nous venons de classer les mails d’alertes dans un dossier dédié, il reste à faire la même chose cette fois-ci pour les mails que j’envoie pour donner mes remarques lors des revues de code. J’ai donc mis en place une règle déclenchée non pas à la réception d’un message mais lors de l’émission :

image

Cette règle me permet d’avoir un historique des revues de code effectué directement dans ma boite mail. Mais il reste un léger problème d’affichage. Comme tous les mails, je me retrouve alors avec l’expéditeur du mail indiqué dans la liste des mails. Etant l’unique expéditeur, je souhaiterais plutôt avoir le destinataire du mail comme ci-dessous :

image

Cette opération peut se faire assez simplement  en modifiant la vue et en changeant l’ordre d’affichage des colonnes :image

Avec la création de ces deux règles, nous sommes donc capable de classer les mails d’alertes de TFS 2010 en réception, mais aussi les mails de revues de code envoyés aux développeurs.

image

La revue de code “du pauvre” avec TFS 2010

imageQue cela soit pour les prestataires auxquels nous faisons appels ou pour le code produit en interne par notre service développement, lors de mon arrivée dans ma nouvelle société, j’ai souhaité mettre en place des revues de code afin :

 

 

  • d’avoir une vision précise de la qualité de code produite en interne et en externe
  • être capable d’évaluer les compétences des prestataires auxquels nous faisons appels
  • Déceler les non-conformités le plus rapidement possible afin de mener des actions correctives les moins couteuses possibles
  • faire monter en compétence l’équipe interne en faisant des revues de code en binôme, et en ciblant les formations internes en fonction des lacunes constatées.

Pour cela, j’ai donc cherché comment effectué des revues de code le plus simplement possible avec Visual Studio 2010 et TFS 2010. Visual Studio 2010 ne proposant pas encore de fonctionnalité intégrée comme cela sera pour la V.next, je vous proprose via ce post ma méthode pour parvenir à effectuer ces revues de code, de manière simple et rapide.

Et pour cela, j’utilise la fonctionnalité des alertes de TFS 2010. Il est en effet possible de s’abonner à tout checkin effectué sur un team project directement depuis Visual Studio :

image

Et avec TFS 2010, ces alertes ont gagné de l’intérêt puisqu’elles bénéficient de l’intégration native de Team Web Access :

image

Chaque item présent dans un changeset peut être pointé via un lien, lien renvoyant directement vers le compare avec la précédente version, ce qui permet de simplement voir l’évolution du code entre les deux versions (celle checkinée, et celle avant la modification) :

image

De plus,  les développeurs de TFS ont eu la bonne idée de définir un header reply-to dans les mails des alertes.

Ce qui fait que l’on peut directement répondre à un mail d’alerte, celui-ci arrivera directement dans la boite du développeur qui a effectué le checkin. Ainsi si l’on suit le screenshot du dessus, au lieu de répondre à tfsservice@loginspace.fr qui a envoyé le mail d’alerte, cela sera bien le développeur qui a effectué le checkin qui recevra le mail :

image

Cette technique permet donc d’effectuer des revues de code simplement, en analysant le code modifié grâce aux alertes, et en faisant les remontées aux développeurs directement par mail, ou via des sessions de revues de code en binôme lorsque cela le nécessite.

L’avantage de cette technique réside dans sa simplicité (pas de mise en place d’usine à gaz), et dans le fait que je peux être très réactif (je fais mes revues tous les jours en fin ou début de journée).

L’inconvénient majeur est que le code revu est déjà présent dans le repository. Ce qui nécessite un second checkin pour corriger le code après une revue.

Dans un prochain post, je détaillerais les configurations d’Outlook que j’ai effectué afin d’améliorer encore ce processus de code.

image_thumb.png

L’incompétence des développeurs

Il y a un peu plus d’un mois je m’étais décidé à répondre au post “On a besoin de stars pas de managers”.

Romain David, co-fondateur de la startup Balloon y explique son désarroi face au grand nombres de développeurs qui ont comme objectif de :

ne pas rester éternellement développeur, mais devenir chef de projet

 

Ce qui dans le cas d’une startup est pénalisant puisque la société recherche des profils techniques pointus, autonomes, capables d’apporter une vraie valeur ajoutée par rapport à des “pisseurs de code” classiques.

La raison de ce désamour du métier de développeur qui incite à devenir chef de projet est selon moi identique à la raison pour laquelle les développeurs ont une mauvaise image.

Et cette raison est simple :

une très grande majorité des développeurs est incompétente

 

Je vous parlais il y a peu des 3 stades de maturité d’une équipe de développement, le problème est que selon mon expérience environ 75% des équipes (et donc des développeurs et chefs de projets) sont dans la phase du chaos, 20% dans la phase intermédiaire, et 5% sont autonomes. (N’hésitez pas à confirmer ou infirmer cette estimation dans les commentaires).

Et pour illustrer cette incompétence je vais m’attarder sur le profil des développeurs .net. Une majorité n’a pas des connaissances de bases telles que :

  • Connaissances de bases sur la POO (expliquer clairement la différence entre une classe et un objet, les différences entre une classe abstraite et une interface, notions de base sur l’héritage, donner un exemple de design pattern, etc.)
  • Comment gérer les erreurs (définir les différentes stratégies de gestion des exceptions)
  • Savoir définir avec une phrase claire ce qu’est le framework .net et quels sont les services fournis par le CLR.
  • Maitriser ce qui n’a pas attrait à l’écriture de code et que Microsoft regroupe sur le terme d’ALM (gestion des sources, gestion des tâches/bugs, builds, tests, etc.)
  • etc., etc., etc.

Quand je parle d’incompétence je ne parle donc de non-maitrise de concepts et notions mais de non-maitrise des fondamentaux essentiels au bon déroulement d’un projet de développement.

Durant les entretiens techniques que je fais passer, j’en suis “réduit” à poser des questions ouvertes afin de juger du recul du candidat sur différentes technologies (compréhension des principes et de la philosophie d’une techno, description des avantages et des inconvénients de la techno), et de juger de sa compréhension du métier de développeur (recul par rapport au métier, description des difficultés du métier, et comment y pallier). Ceci pour estimer de sa capacité à rapidement arriver au 2eme stade de compétence décrit rapidement ci-dessus.

Le fabuleux destin du développeur

Fort de cette incompétence, le développeur tel un forçat va devoir s’efforcer d’essayer de rattraper (souvent en vain) ses propres erreurs, les erreurs de ses collèges développeurs, du chef de projet, et des commerciaux. Oublier la notion d’horaires de travail et prendre un soin particulier à bien entretenir sa nouvelle petite amie : la machine à café.

Le tout en devant :

  • expliquer pourquoi une fonctionnalité qui marchait correctement auparavant ne fonctionne plus à cause d’une modification qui n’a (en apparence) aucun rapport avec celle-ci
  • parvenir à justifier pourquoi il serait plus simple de refaire depuis zéro

qui pourrait être traduit par :

  • “ah bravo tu es tellement mauvais que quand tu touches une partie de l’application, tu en casses une autre“
  • “tu es tellement mauvais que pour faire une tâche tu dois t’y reprendre à plusieurs fois en recommençant à zéro“

image

Ainsi après avoir passé plusieurs mois à travailler sur des projets en sachant pertinemment que le développement réalisé était de très mauvaise qualité, et en se demandant pourquoi on lui avait explique que les frameworks et outils actuels rendaient la vie du développeur très simple (on m’aurait menti ?) il est compréhensible que celui-ci veuille prendre la responsabilité de chef de projet.

Une partie des développeurs voudront assumer cette responsabilité afin d’essayer d’améliorer les choses.
Bien évidemment, n’ayant pas reçu de formation de chef de projets, la probabilité d’arriver à réellement améliorer les choses est assez faible. Et ceux qui font l’investissement de faire une pause dans leur cursus professionnel afin de retourner à l’école et suivre une vraie formation de chef de projet suite à de mauvaises expériences vécues en tant que développeur, se font recaler pour leur manque d’expérience (cas d’un récent candidat qui recherche donc à présent de nouveau un poste de développeur…)

Une seconde partie de développeurs voudra devenir chef de projet non pas pour améliorer les choses mais pour ne pas à avoir subir toutes les erreurs du projet tout en ayant un meilleur salaire. Comme dans beaucoup de secteurs, c’est le salarié tout en bas de l’échelle qui subit le plus les conséquences des erreurs qui ont pu être commises. Il est donc plus confortable de monter d’un niveau, on ne sera pas plus compétent mais au moins on se tuera moins à la tâche. Et oui, dans le domaine du développement le développeur est considéré comme l’ouvrier préposé aux tâches répétitives. Après tout, du code ça reste du code non ?

Pour les développeurs qui ne souhaitent pas ou ne peuvent pas devenir chef de projet, plusieurs attitudes sont possibles. La plus courante est la résignation. Quand on a pleinement conscience de faire un travail de mauvaise qualité, soit on se rend malade en s’apitoyant sur son sort soit on prend du recul, de la distance, et on se détache petit à petit de son travail, en ne cherchant pas à s’impliquer et en renonçant totalement à essayer de faire changer les choses.

Je vous recommande la lecture de le post de Romain Verdier “Dégage sale programmeur ! ” qui décrit le problème avec infiniment plus de talent que moi.

Le métier de développeur est très complexe

Ce tableau assez noir n’est pas dû à la stupidité des personnes qui endossent le rôle de développeur (je pense que la majorité des développeurs est incompétente, je ne pense pas qu’ils sont stupides…) mais à la complexité du métier de développeur.

Un développeur doit posséder les compétences suivantes :

  • Etre avant tout un très bon “informaticien”. J’entends par là qu’il doit maitriser les notions fondamentales indispensables à la bonne utilisation et à la bonne exploitation de l’outil informatique. Maitrise d’un grand nombre de connaissances qui ne sont pas directement lié au développement (exemples : maitrise du fonctionnement d’un OS, de sa conception, de son architecture, sa gestion de la mémoire, maitriser la sécurité, savoir ce qu’est un process, un thread, maitriser la différence entre le 32 bits et le 64 bits, savoir ce qu’est une partition, savoir ce qu’est la virtualisation, connaitre les fondamentaux liés aux réseaux (ARP, DNS, IPV4, IPV6, MAC, etc.) etc., etc.)
  • Et après avoir acquis toutes ces connaissances “de base” sur l’informatique, le développeur pourra commencer à apprivoiser l’écriture de code et ceci via plusieurs langages puisqu’un seul ne suffira pas pour faire son métier (C#, VB, T-SQL, PL-SQL, XPath, Javascript, etc.). Il devra pour cela maitriser tous les fondamentaux de la programmation orientée objets, et découvrir par lui-même quelques bonnes pratiques qu’il n’a pas forcément ou pas correctement acquises durant sa formation. Puis au fil de son expérience devra comprendre en quoi consiste vraiment l’écriture de code (un code n’est pas figé et doit évoluer dans le temps = être maintenable, refactorisé et donc être testé, il doit de plus être géré via un source control (avec maitrise des concepts associés, checkin/checkout/label/shelve/merge, etc.).
  • Il devra également réellement comprendre en quoi consiste un projet de développement, le rôle et l’impact de chacun, et bien comprendre que développer ce n’est pas uniquement écrire du code.
  • Et bien évidemment comme l’informatique évolue très vite, une fois l’ensemble de ces connaissances acquises, le développeur doit être capable de les tenir à jour semaines après semaines en effectuant une veille technologique appropriée.

Bref, à mon avis un bon développeur se fait seul et n’apprends pas l’ensemble des concepts et notions qui feront de lui un développeur correct durant ses études (même après une école d’ingénieur). Cela nécessite un auto-apprentissage important (et donc un investissement personnel important) ce qui explique l’incompétence généralisée décrite au travers de ce post.

L’essentiel de la compétence d’un développeur s’acquiert via son expérience, il est nécessaire de réaliser que malgré toutes les compétences techniques qui ont pu (ou pas) être acquises durant les études, le métier de développeur nécessite de ne pas laisser tomber et de vraiment débuter à apprendre son métier lorsque l’on débute son expérience professionnelle le tout dans un contexte professionnel souvent très mauvais (mauvaise équipe de dév, mauvais chefs de projets, etc.)

Bon et bien évidemment, si vous pensez être dans les 5% évoqué ci-dessus ou même dans les autres 20%, je vous rappelle que je recherche du monde ! Clignement d'œil
(et maintenant vous connaissez certaines des questions que je pose durant les entretiens techniques…)

image

Les 3 stades de maturité d’une équipe de développement

Avec mon changement de métier en début d’année, j’ai naturellement enrichi ma liste de lectures avec des sites/blogs non techniques traitant du leadership d’équipes de développement.

Un des mes sites préférés dans ce domaine est le blog Five Whys de Roy Osherove et celui-ci identifie 3 stades de maturité d’une équipe de développement :

  • Le chaos : l’équipe ne possède pas les connaissances techniques fondamentales/de base/minimales nécessaires pour débuter à faire correctement les choses.
  • L’apprentissage : l’équipe possède certaines connaissances techniques ET non-techniques qui lui permettent de voir son niveau régulièrement s’améliorer
  • L’autonomie : l’équipe est quasiment autonome, et possède les connaissances nécessaires au bon déroulement d’un projet.

Vous pouvez vous référer à ce post ou encore à ces slides pour plus de détails sur ces stades de maturité.

image

Je n’avais jamais formalisé mon point de vue sur le niveau des équipes de dév. de cette manière avant d’avoir lu le blog de Roy Osherove, mais je suis entièrement d’accord avec ce découpage.

Et je trouve de plus qu’il permet d’expliquer énormément de choses concernant le monde du développement, et je vais m’attacher cette semaine à rédiger différents posts à ce sujet.

Stay tuned !

image

L’impact psychologique du nommage

Ceux qui me suivent sur Twitter le savent, je suis en train de mettre en place TFS 2010 au sein de ma nouvelle société et à cet effet nous avons mis en place une toute nouvelle infrastructure matérielle afin d’utiliser un ensemble de machines virtuelles.

Lors de la création de la machine virtuelle destinée à l’installation de TFS 2010, un de mes collègues m’a demandé le nom de machine que je souhaitais pour cette machine virtuelle en me demandant si le nom “VM-TFS” me convenait.

image Je me suis alors empressé de lui dire que je ne souhaitais pas que VM apparaisse dans le nom de la machine afin que les utilisateurs ne puissent pas râler sur l’installation à cause du fait que cela soit une VM. Mon collègue l’a pris sur le ton de l’humour mais j’étais en réalité très sérieux.

Une VM doit réagir comme une machine physique et je ne souhaite pas que les utilisateurs puissent avoir une image négative de TFS à cause du fait qu’il soit installé dans une machine virtuelle. La société n’a pas l’habitude d’utiliser les technologies de virtualisation, il est donc plus simple de ne pas leur mettre sous les yeux un panneau “Attention c’est une VM” à chaque fois qu’ils vont y accéder. L’idée n’est pas de masquer les choses (la nouvelle infrastructure a été présentée après que la migration de TFS 2005 vers TFS 2010 ait été effectué) mais de faciliter l’adoption d’une nouvelle technologie en supprimant des freins liés à des idées préconçues.

Dans le domaine du développement, j’ai également conseillé à plusieurs clients de nommer “intelligemment” certaines classes afin d’inciter une réelle maintenance/refactorisation de celles-ci. Durant des revues de code, ou tests de migration, ou autre type d’intervention, j’ai régulièrement trouvé des classes helpers destinées à faciliter l’utilisation d’une fonctionnalité. Ces classes utilisent souvent un nommage du genre “EasyQqueChose” (EasyDB pour l’accès aux bases de données, EasyXml pour la manipulation XML, etc.) pour bien signifier aux développeurs qu’avec cette classe il sera très simple d’effectuer la tâche qu’ils doivent accomplir.

Seulement avec le temps, la classe destinée à faciliter les choses est devenue un vrai capharnaüm, et est devenue complexe à utiliser. Bien évidemment cette classe doit être refactorée depuis 97879 siècles mais au final elle ne l’est jamais.

Quand je rencontrais ce genre de cas, je proposais souvent la même idée : prendre quelques minutes pour renommer la classe “EasyQqueChose” en “FuckingComplexAndUnusableQqueChose”. Je ne suis parvenu à faire appliquer cette idée qu’une seule fois  (et oui il y a encore beaucoup de développeurs qui ont peur de renommer une classe…) et étrangement quand je suis revenu quelques semaines plus tard chez ce client la classe avait été refactorée (et donc de nouveau renommée).

3 livres pour avoir les bases en .net

Quels
sont les livres que je peux lire pour avoir de bonnes bases en .net ?”

est en substance la question que se peuvent se poser ceux qui débutent en .net (et
que devraient se poser beaucoup de développeurs qui pensent avoir les bases :)). Il
se trouve qu’on vient de me la poser pour 686 ème fois, voici donc ma sélection de
3 ouvrages que je trouve important d’avoir lu pour être efficace.

Le
premier est la 3ème édition de CLR via C# écrit par Jeffrey Richter de Wintellect.
J’ai déjà lu les deux premières éditions et je suis en train de lire cette 3ème édition
(qui est sorti très récemment), et c’est de mon point de vue un des meilleurs ouvrages
sur les fondamentaux de la CLR et donc de la BCL.
Le
second ouvrage est orienté maitrise du langage C#. C# in depth de Jon Skeet est très
clairement l’ouvrage le plus pédagogique est le plus avancé que j’ai pu lire sur le
langage C#. Ce qui est plaisant avec cet ouvrage, c’est que l’ensemble des concepts
et notions sont abordés de manière intelligente sans passer sur les détails qui peuvent
paraitre compliqué au premier abord. Une vrai référence pour ceux qui s’intéresse
au langage C#.
Et
enfin, le petit dernier est le bien connu Framework Design Guidelines. Cet ouvrage
annoté par plusieurs acteurs importants dans le monde .net permet de comprendre comment
le framework .net a été conçu, et indique comment créer des frameworks qui respectent
les recommandations de Microsoft. Sa lecture peut très globalement être appliquée
à la création de tous type d’applications.

 

Et vous ? Quelles sont vos recommandations de lecture sur .net en général et sur
C# ?

<br />