Si quelqu'un vous propose une déclaration non vérifiée concernant les pratiques de développement de logiciels, répondez-vous par «citation nécessaire»? [fermé]

Récemment, j'ai assisté à une conférence donnée par Greg Wilson (scientifique en chef de la menuiserie logicielle). Du résumé:

L'idée selon laquelle les affirmations sur les pratiques de développement de logiciels devraient être fondées sur des preuves est encore étrangère aux développeurs de logiciels, mais cela commence enfin à changer: tout universitaire qui prétend qu'un outil ou une pratique particulier rend le développement de logiciels plus rapide, moins cher ou plus fiable est maintenant devrait étayer cette affirmation avec une sorte d'étude empirique.

Dans l'ensemble, la conférence a été très informative et m'a laissé réfléchir assez profondément à mon approche du développement. En particulier, je me retrouve maintenant à la recherche de citations pour sauvegarder un grand nombre de déclarations. Auparavant, j'avais pris l'habitude de simplement répéter les vérités proposées, avec peut-être une note mentale pour vérifier plus tard.

En termes francs, j'étais crédule .

Voici un exemple tiré de la conférence:

"Si plus de 25% du code doit être refactorisé, il est plus rapide de le réécrire".

Cela semble plausible, mais est-ce vrai? Où est l'étude étayant cela? Est-ce vrai pour toutes les langues? Etc.

OK, il est tout à fait possible de pousser cela à l'extrême et de ne rien croire de personne, sauf si vous l'avez dérivé vous-même des premiers principes. De cette façon réside la folie (ou peut-être les mathématiques ;-)). Mais, si quelqu'un vous présente une déclaration du type "Hé, en faisant cela dans [choisir la langue du moment], nous serons en mesure d'augmenter la productivité de [choisir un multiple de 10]%" êtes-vous enclin à l'accepter, ou allez-vous demander des preuves prouvées?

Si c'est ce dernier (et j'espère que oui) alors

1. où iriez-vous pour trouver ces preuves?
2. à quel point seriez-vous rigoureux?

En bref, si quelqu'un vous propose une déclaration non vérifiée, répondrez-vous par "citation nécessaire"?

Le problème avec ce genre d'énoncés est que même si vous aviez des preuves empiriques à l'appui de cette affirmation, il serait très difficile de déterminer si l'étude qui a mené aux preuves s'applique à votre situation actuelle.

Presque tout dans la profession comporte une mise en garde, ou plusieurs, de sorte que chaque amélioration à un endroit donné risque d'être un mauvais service ailleurs.

Les gens dans les tranchées connaissent la différence par l'expérience et n'ont généralement pas le financement / le temps / les ressources pour essayer de le prouver par une étude scientifique.

Les gens qui essaient de le prouver par une étude scientifique ont évidemment des ressources à consacrer à de telles études et sont donc très susceptibles de vous vendre quelque chose, donc je dirais que vous devriez appliquer encore plus rigoureusement votre propre expérience personnelle à tout ce qui prétend être étayé par des recherches empiriques.

Si quelqu'un vous disait "Si plus de 2% du code a besoin d'être refactorisé, il est plus rapide de le réécrire", vous saurez que c'est faux autant que si quelqu'un vous le dit "Seulement si plus de 98% du code a besoin d'être refactoré, c'est pour le réécrire plus rapidement ". Le nombre réel dépend de ce que vous faites et de l'idéal du code actuel.

L'idée qu'après un certain point il est plus facile de faire un refactor nucléaire est évidemment vraie dans de nombreux cas, mais le pourcentage réel est plus un exemple que vous devez considérer à travers la lentille de votre propre expérience (de l'équipe) et de la situation actuelle.

Si quelqu'un vous propose une déclaration non vérifiée concernant les pratiques de développement de logiciels, répondez-vous par «citation nécessaire»?

Non, je le poste ici et vois s'il obtient des votes positifs. La preuve sociale vaut mieux que pas de preuve!

De nombreux développeurs basent leurs décisions instantanées sur l'expérience des tranchées travaillant avec le code et les clients auxquels ce code sert.

Lorsqu'une classe ou une méthode est devenue tellement fragmentée par des corrections de bogues et des demandes de changement de client qu'elle est devenue impossible à maintenir, un développeur prendra parfois la décision de le réécrire plutôt que de le refactoriser, en supposant qu'il économisera du temps et des efforts à long terme , car le code résultant sera de meilleure qualité.

Ce type d'intelligence d'expérience est ce que les départements RH appellent «capital humain». C'est l'une des choses qui rend les développeurs expérimentés précieux, et l'une des raisons pour lesquelles les bonnes entreprises font des choses pour essayer de préserver la longévité de leurs employés.

Il ne semble pas juste ni même pratique de demander aux développeurs expérimentés de proposer une étude et des données empiriques comme preuve de la validité de leurs techniques. L'expérience ne fonctionne pas de cette façon. Au contraire, l'expérience est quelque chose d'un «sens ressenti». Dans le monde du refactoring, nous l'appelons souvent «odeur».

En fin de compte, une déclaration comme "Si plus de 25% du code doit être refactorisé, il est plus rapide de le réécrire" ne peut pas être prouvée fonctionner en toutes circonstances, donc la déclaration [citation-nécessaire] est vraiment un moyen d'informer le programmeur dogmatique qui cherche à forcer son point de vue sur les autres que ce n'est pas toujours «sa voie ou l'autoroute».

Je pense qu'avec tout ce que vous ne savez jamais jusqu'à ce que vous l'essayiez. Même avec une preuve pour sauvegarder une déclaration, il est toujours possible de plier les faits au profit de votre argument. Cela étant dit, vous ne devriez pas essayer chaque nouvelle chose qui frappe les interwebs. Faites votre meilleur jugement. N'oubliez pas que si quelque chose semble trop beau pour être vrai, c'est probablement le cas. Demandez-vous toujours pourquoi avez-vous besoin d'adopter quelque chose? Qu'avez-vous à gagner? Est-ce logique d'un point de vue commercial? Jamais aveuglé sauf quelque chose sur la foi.

L'exemple de la conférence est une heuristique, une règle de base et rien de plus. Cela devrait être implicitement évident.

L'heuristique est comme toute autre chose: elle est soumise à un certain contexte et dépend d'un certain nombre d'hypothèses non énoncées, et son utilité peut être très non déterministe. Il faut autant de jugement arbitraire pour les trouver utiles que pour les formuler en premier lieu.

Est-ce à dire qu'ils sont sans valeur? Je ne le dirais pas du tout.

L'heuristique est l'une des approches que nous pouvons adopter pour résoudre les problèmes NP-complets, et à bien des égards, l'ingénierie logicielle est elle-même un problème NP-complet.

Ça dépend. :) Lorsque la déclaration de quelqu'un contredit une expérience répétée, réfléchie et personnellement vérifiée, alors oui, je voudrais voir une sorte de référence d'une étude. D'un autre côté, si quelqu'un fait écho à une idée que vous avez vue et vécue plusieurs fois, il n'y a pas beaucoup de réaction provoquée (cela ne signifie pas pour autant que l'idée soit infaillible).

À titre d'exemple, le livre "Code Complete" cite des dizaines d'études dans chaque chapitre pour faire valoir ses points, parfois sur des sujets apparemment petits (comme l'indentation et l'espacement, ou la longueur de nom variable). Je me souviens de certains (plus jeunes) développeurs à qui j'ai présenté le livre en pensant que ce niveau de détail et de preuve était idiot. Mais quelques mois plus tard, avec plus d'expérience en codage de production et après quelques révisions de code, certains de ces mêmes développeurs ont eu l'honnêteté d'admettre que oui, même le nombre d'espaces en retrait importe. Les bons commentaires comptent. L'encapsulation est importante. etc.

À l'autre bout, lorsqu'un fournisseur prétend qu'un nouvel IDE est 50% plus productif, ma première réaction est bull $% ^ &!

N'est-ce pas quelque chose qui dépend de beaucoup de variables intangibles (variables qui n'ont aucun moyen d'être mesurées scientifiquement)?

À mon avis, ils parlent d'une méthode empirique pour mesurer les émotions. Quelque chose que même Spock ne pouvait pas accomplir. =)