Le social a plus d'influence sur les bugs que la technique

On peut penser ce qu'on veut de Microsoft en tant qu'entreprise, force est de constater que l'éditeur offre un terrain propice à l'étude à grande échelle des réalités du développement logiciel; et que les moyens financiers de Microsoft lui servent entre autres choses à financer une recherche privée d'un excellent niveau. L'exemple emblématique pour moi en est Nachi Nagappan, dont les travaux me fascinent.

Nagappan a repris un sujet d'étude assez ancient, la notion de susceptibilité aux bugs ("defect proneness"). Si vous découpez un logiciel en modules, et que vous comptez à l'issue d'une analyse raisonnablement rigoureuse quels modules font l'objet du plus grand nombre de corrections de défauts, vous vous rendrez compte que tous les modules ne se valent pas. Certains accumulent les casseroles, pour ainsi dire. On peut donc se demander s'il existe des régularités qui caractériseraient les modules les plus (ou les moins) susceptibles de contenir des défauts, de façon par exemple à guider le travail des testeurs.

On a beaucoup étudié les corrélations avec des mesures techniques, comme l'analyse des dépendances ou la complexité cyclomatique. Nagappan relève que c'est ignorer totalement l'aspect humain; on fait comme si le logiciel était en soi quelque chose d'objectif, une "chose" qu'on trouve telle quelle dans la nature et qu'on examine à la loupe comme un caillou ou une plante. Or ce qui est le plus important dans l'histoire c'est qu'un module ou un logiciel est produit par une organisation d'individus.

Nagappan et ses collaborateurs se sont donc penchés sur des "métriques" caractérisant l'organisation sociale des équipes responsables de divers modules dans le code, proprement garguantuesque, du système Windows 7. La culture d'entreprise de Microsoft offre un environnement relativement homogène, dans lequel des équipes bien identifiées s'occupent de modules bien identifiés, le terrain est donc favorable à une étude comparative qui analyse des caractéristiques relativement stables des équipes et des modules logiciels concernés.

Le résultat obtenu fait réfléchir (mais est-il vraiment surprenant): les paramètres "sociaux" sont plus pertinents que les paramètres "techniques" pour prédire quels modules sont les plus susceptibles de contenir des défauts.

Comme je l'ai dit précédemment il convient de rester critique, et le travail de Nagappan mobilise des outils statistiques et des critères d'évaluation ("précision" et "rappel") que je ne maîtrise pas, il me manque donc (pour l'instant) la culture nécessaire pour évaluer ces résultats.

Il me semble cependant qu'ils sont sur une bonne voie, qu'ils posent les bonnes questions.