Ho appena letto un bellissimo post di Roberto Messora, nel quale Roberto evidenzia come cercare la perfezione lo porta spesso ad essere meno produttivo e da li si parte su un discorso più ampio.
Con l'uscita di EF infatti MS ha "Sdoganato" gli orm, ora che si ha un ORM di casa Microsoft tutti si interrogano sul: è utile? può aiutarmi nel mio lavoro di tutti i giorni? etc, etc e contemporaneamente sempre più si parla di pattern, progettazione OO, e chi più ne ha più ne metta.
Il problema di questo interesse verso le nuove tecnologie è che si perdano di vista le necessità degli stakeholder, siano essi i committenti del progetto, ma più spesso anche gli utenti che andranno ad utilizzare il software stesso, con il rischio che il prodotto completo alla fine non soddifi le reali esigenze.
La domanda fondamentale che ogni sviluppatore/architetto/modellista software deve porsi, prima di decidere quale metologie adottare, è: "l'adozione delle tecnologie/pattern/principi X Y Z può aiutarmi a scrivere software che soddisfi maggiormente gli stakeholder?". Il problema nasce quando la domanda in realtà è: "Usare le tecnologie/pattern/principi X Y Z mi fa scrivere software che soddisfi maggiormente me stesso che lo scrivo o altri sviluppatori che poi ci lavoreranno?".
Sarà che ho letto recentemente "Why software sucks", ma la sostanza è che noi sviluppatori/architetti/modellisti diamo al software pesi pesi differenti dai nostri stakeholder e tendiamo a dare maggiore enfasi a caratteristiche del codice che a conti fatti, non portano nessun beneficio osservabile per chi poi il software lo usa veramente. Il problema quindi è adottare una tecnologia solo quando ci aiuta a scrivere software migliore (per gli altri, non per noi stessi) e non invece solo perchè ci piace o perchè è di moda.
Un esempio classico è il Testing, argomento controverso e molto attuale. Il rischio è che si passi da una situazione in cui i progetti non hanno nemmeno un test automatizzato, ad una in cui si perde tempo solo per raggiungere 100% code coverage, oppure ancora peggio, si adottano architetture particolari con la sola ragione di rendere il software Testabile. Alla fine dei conti al cliente non importa nulla se gli facciamo vedere una schermata di NCover che mostra come ogni linea di codice sia stata testata. ;)
Alla fine tutto questo discorso può comunque essere riassunto da una bellissima frase di Raf a commento del post di Roberto.
"La conoscenza è "obbligatoria" per fare il mestiere, saper scegliere è quello che fa la differenza."
Da qui ne discende che è sempre bene cercare di aumentare sempre il più possibile le proprie conoscenze, ma cercare nel contempo di capire a fondo dove realmente applicarle e dove no.
Alk.