Quello Non E' Il Mio Lavoro (?)
Vorrei ricollegarmi con un breve post di alcuni giorni fa che ha generato un paio di interessanti opinioni (che mi trovano in disaccordo), ed espandere se possibile la discussione. Il post era una mezza battuta relativa al fatto che i moderni "web developers" (e probabilmente molti altri tipi di "developers") non conoscono ne' capiscono le basi o la teoria dietro i databases e, in parecchi casi, tutto quello che e' appena oltre il loro "campo di azione". E peggio ancora non sembrano curarsene minimamente.
Ora, l'idea che ognuno debba essere pienamente competente nel proprio campo e' una buona idea e nessuno (me incluso) dice che voi non dobbiate essere competenti in quell'area. Il mio problema e' quando tale "area" diviene molto, molto piccola al punto che praticamente ogni altra cosa attorno cessa di essere "il vostro lavoro".
E' impossibile, o semplicemente poco conveniente, essere dei "tuttofare", semplicemente perche' richiede una montagna di tempo per diventarlo ed i risultati sono in genere mediocri (quando va bene). Certa gente riesce ad acquisire un quantitativo di skills sufficienti semplicemente svolgendo diverse attivita' per un certo tempo, operando in certi campi per un po' ed effettivamente cavandosela decentemente, ma molti tendono naturalmente a concentrarsi su alcune attivita' o campi che li interessano di piu' e quindi ad acquisire piu' esperienza in quei specifici campi, finendo con l'ignorare o evitare volontariamente tutto quello che non gli interessa. E va bene, fintanto che non danneggia la loro capacita' di fare quello che gli interessa.
Tuttavia, devo far notare che nel "mondo moderno" (specialmente in IT), e' parecchio raro che una qualunque disciplina o attivita' sia completamente indipendente da tutto il resto. In effetti, in molti casi una qualunque parte di una struttura IT e' talmente interconnessa con tutto il resto che un problema in una parte si riflette direttamente sull'intera struttura. Supponiamo che voi stiate scrivendo del codice per l'acquisizione di dati, questi 'dati' si suppone che verranno utilizzati da altre parti della struttura, e quindi il modo con cui li trattate nella fase di acquisizione avra' delle conseguenze sui modi in cui tali dati potranno essere trattati in altre parti (pensiamo semplicemente all'idea di memorizzare tutto come 'stringa' invece di differenziare i vari tipi di dati o eseguire dei controlli di sanita' sui dati invece di memorizzare ogni sorta di immondizia).
Con questo, non dico che ognuno dovrebbe conoscere tutto fino al minimo dettaglio, ma l'avere un'idea generale ed una conoscenza delle basi del tutto, sicuramente aiuta a comprendere ed identificare il migliore approccio ad uno specifico problema per evitare di causare un maggiore problema in un'altra parte del sistema dopo.
Ai "vecchi tempi" (come odio questo termine), c'erano Capi Progetto, Analisti ed Architetti di sistema, il cui compito era quello di guardare al "quadro d'insieme" della cosa e poi dividerlo e ridurlo nei minimi dettagli, fornendo a ciascuno un progetto dettagliato e chiaro di quello che si sarebbe dovuto realizzare. Ed il che avrebbe dovuto eliminare o ridurre di molto i problemi nel corso dell'opera. I "vecchi tempo" tuttavia, sono finiti da un pezzo ed la buzzword del momento e' Agilita', che sostanzialmente significa mettere insieme della roba il piu' in fretta possibile e non preoccuparsi troppo perche' tanto non durera' piu' di alcuni giorni e poi ci sara' da rifarla da capo o fare qualche cosa d'altro. E poi ci si meraviglia come e' che si finisce con l'avere un miliardo di bachi o roba che spesso non funziona.
Dato che oggi ognuno deve essere un 'designer' e responsabile per una porzione di quello che fa, dovrebbe essere interesse comune (e responsabilita' anche) di SAPERE almeno le basi delle parti con cui si hanno interazioni anche se non sono direttamente sviluppate.
Pertanto, uno sviluppatore che utilizza un database, ma non ha idea dei concetti e delle teorie di base comuni a tutti i database (nel senso di struttura e progetto dello stesso), finira' con il non usare tale database al meglio delle sue capacita', o peggio ancora, utilizzarlo in modo da ottenere le peggiori prestazioni possibili. A quel punto, di solito, la palla e' mollata all'amministratore di sistema per essere "risolta". E la "soluzione" in molti casi e' semplicemente aggiungere hardware al sistema. Quando funziona, e' uno spreco di risorse e quando non funziona.... non funziona.
Quindi no. Dire "non e' il mio lavoro", non e' accettabile. Non dal mio punto di vista almeno.
Davide Bianchi
13/11/2018 11:40
