Quando non è il caso di sperimentare
Giovedì 17 Luglio 2008 - 09:21
di Simone Carletti
Normalmente sono due le tipologie di sviluppatori (alcune volte manager) che si possono incontrare:
- L’irremovibile sedentario
- L’incontenibile innovatore
La prima figura è il classico individuo “arrivato”. Utilizza lo stesso linguaggio di programmazione da quando ha imparato che cosa fosse una stringa, non si è mai preoccupato di approfondire la conoscenza di qualcosa di nuovo e sperimentare una nuova tecnologia è più un problema che un’opportunità. Tipicamente rientra in questa categoria chi lavora in questo settore per necessità.
La seconda figura è il classico individuo irrefrenabile. È spesso confusionario, difficilmente arriva a completare un progetto senza aver cambiato almeno 3 volte strumenti dato che è sempre alla ricerca di quella tecnologia che l’amico o il blog di turno ha detto essere migliore di quella che sta usando lui. Non importa se sia una alpha preview, che vuol dire che quel linguaggio lo conoscono in 3 (l’autore, la moglie e l’amico)? Se hanno detto che è meglio del mio devo usarlo assolutamente!
Entrambi i casi sono volutamente sproporzionati ma, pensateci bene… siete proprio sicuri di non riconoscere in questa descrizione qualche vostro collega o magari proprio voi stessi?
Sviluppatore Sedentario vs Irrefrenabile
Lo sviluppatore sedentario è destinato ad essere scavalcato, a diventare obsoleto. L’aggiornamento è un punto fondamentale nel settore informatico come è già stato più volte ribadito in questo blog.
Difficile capire se l’individuo sedentario sia meglio o peggio di quello irrefrenabile. Quest’ultimo è altrettanto pericoloso. Non vi è mai capitato di trovarvi ad usare per la compilazione di un programma nel linguaggio X uno strumento scritto con il linguaggio Y solo perché quello che lo ha scritto stava provando se Y è veramente figo come dicono? Oppure, non vi è mai capitato di dover sviluppare un progetto che è ripartito per ben 4 volte solo perché ogni volta che si arrivava al punto X si scopriva che il framework Y era sorpassato, scaduto o semplicemente demodé?
Lo sviluppatore professionista dovrebbe essere consapevole di quando è il caso di sperimentare e quando, invece, è più opportuno utilizzare una tecnologia comprovata. La conoscenza e l’esperienza sono i due punti chiave sul quale basare un’analisi ed una decisione. Questa capacità diventa poi essenziale se la figura in considerazione ha un ruolo di gestione, come un project manager.
Ma quando sperimentare?
In alcuni casi è meglio non sperimentare
Di norma, la ricerca e sviluppo è un’attività che non dovrebbe mai mancare in un’azienda, soprattutto se di carattere informatico. Purtroppo, questa prassi è spesso ignorata o semplicemente condotta con una inconsistenza tale da renderla inefficace.
Esistono però alcuni momenti in cui è opportuna una scelta alternativa.
Deadline imminente
Adottare una nuova tecnologia in occasione di una deadline non è una scelta razionale.
Ad esempio, eseguire un refactoring completo del codice di compilazione del vostro programma sul ramo principale di sviluppo proprio in occasione del rilascio della nuovissima Release 1.0 non è saggio. Più saggio è creare un ramo parallelo (branch) dove sperimentare le modifiche al nuovo strumento di compilazione e, eventualmente, integrare le modifiche in seguito al rilascio nel periodo “di riflessione” che normalmente segue il rilascio di una release, prima di una nuova iterazione di sviluppo.
Tecnologia isolata
Se la vostra azienda utilizza Python ed il vostro programma è scritto completamente in Python, utilizzare Rake o Ant per scrivere le vostre routine non è una scelta opportuna. Non lasciatevi attrarre da una tecnologia in quanto tale in modo isolato. Se per qualche motivo gli script dovessero interagire (come di solito avviene) con il sorgente principale, potrebbe non essere così semplice dover far dialogare tra loro Python e Java o Ruby e Python.
Funzionalità critiche
Prestate attenzione affinché nessuna tecnologia critica per il vostro sviluppo diventi un banco di prova per nuovi esperimenti.
Ad esempio, nella vostra azienda ci sono 10 team di sviluppo ognuno dei quali composto da 5 persone coordinate da un project manager. Ogni team lavora in parallelo su più progetti grazie alla separazione dei software in livelli e componenti. Il codice sorgente dei team è gestito da Subversion e diversi tool interni, come ad esempio il vostro script per il deploy, si basano su questa struttura oramai rodata. Altri sistemi per il controllo di versione stanno emergendo velocemente. Strumenti distribuiti come Mercurial e GIT sono spesso considerati superiori a Subversion.
In questo esempio, il sistema di gestione del codice è una funzionalità critica del processo di sviluppo dell’azienda. Sperimentare un nuovo sistema di gestione del codice in quest’area è quindi un passo molto pericoloso che va affrontato con la massima cura.
Innanzitutto, scegliete un singolo team. Verificate l’attitudine del team al test di nuove tecnologie ed assicuratevi di affiancare la nuova tecnologia alla vecchia per un periodo di tempo sufficiente. State certi che non è sufficiente leggere 10 manuali o centinaia di articoli per conoscere uno strumento… è necessario usarlo.
Assicuratevi che il team di test sperimenti la tecnologia su un componente che, in caso di problemi, non limiti l’attività degli altri team.
Non delegate la sperimentazione di una tecnologia ad una sola persona poiché il risultato potrebbe essere forzatamente influenzato (in positivo o negativo).
Assicuratevi inoltre di verificare attentamente tutti gli strumenti correlati alla nuova tecnologia che state utilizzando, prima di procedere ad una (progressiva) integrazione della nuova tecnologia. Non siate frettolosi! La fretta non paga.
In conclusione
Anche se alcuni o (forse) molti dei punti discussi in questo post potrebbero sembrarvi ovvi, vi assicuro che non lo sono affatto. Se lo fossero, in giro ci sarebbero molti più professionisti e molti meno scempi rispetto a certi software/progetti/portali distribuiti o commercializzati.
Ho cercato il più possibile di fornire esempi concreti di ciascun problema poiché spesso, con gli esempi, è più facile comprendere ed immedesimarsi. Non so voi, ma anche nella lettura di suggerimenti banali a volte mi capita di vedere l’applicazione di un esempio e dire… cavolo, questa cavolata l’ho fatta anche io! :)
Commenti
1
Hai parlato di tecnologie, e source control, ma per sperimentazione o innovazione io intendo anche una innovativa, flessibile, o ad hoc, metodologia di sviluppo coordinato.
Spesso non e’ solo il linguaggio, il problema, ma come lo si utilizza. Lo scempio di cui parli, e sulla quale mi trovi d’accordo, e’ spesso dato piu’ dalla superficiale conoscenza di un linguaggio (i parzialmente seduti, programmatori passivi che dopo 2 libri si sentono esperti), che dalle tecniche di gestione source, o framework adottato.
Inutile passare a Django, se il codice, qualche chiamata a parte, continua ad essere scritto ad monnezzum, per fare un esempio.
Per concludere, questa frase io la ripeto da credo 9 anni:
State certi che non è sufficiente leggere 10 manuali o centinaia di articoli per conoscere uno strumento… è necessario usarlo
ma, ogni volta che l’ho espressa, mi hanno sempre puntato il dito contro, soprattutto gli irremovibili, per lo piu’ “datati” e seduti, “professionisti informatici”, incontrati in questi anni, persone saccenti che parlano “per conto terzi”, senza avere idea di come scrivere una sola linea di codice sensata.
Complimenti per il post e buona giornata.
2
io sinceramente mi ritengo innovatore pazzo sperimentatore e folle malato di tutto ciò che è nuovo.. :P
# - postato da Davide Espertini - 17 Luglio 2008 - 10:35
3
Tra i due preferisco sicuramente la figura “irrefrenabile”, in passato l’aver adottato (e osato un pochettino), tecnologie che pochi usavano ci ha permesso di acquisire l’esperienza e la padronanza giusta al momento che sono diventate “standard”. Nello sviluppo dei progetti web è sempre necessario cercare di essere un passo avanti, l’evoluzione è così veloce che ci è capitato in un progetto molto grande il cui sviluppo è durato un anno di dover rivedere alcune tecnologie che nel frattempo si erano evolute.
# - postato da Oliver Astrologo - 17 Luglio 2008 - 11:19
4
Ragazzi quanto è vero. Per quel che mi riguarda sarebbe meglio averle tutte e due queste figure. Altrimenti chi fa il lavoro noioso?:)
# - postato da eugenio ambrosi - 17 Luglio 2008 - 11:33
5
Io aprirei anche una ulteriore diatriba: focalizzarsi su una attivita’ o abbraciarne molte?
Spesso, sia per la mia irrefrenabile voglia di sperimentare sia per esigenze lavorative, mi sono ritrovato a lavorare con tecnologie molto diverse da loro.
Esempio? Ho iniziato ovviamente con l’HTML, poi sono passato ad ASP, poi sono passato ad ACTIONSCRIPT, poi a XHTML e CSS, poi un po’ da SISTEMISTA WIN, poi a RUBY ON RAILS, poi ancora indietro a XHTML e CSS, ora di nuovo ACTIONSCRIPT.
Il tutto partendo da ambienti windows, passando a sistemi linux ed approdando ora su osx. :DInsomma credo di aver provato davvero di tutto e alla fine sono ben formato in tutte queste discipline. Il problema sorge pero’ quando bisogna aggiornarsi. Con Flash ad esempio mi ero fermato all’8 mentre ora sto reimparando tutto con AS3, OOP, librerie come PV3D etc…
Insomma… io sono contento di provare sempre cose diverse… ma dopo 7 anni incomincio a chiedermi se non sarebbe meglio fermarsi su una tecnologia e cercare di diventare proprio dei GURU su quella e basta.
Oggi giorno tutto si muove a velocita’ impressionanti… e mi trovo davvero in difficolta’ nel cercare di mantenere il passo su tecnologie cosi’ diverse fra loro!
Secondo voi e’ quindi meglio rimanere un “tuttologo” o provare a impegnarsi in tutto e per tutto su una tecnologia singola?
# - postato da Andrea - 17 Luglio 2008 - 14:19
6
Anche se come dice Simone possono sembrare ovvie alcune cose, è sempre meglio fermarsi e riflettere su quello che si sta facendo.
Io sono più uno sperimentatore, ma credo che la maggior parte di quelli che leggono qui sono tali (un’irremovibile sedentario probabilmente nemmeno legge blog come questo).
Anche io come Andrea da qualche hanno sono nel settore, e ho provato a fare di tutto, dal tecnico di networking, all’amministratore linux al programmatore php, e ora sto cominciando a lavorare in modo produttivo con javascript.
Putroppo secondo me al giorno d’oggi a meno di sacrificare la vita sociale e le ore di sonno spesso la sperimentazione passa da un progetto in sviluppo.
Sono oberato dal lavoro e se mi metto al pc di notte (come capita sempre più spesso) non è certo per sperimentare ma per portare a termine il progetto che devo consegnare a breve.Cosi nei limiti dei dettami del buon senso citati da simone mi trovo a sperimentare sui progetti, e non su pezzetti di codice solo per il gusto di provare.
Aspiro a raggiungere uno standard che mi permetta di stravolgere il meno possibile il codice di partenza del progetto precedente per migliorare quello successivo.
Per rispondere ad Andrea, credo che il giusto sia la via di mezzo, se non fossimo interessati alle diverse tecnologie probabilmente una volta diventati guru di un linguaggio diventeremmo dei sedentari.
Come i calciatori, dobbiamo avere un piede preferito, ma non disdegnare l’uso dell’altro :-)# - postato da Giovanni Battista Lenoci - 17 Luglio 2008 - 14:34
7
Concordo con Giovanni. Anche se non sono molti anno che programmo, mi sono dato molto da fare nel conoscere( ed imparare ovviamente ) il maggior numero di linguaggi. Sono passato da php, sql, javascript, vbscript, html e tutti gli altri linguggi usati nelle applicazioni.
A lungo andare mi sono reso conto che non è possibile mettersi a testa bassa ed imparare tutto, bisogna sempre fare una scelta. La mia è stata quella di studiare veramente bene un solo linguaggio per tipo( C per applicazioni , php per internet ) mentre gli altri li ho visti in superfice, tanto per conoscerli.
Perché sono convinto che un programmatore debba riuscire ad adattare le sue conoscenze in modo generico. Se conosci bene la teoria di una cosa, poi non ci sono veri problemi nell’adattarla ad altri contesti.
Per gli aggiornamenti poi è impossibile stare al passo con la velocità con cui escono nuovi progetti. L’unico modo secondo me è, nel momento del bisogno, vedere tutte le nuove e vecchie possibilità e compararle, trovando quella che meglio si adopera a risolvere il nostro problema.# - postato da Lorenzo - 17 Luglio 2008 - 16:09
8
una voce fuori dal coro: io non sono un incontenibile innovatore… anzi. però ne sono fiero! :-)
9
Andrea, io come te passo quotidianamente da PHP, JavaScript, ActionScript, Python, MySQL, SQLite, XML, CSS, XHTML, C# quando capita o XSLT, di cui almeno 2 linguaggi di programmazione, Python e PHP per lo più, per crontabs in linux e/o shell scripts cross platform (quindi anche sistemista programmatore, seppur non mi senta tale in alcun modo), per questo ti capisco benissimo.
La tua domanda è quindi più che lecita, ma la risposta non è abbastanza aperta … hai mai pensato al “gurologo”? :P
Fermarsi ad una sola teconologia non basta, un guru C (o altro) che non è guru anche di altro ha vita lunghissima o brevissima, quindi secondo me, continua ad approfondire al massimo ogni singolo linguaggio che hai incotrato, usato, e con il quale ti sei fatto ossa e barba, tutti i giorni, poichè essere guru di una sola tecnologia è, secondo me, contro producente, mentre saperle tutte (o anche poche) sommariamente è, sempre secondo me, completamente inutile, da cambiare lavoro, a meno che non ci si dichiari, e giudichi, un hobbista, o un semplice appassionato, sacrosanto diritto.
Sunto, appoggio in pieno Giovanni Battista Lenoci (GBL come nick, no eh? :D), la giusta via è nel mezzo, senza mai abbandonare quanto appreso durante il cammino. Opinione personale.
10
Sunto, appoggio in pieno Giovanni Battista Lenoci (GBL come nick, no eh? :D), la giusta via è nel mezzo, senza mai abbandonare quanto appreso durante il cammino. Opinione personale.
Mi avete scoperto, era un modo per far indicizzare il mio nome da google! :P
ok, d’ora in poi mi firmo come gianiaz anche qui :-)
Ciao
11
Grazie per le vostre risposte…
Il mio dubbio nasce cmq da una constatazione:
di veri guru ce ne sono pochi, per guru intendo proprio gente con le strapalle (perdonatemi il termine) non una persona che semplicemente conosce “bene” un linguaggio… ma qualcuno conosciuto nell’ambiente, che scrive libri, partecipa come speaker a convegni e meeting… e ovviamente non si puo’ raggiungere tale livello in tutte le diverse discipline.
Ultimamente sto incominciando a fare un po’ di considerazioni pecuniarie e mi sto rendendo conto che paga molto di piu’ avvicinarsi alla figura del guru piuttosto che rimanere mediocri su tante discipline diverse.
Da qualche mese mi sono trasferito a Londra e vedo ogni giorno gente davvero davvero davvero in gamba su un tema specifico e per questo vengono pagati fior fior di soldi.
E cosi’ ho incominciato a riflettere un po’ sull’argomento…# - postato da Andrea - 18 Luglio 2008 - 13:24
12
Ho il piede in 2 scarpe ^_^
Lavoro con passione quindi sono sempre alla ricerca di nuovi stimoli… ma quando ti trovi a dover chiudere un lavoro (x fatturare :D ) non stai a perdere tempo a sperimentare l’ultima ver dello script o l’ultimo framework js!!!