Parfois la raison des informaticiens, d'ordinaire patiente et affutée, s'évanouit quand le problème à résoudre s'éloigne de la routine booléenne pour s'aventurer dans les pièges de la rhétorique, la manipulation marketing et l'enthousiasme geek.
Ainsi sent-on l'hystérie poindre quand les discussions abordent des points chauds comme :
- Y gagne-t-on vraiment à développer en TDD ?
- Les cheveux poussent-ils plus vite quand on les coupe ?
- Faut-il tout tester pour que ce soit utile ?
- L'intelligence est-elle innée ou acquise ?
- Un développeur expérimenté vaut-il deux développeurs débutants ?
- Faut-il, pour préserver la planète, préférer les mugs aux gobelets jetables ?
- Quel est l'impact des "assert" sur la qualité du soft ?
- Les fabriquants d'OGM ont-ils un intérêt à infléchir dans leur intérêt les études de toxicité qu'ils ont obligation de mener ?
- Peut-on faire du bon logiciel avec des équipes réparties aux quatre coins de la planète ?
Sûrement, chacune de ces questions réveillera vos déjeuners d'équipe malgré les rhumes de saison. D'ailleurs si vous en connaissez d'autres, n'hésitez pas à commenter. Mais ne pourrait-on pas aborder ces débats sous un angle rigoureux, scientifique, avec mesures et analyses, hypothèses et déductions ?
C'est justement le sujet de recherche des chercheurs de l'ESM (Empirical Software Engineering and Measurement Research Group) de Microsoft, qui curieusement s'en tiennent aux questions d'ingénierie informatique.
Ci-dessous quelques résultats de leurs travaux qui mettent les points sur les ı (ou les suppriment des ï, c'est selon -- notez en passant que le caractère unicode 305 a été inventé juste pour pouvoir écrire "mettre les points sur les ı").
To unit-test or not to unit-test ?
Le taux de couverture des tests est moins déterminant vis-à-vis de la qualité du produit (mesurée en nombre de bugs découverts après livraison) que le niveau de complexité du code testé et le niveau d'utilisation de ce code par le client.
Les équipes qui travaillent en TDD produisent du code supérieur (en termes de densité de bugs) de 60 à 90% au code produit par du développement non TDD. En contrepartie les projets TDD durent de 15 à 35% plus longtemps. Cf.http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf
To assert or not to assert ?
L'usage intensif d'assertions réduit le nombre de bugs.
L'impact des assertions sur la qualité du produit est d'autant plus grand que les développeurs sont expérimentés.
To fragment or not to fragment ?
Le degré de morcellement de la R&D est un facteur de bugs plus important que le niveau de "churn" du code, sa complexité ou son taux de couverture. Cf. The Influence of Organizational Structure on Software Quality: An Empirical Case Study.
L'éloignement des équipes impacte peu la qualité. Cf. Does distributed development affect software quality? An empirical case study of Windows Vista.
Source : Exploding Software-Engineering Myths. (exploding or exploring ?)
ça n’a rien à voir avec le sujet principal, mais le ı sans point est apparemment utilisé par le turc et l’azéri ;-) http://www.unicode.org/fr/charts/PDF/U0100.pdf (caractère 0x131)
Pour revenir au sujet de l’article, merci pour les informations !
Rédigé par : zigazou | 09 octobre 2009 à 07:52
On pourrait en imaginer un paquet d'autres...
Exemples qui me passent par la tête:
* La qualité d'un logiciel est-elle proportionnelle au poids des documents de spécifications et d'"assurance qualité" produits en amont?
* Eteindre son pc tous les soirs réduit-il la durée de vie de ses composants?
* Doit-on commenter son code source de manière détaillée ou doit-on considérer qu'un commentaire détaillé est un aveu de non-expressivité parfaite du code?
* Interfaces ou classes abstraites?
* Slip ou caleçon?
* Douche ou Bain?
* Beurre ou margarine?
etc... etc...
:)
Rédigé par : Num | 22 janvier 2010 à 17:03