<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-03-10 14:21 GMT+00:00 Giovanni Porcari <span dir="ltr"><<a href="mailto:giovanni.porcari@softwell.it" target="_blank">giovanni.porcari@softwell.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>Si. Tutto vero. Tutto sacrosanto. Tutto giusto.<br>
<br>
Però come dicevo in un'altra mail è un problema di risorse che puoi avere e non avere<br>
e le compatibilità economiche non sono meno importanti di quelle tecniche.<br></blockquote><div><br></div><div>Si, appunto. Per determinati business (che so, se fai servizi web based) il costo di un baco in produzione sufficientemente grave puo' anche nella peggiore delle ipotesi farti chiudere baracca. Se i clienti perdono fiducia nel tuo business, semplicemente non hai piu' clienti (per lo meno, nel lungo termine). Se il business fa billing sulla base delle transazioni dei clienti, downtime vuole dire potenzialmente milioni di dollari di mancate entrate. In ogni caso probabilmente hai delle SLA che devi rispettare, e se non le rispetti devi sbatterti non poco per scusarti (e generalmente tutto questo coinvolge ancora una volta mancate entrate)</div><div><br></div><div>Certo, se vendi software "boxed" sei in un mondo completamente diverso. Come e' diverso se vendi soluzioni custom per clienti singoli, e magari ti va anche bene. Eh, scusa, eravamo giu' per un paio di ore, ma dai, non ti preoccupare. In altri casi questo e' un pochetto piu' complicato. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Non posso parlare per altri ma solo per me. Lavoro in questo ambito da più di 40 anni<br>
e non ho mai infilato in produzione dei bachi che non fossero 'cosmetici'.<br></blockquote><div><br></div><div>Eh... che dire. Bravi. La mia esperienza, sebbene molto piu' breve, e' tutta diversa. </div><div><br></div><div>Diciamo cosi'... l'esperienza (breve finche' vuoi) mi insegna a diffidare molto di questo tipo di affermazioni. </div><div><br></div><div>Nel mio mondo, la parola chiave e' "build to fail". I sistemi falliranno. Il trucco e' essere sufficientemente ridondanti. E il costo ingegnere di scrivere un test e' assolutamente *nullo* rispetto al costo di tenere in piedi la baracca (che a sua volta e' completamente trascurabile rispetto al costo di fallire davvero). </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Che poi questo dipenda da fortuna, capacità, senso di responsabilità o attenzione non lo so.<br></blockquote><div><br></div><div>La fortuna non perdura in eterno, il senso di responsabilita' non aiuta (ovvero, l'incoscienza chiaramente rema contro, ma non direi che e' un problema di "senso di responsabilita'"). Attenzione? Forse. Ma vuole anche dire che il business ha tempi molto lenti (o se vuoi "umani"). Ma soprattutto, non e' una garanzia. Perche' sei attento fino alla volta in cui sei disattento.</div><div><br></div><div>Se vai a vedere come gestiscono le cose quelli che *non* possono permettersi bachi *per nulla* (sarebbe piuttosto sgradevole un 404 con l'omino dei lavori in corso sul monitor del 747 che sta precipitando con 500 persone a bordo -- sorry, we are working for you: ATC will be online in a couple of hours, please consult your onboard spiritual advisor for your last prayers). Beh... vedrai che non ti parlano di "attenzione" e "senso di responsabilita'". Semmai hanno svariati team di QA che fanno test manuali, automatici, randomizzati e pagano licenze piuttosto costose per tool che fanno analisi statica e dimostrano l'assenza di determinati bachi in determinate parti del codice. E a volte tutto questo si rompe e nonostante tutto si va Arianne 5.</div><div><br></div><div>Ora tutto questo ha un costo immenso. Per lo meno vuole dire un ciclo di sviluppo cosi' lungo che nel mio mondo saremmo tutti fuori dal business. E quindi via di compromessi. Oltretutto un moderno sistema software e' *molto* piu' complicato della maggior parte dei sistemi mission critical di quel tipo (principalmente perche' il costo di non introdurre una feature puo' essere molto piu' alto del costo del rischio di un downtime).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Forse il rovescio della medaglia è che se ti convinci che i test comunque ti parano il culo<br>
tendi a lavorare con il medesimo.<br></blockquote><div><br></div><div>"True man do not write bugs". No. La gente scrive i test quando lavora bene. Se non scrive i test, dal mio punto di vista, sta lavorando con il culo. Ci sono talmente tante buone ragioni per scrivere i test... e quale ragione per non scriverli? Risparmio tempo? In generale si dimostra che non e' manco vero che si risparmia tempo sul lungo termine. Poi certo, se uno se la gioca tutta sul fatto che "va in bancarotta sul debito tecnico" ok... ma non e' un gran piano nel caso generale.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Un po' come l'acrobata che cammina sul filo senza la rete sotto: o sta attento o è un uomo morto.<br></blockquote><div><br></div><div>Ecco... ma noi siamo acrobati che lavorano troppe ore al giorno su un filo invisibile con illuminazione a lume di candela fatta dal pubblico sottostante. E il filo non e' dritto ma va un po' di qua e un po' di la. E un orso ubriaco con la faccia di Bruce Campbell ci sta inseguendo con una motosega al posto della zampa destra.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Io non dico che avere un'ottima copertura dei test sia sbagliato anzi, è una cosa meravigliosa.<br>
Dico solo che io, purtroppo, non me la posso permettere :)<br></blockquote><div><br></div><div>E io non conosco il tuo business, per cui non posso e non voglio commentare oltre. I tuoi clienti sono contenti, restano, e ne continuano ad arrivare di nuovi? Allora vuole dire che stai facendo bene quello che fai. Puro e semplice. </div><div><br></div><div>Detto questo, io non sono affatto convinto che tu non te lo possa permettere: di solito quando hai una buona infrastruttura di testing vai molto piu' veloce a fare tutto. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Se questo significa lavorare ammerda pazienza. Per ora con questa 'ammerda' ho mangiato e<br>
non ho mai messo in difficoltà i miei clienti :)<br></blockquote><div><br></div><div>Ottimo. Mi fa piacere che per te funzioni. Vorrei solo che sia chiaro che non e' un caso generale che sia facilmente estensibile ad altri business in modo automatico. Appena cambi un pochetto le regole del business e' facile che non funzioni piu' tanto bene.</div><div><br></div><div><br></div></div>-- <br><div class="gmail_signature"> .<br>..: -enrico-</div>
</div></div>