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! :)