Se qualcuno ti offre una dichiarazione non verificata relativa alle pratiche di sviluppo del software, rispondi con "citazione necessaria"? [chiuso]

Di recente ho partecipato a una conferenza tenuta da Greg Wilson (Chief Scientist of Software Carpentry). Dall'abstract:

L'idea che le affermazioni sulle pratiche di sviluppo del software dovrebbero essere basate su prove è ancora estranea agli sviluppatori di software, ma questo sta finalmente iniziando a cambiare: qualsiasi accademico che afferma che un particolare strumento o pratica rende lo sviluppo del software più veloce, economico o più affidabile è ora si aspettava di sostenere tale affermazione con una sorta di studio empirico.

Nel complesso, la lezione è stata molto istruttiva e mi ha lasciato riflettere molto profondamente sul mio approccio allo sviluppo. In particolare, ora mi ritrovo a cercare citazioni a sostegno di molte dichiarazioni. In precedenza, avevo preso l'abitudine di ripetere semplicemente le verità offerte, con forse una nota mentale per andare a controllare più tardi.

Per dirla senza mezzi termini, stavo diventando credulone .

Ecco un esempio tratto dalla lezione:

"Se oltre il 25% del codice deve essere sottoposto a refactoring, è più veloce riscriverlo".

Sembra plausibile, ma è vero? Dov'è lo studio a sostegno di questo? È vero per tutte le lingue? E così via.

OK, è del tutto possibile portare questo all'estremo e non credere a nulla da nessuno a meno che tu non l'abbia derivato dai primi principi. In questo modo sta la follia (o forse la matematica ;-)). Ma, se qualcuno ti viene incontro con una dichiarazione sulla falsariga di "Ehi, facendo questo in [scegli la lingua del momento] saremo in grado di aumentare la produttività del [scegli multipli del 10]%" sei propenso a accettalo o chiederai prove comprovate?

Se è quest'ultimo (e spero lo sia) allora

1. dove andresti a trovare queste prove?
2. quanto saresti severo?

In breve, se qualcuno ti offre una dichiarazione non verificata, risponderai con "citazione necessaria"?

Il problema con questo tipo di affermazioni è che anche se avessi prove empiriche a supporto del reclamo, sarebbe molto difficile determinare se lo studio che ha portato alle prove si è applicato alla tua situazione attuale.

Quasi tutto nella professione ha un avvertimento, o diversi quindi ogni miglioramento in un posto ha la probabilità di essere un disservizio da qualche altra parte.

Le persone giù nelle trincee conoscono la differenza attraverso l'esperienza e generalmente non hanno i finanziamenti / il tempo / le risorse per provare a dimostrarlo attraverso uno studio scientifico.

Le persone che provano a dimostrarlo attraverso uno studio scientifico hanno ovviamente risorse da dedicare a tali studi e sono quindi molto propensi a venderti qualcosa, quindi direi che dovresti applicare ancora più rigorosamente la tua esperienza personale a tutto ciò che afferma di essere supportato dalla ricerca empirica.

Se qualcuno ti dicesse "Se è necessario il refactoring per oltre il 2% del codice, è più veloce riscriverlo", sapresti che è falso come se qualcuno ti dicesse "Solo se più del 98% del codice necessita di refactoring, è più veloce a riscriverlo ". La posizione del numero effettivo dipende da ciò che si sta facendo e dalla distanza dall'ideale del codice corrente.

L'idea che dopo un certo punto sia più facile eseguire un rifrattore nucleare è ovviamente vera in molti casi, ma la percentuale effettiva è più di un esempio che è necessario considerare attraverso l'obiettivo della propria esperienza (della squadra) e della situazione attuale.

Se qualcuno ti offre una dichiarazione non verificata relativa alle pratiche di sviluppo del software, rispondi con "citazione necessaria"?

No, lo pubblico qui e vedo se ottiene voti. La prova sociale è meglio di nessuna prova!

Molti sviluppatori basano le loro decisioni momento per momento sull'esperienza nelle trincee che lavorano con il codice e con i clienti che quel codice serve.

Quando una classe o un metodo è diventato così frammentato da correzioni di bug e richieste di modifica da parte del cliente da renderlo non mantenibile, uno sviluppatore a volte prenderà la decisione di riscriverlo piuttosto che refactor, secondo la teoria che farà risparmiare tempo e fatica a lungo termine , perché il codice risultante sarà di qualità superiore.

Questo tipo di esperienza intelligence è ciò che i dipartimenti delle risorse umane chiamano "capitale umano". È una delle cose che rende preziosi gli sviluppatori esperti e uno dei motivi per cui le buone aziende fanno le cose per cercare di preservare la longevità della loro gente.

Non sembra giusto o nemmeno pratico chiedere agli sviluppatori esperti di elaborare uno studio e dati empirici come prova della validità delle loro tecniche. L'esperienza non funziona in questo modo. Al contrario, l'esperienza è una sorta di "senso sentito". Nel mondo del refactoring, spesso lo chiamiamo "odore".

In definitiva, un'affermazione come "Se oltre il 25% del codice necessita di refactoring, è più veloce riscriverlo" non può essere dimostrata in tutte le circostanze, quindi l'affermazione [citazione necessaria] è davvero un modo per informare il programmatore dogmatico che cerca di forzare le sue opinioni sugli altri che non è sempre "La sua strada o l'autostrada".

Penso a tutto ciò che non sai mai fino a quando non lo provi. Anche con la prova a sostegno di un'affermazione, è sempre possibile piegare i fatti a beneficio del tuo punto. Detto questo, non dovresti provare ogni cosa nuova che colpisce le interwebs. Dai il tuo miglior giudizio. Ricorda, se qualcosa sembra troppo bello per essere vero, probabilmente lo è. Chiediti sempre perché devi adottare qualcosa? Cosa devi guadagnare? Ha senso dal punto di vista commerciale? Mai accecato tranne qualcosa sulla fede.

L'esempio della lezione è un euristico, una regola empirica e niente di più. Ciò dovrebbe essere implicitamente ovvio.

L'euristica è come qualsiasi altra cosa: sono soggetti a un determinato contesto e dipendono da un numero qualsiasi di ipotesi non dichiarate e la loro utilità può essere molto non deterministica. Tanto giudizio arbitrario finisce per trovarli utili quanto in primo luogo nel formularli.

Ciò significa che sono senza valore? Non lo direi affatto.

L'euristica è uno degli approcci che possiamo adottare per affrontare i problemi NP-completi e, per molti aspetti, l'ingegneria del software è esso stesso un problema NP-completo.

Dipende. :) Quando l'affermazione di qualcuno contraddice l'esperienza ripetuta, riflessiva e verificata personalmente, allora sì, vorrei vedere una sorta di riferimento di uno studio. D'altra parte, se qualcuno fa eco a un'idea che hai visto e vissuto molte volte, non c'è molta reazione provocata (non significa che l'idea sia infallibile però).

Ad esempio, il libro "Codice completo" cita decine di studi in ogni capitolo per evidenziarne i punti, a volte su questioni apparentemente piccole (come rientro e spaziatura o lunghezza del nome variabile). Ricordo alcuni sviluppatori (più giovani) ai quali ho presentato il libro pensando che quel livello di dettaglio e prove fosse sciocco. Ma pochi mesi dopo con più esperienza nella codifica di produzione e dopo alcune revisioni del codice, alcuni di quegli stessi sviluppatori hanno avuto l'onestà di ammettere che sì, anche il numero di spazi nella rientranza è importante. I buoni commenti contano. L'incapsulamento conta. ecc ecc.

D'altra parte, quando un fornitore afferma che un nuovo IDE è più produttivo del 50%, la mia prima reazione è di $ $ ^ ^ &!

Non è qualcosa che dipende da molte variabili immateriali (variabili che non hanno modo di essere misurate scientificamente)?

Secondo me, stanno parlando di un metodo empirico per misurare le emozioni. Qualcosa che nemmeno Spock poteva realizzare. =)