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

Il problema con questo tipo di affermazioni è che anche se tu avessi prove empiriche a sostegno del reclamo, sarebbe molto difficile determinare se lo studio che porta all'evidenza applicata alla tua situazione attuale.

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

Le persone in fondo alle trincee conoscono la differenza attraverso l'esperienza e generalmente non hanno il finanziamento / tempo / risorse per provare a dimostrarlo attraverso uno studio scientifico.

Le persone che cercano di dimostrarlo attraverso uno studio scientifico hanno ovviamente delle risorse da dedicare a tali studi e quindi sono altamente propensi a venderti qualcosa quindi direi che dovresti applicare ancora più severamente la tua esperienza personale a qualsiasi cosa che sostiene di essere supportato da ricerche empiriche.

Se qualcuno ti dicesse "Se più del 2% del codice ha bisogno di refactoring, è più veloce riscriverlo" lo sapresti essere falso tanto quanto se qualcuno ti dicesse "Solo se più del 98% del codice ha bisogno refactoring, è più veloce riscriverlo ". Dove il numero effettivo dipende da cosa stai facendo e quanto lontano dall'ideale è il codice corrente.

L'idea che dopo un certo punto è più facile fare un refattore nucleare è ovviamente vera in molti casi, ma la percentuale effettiva è più di un esempio che devi considerare attraverso la lente della tua esperienza (di squadra) e situazione attuale.

If someone offers you an unverified statement regarding software development practices, do you respond with “citation needed”?

No, lo metto qui e vedo se ottiene qualche upvotes. 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 servono a quel codice.

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

Questo tipo di esperienza di 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 cose per cercare di preservare la longevità della loro gente.

Non sembra giusto o addirittura pratico chiedere agli sviluppatori esperti di elaborare uno studio e dati empirici come prova che le loro tecniche sono valide. L'esperienza non funziona in questo modo. Al contrario, l'esperienza è qualcosa di "felt sense". Nel mondo del refactoring, spesso lo chiamiamo "odore".

In definitiva, una dichiarazione del tipo "Se è necessario refactoring più del 25% del codice, è più veloce riscriverlo" non può essere dimostrato che funzioni in tutte le circostanze, quindi la dichiarazione [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 la strada".

Penso a tutto ciò che non sai mai finché non lo provi. Anche con la prova per eseguire il backup di una dichiarazione, è sempre possibile piegare i fatti a vantaggio del tuo punto. Detto questo non dovresti provare ogni nuova cosa che colpisce l'interwebs. Fai il tuo miglior giudizio. Ricorda, se qualcosa è troppo bello per essere vero, probabilmente lo è. Chiediti sempre perché hai bisogno di adottare qualcosa? Che cosa hai da guadagnare? Ha senso da una prospettiva di business? Mai accecato tranne qualcosa sulla fede.

L'esempio della lezione è un euristico, una regola empirica e nient'altro. Questo dovrebbe essere implicitamente ovvio.

Le euristiche sono come qualsiasi altra cosa: sono soggette a un certo contesto e dipendono da un numero qualsiasi di assunzioni non dichiarate, e la loro utilità può essere molto non deterministica. Altrettanto arbitrario è il giudizio nel trovarli utili, come va in primo luogo nella formulazione.

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 è di per sé un problema NP-completo.

Dipende. :) Quando la dichiarazione di qualcuno contraddice l'esperienza ripetuta, riflessa 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 comunque infallibile).

Ad esempio, il libro "Code Complete" cita decine di studi in ciascun capitolo per fare i suoi punti, a volte su argomenti apparentemente piccoli (come indentazione e spaziatura, o lunghezza del nome variabile). Ricordo alcuni (più giovani) sviluppatori che ho presentato al libro pensando che quel livello di dettagli e prove fosse sciocco. Ma pochi mesi dopo con più esperienza nella codifica della produzione e dopo alcune revisioni di codice, alcuni di quegli stessi sviluppatori hanno avuto l'onestà di ammettere che sì, anche il numero di spazi in indentazione è importante. I buoni commenti contano. L'incapsulamento conta. ecc. ecc.

Dall'altra parte, quando un venditore afferma che un nuovo IDE è il 50% più produttivo, la mia prima reazione è bull $% ^ &!

Non è qualcosa che dipende da un sacco di variabili intangibili (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. =)