Une forge, des forges... ou autre chose ?

Par forge de développement logiciel, j'entends ici les plateformes type GForge, Savannah ou encore GitHub, c'est-à-dire un ensemble d'outils pour le développement logiciel comprenant au moins un gestionnaire de versions, un gestionnaire de bogues (ou "tracker"), ainsi que souvent l'hébergement de site web, des outils de communication, ...

La communauté des développeurs de l'ESR est très variée, du point de vue des méthodes et technologies utilisées mais aussi du point de vue de l'expérience de ses membres, allant du débutant à l'expert chevronné, en passant par le chercheur "qui s'y est mis".

De cette variété de profils, de compétences et de besoins, est issue une grande variété de pratiques des outils disponibles pour le développement logiciel:

• Certains font des branches avec leur gestionnaire de versions, d'autres non,
• Certains utilisent un gestionnaire de bogues, d'autres non, d'autres ajoutent des champs spécifiques à leur logiciel alors que d'autres ignorent même cette possibilité,
• Certaines équipes pratiquent intensément la gestion de projet tandis que d'autres ont un mode de fonctionnement moins strict,
• ...

Par ailleurs, chaque développeur ou équipe de développeurs fait évoluer ses propres pratiques, en s'inspirant de celles des autres, en rencontrant des problèmes ou encore à cause de nouveaux besoins ou de nouvelles ambitions.

De façon naturelle et autant que possible, chacun met les outils disponibles au service de sa façon de travailler. Les outils sont donc idéalement au service du développeur, de ses besoins, de sa vision de son travail, des contraintes qu'il se fixe.

Le développeur, en véritable artisan, fait sans cesse évoluer ses propres pratiques, notamment en fonction de son expérience. Pour cela, il doit pouvoir choisir ses outils et utiliser les outils disponibles de la façon la plus adaptée à sa tâche.

Une forge n'est qu'une collection d'outils, parfois (mais rarement) reliés entre eux. Par ailleurs, le développeur n'a pratiquement jamais la possibilité de modifier ces outils pour les plier à ses besoins. De plus, certains développeurs n'ont pas la possibilité de mettre en place leurs propres outils, voire leur propre forge.

La mise à disposition d'une forge pour une communauté de développeurs peut donc être considérée comme une prescription plus ou moins forte d'outils à utiliser. De plus, sans grande marge d'adaptation des outils à ses besoins, le développeur se voit alors prescrire non plus seulement des outils, mais les pratiques associées à ces outils, les fameuses "bonnes pratiques".

Or, si ces pratiques peuvent être jugées "bonnes", c'est toujours par rapport à un besoin, un objectif. Chaque développement étant différent, avec ses propres besoins, ses propres contraintes et ses propres objectifs, il y a peu de pratiques universellement bonnes, c'est-à-dire adaptées à tous les contextes.

La prescription des pratiques met alors le développeur dans l'impossibilité de créer, d'inventer les pratiques les plus adaptées à son projet. La seule solution qu'il lui reste, s'il en a la capacité, est alors d'utiliser d'autres outils, voire de développer ses propres outils.

En l'absence de cette possibilité d'initiative, le développeur n'est plus le maître de ses pratiques: il est prolétarisé, il devient l'exécutant du fonctionnement imposé par la machine.

Cette prolétarisation n'est ni bien ni mal, mais elle est les deux à la fois.

Le développeur peut alors se concentrer sur le code sans avoir à éventuellement mettre en place d'autres outils pour refléter ses pratiques, ce qui peut être vu comme un gain de temps. C'est le même principe que le lave-linge: l'utilisateur ne sait plus laver le linge mais il a du temps pour faire autre chose, notamment pour recréer de nouveaux savoirs, donc une possibilité de déprolétarisation.

Des formations permettent d'obtenir des développeurs partageant les mêmes pratiques, facilitant la reprise d'un développement par d'autres développeurs. Cependant, cet aspect peut dériver dans une logique basée sur les fameuses "compétences techniques", réduisant le développeur à un ensemble de telles compétences.

Enfin, l'impossibilité d'adapter les pratiques peut freiner voire nuire à un développement, handicaper la communication entre développeurs, ...

Sur la prolétarisation (Allocution de C. Fauré à l'INRIA, 20'52 -> 28'30):

Si la prescription d'outils et par là même de pratiques peut être bénéfique, dans un premier temps, pour une catégorie de développeurs, notamment débutants, il faut cependant laisser la possibilité à chaque développeur de faire évoluer ses pratiques de sa propre initiative, car il est le mieux placé pour adopter les pratiques les plus bénéfiques pour sa tâche.

Par ailleurs, prescrire des pratiques à un débutant ne dispense en aucun cas d'explications quant au bien fondé de ces pratiques dans le cadre de son activité. Un accompagnement doit lui permettre d'avoir un regard critique sur ses pratiques, condition indispensable pour qu'il les fasse évoluer.

Il ne faut donc pas mettre le développeur en position d'adaptation à des usages prescrits, mais en position d'adoption de pratiques (cf la différence entre adoption et adaptation).

Une forge peut donc permettre d'"élever le niveau" de développeurs débutants en prescrivant outils et pratiques, pourvu qu'on les accompagne de formations; il s'agit en quelque sorte de faciliter la mise du pied à l'étrier.

Pour les développeurs plus expérimentés et en capacité d'une réflexion sur leurs pratiques, y compris les débutants après quelques temps, le cadre trop figé et trop prescriptif d'une forge n'est plus satisfaisant et agit comme une bride.

Par ailleurs, les limites des forges actuelles ne se situent pas seulement dans les outils figés qu'elles proposent, mais également dans les possibilités de liens entre ces outils. Si des pratiques existent pour chaque outil, il existe aussi des pratiques, ou process, mettant en jeu plusieurs outils; c'est l'exemple classique du lien entre gestionnaire de versions et gestionnaire de bogues: on veut pouvoir dire que telle révision (tel "commit") correspond à la correction de tel bogue. En l'absence de lien entre les outils, tout repose sur la discipline du développeur qui doit mettre lui-même en place les références entre les éléments (numéro du bogue dans le commentaire de commit, numéro de révision dans les informations relatives au bogue).

La composition des outils disponibles offre un champ de pratiques infini pour refléter les processus de développement de chaque développeur et chaque équipe.

La prescription des liens possibles entre les outils est alors une limite de plus pour les pratiques du développeur.

Suite à ces considérations, il apparaît donc qu'une forge n'est pas adaptée pour satisfaire les besoins de l'ensemble des développeurs.

On veut donc pouvoir faire sauter deux verrous: la liste figée des outils, les liens figés entre les outils proposés.

Une "solution" pourrait être la suivante: continuer de proposer des outils comme ceux des forges, mais en ajoutant la possibilité d'accéder à leurs fonctionnalités via une interface de programmation (SOAP, RPC, web service, ici n'est pas la question). Ceci permettrait, toujours dans le but de mettre en place les outils reflétant les pratiques choisies par le développeur, de:

• "faire son marché" dans les outils proposés, en adopter certains et en développer éventuellement d'autres,
• interfacer ces outils pour en quelque sorte implémenter les méthodes de développement appropriées pour un projet.

Les outils sont notamment des gestionnaires de bogues, gestionnaires de tickets, gestionnaires de tâches, gestionnaires de projet, aides à la revue de code, gestionnaires de versions, ...

L'important est que le développeur puisse agencer ces outils de la façon qu'il le souhaite, quitte à développer la glu entre ces outils, glu basée sur les interfaces offertes par ces outils.

Qui peut le plus peut le moins: cette approche est tout à fait compatible à la mise en place d'un environnement "standard" pour développeurs débutants. On peut même imaginer plusieurs "standards", en mettant à disposition plusieurs agencements d'outils. Les développeurs expérimentés peuvent également rendre disponibles leurs propres agencements.

L'offre d'outils à agencer peut s'enrichir plus rapidement puisque leur développement peut être indépendant des autres outils.

On retrouve bien ici le côté artisan du développeur, ce dernier choisissant les outils appropriés pour ce qu'il veut développer et adaptés à sa façon de travailler. Le choix des outils est un acte important qui permet notamment de se contrôler soi-même, de contrôler sa propre activité. Cela passe par une connaissance de ses méthodes, de ses défauts, de ses "mauvaises habitudes".

Le choix et l'agencement des outils choisis doit permettre au développeur de construire un véritable système d'information associé au logiciel développé, système comprenant également les circuits d'information correspondant aux processus de développement mis en oeuvre.

Ajout le 29 octobre 2011: L'artisan et son atelier