Le diverse facce dello sviluppo
In campo informatico esiste una grandissima varietà di programmatori, un po’ come per ogni mestiere esistono molti tipi di lavoratori: quelli perfezionisti che vogliono sempre che tutto sia a posto, quelli trasandati che trasmettono il disordine anche al loro lavoro, quelli teorici che non si preoccupano del lato realizzativo e quelli pratici che invece mettono al centro della loro attenzione i tempi di elaborazione e quindi cercano di moderare tutto intorno ad essi. Questi sono naturalmente tutti estremi (e a ben vedere ce ne sarebbero ancora moltissimi altri), ma in parte sono un quadro della realtà.
Il confronto da me percepito principalmente, è quello tra teorici e pratici: ove il teorico si perde nei suoi ragionamenti tendendo a strafare in design che non si avrà mai il tempo per realizzare, il pratico cerca di tagliare corto la fase di design e di buttarsi nella stesura del codice (ragionando, vedi approccio test-driven e altro ancora). Il primo è spesso un programmatore con una grande conoscenza di tecnologie e pattern-design, il secondo con una grande conoscenza di scrittura di codice, sintassi, ecc… Come spesso accade, la cosa migliore si verifica quando gli estremi si incontrano. Senza un teorico non si può fare un design appropriato su cui basare le fondamenta del proprio software, senza un pratico quel software rimarrà nei meandri della mente del teorico o (peggio) si realizzerà male quando ci si arrenderà all’evidenza che tutto quanto pensato non vi è modo di realizzarlo (per tempi, costi, ecc…).
I problemi, potenzialmente, nascono quando in un team vi è presenza di estremi: un designer che si dimentichi quasi totalmente della realizzazione cercherà di impostare un’architettura complessa che sebbene possa rappresentare la miglior realizzazione possibile, verrà necessariamente troncata, rimaneggiata e rielaborata in fase di sviluppo, ovvero quando si dovrà fare i conti con la realtà. A questo punto allora accadrà che tutte quelle fondamenta si sgretoleranno davanti alla fretta del “dai ragazzi che dobbiamo farcela” salvo poi non farcela proprio, ritardando così la release e trovandosi a conti fatti con qualcosa che (in corsa e quindi non a tavolino, il che è notevolmente peggio) traballerà sin dalla sua base e che richiederà a sua volta ulteriori rimaneggiamenti.
Un buon sviluppo, a parer mio, non deve avere estremi: si deve pensare e disegnare un’architettura basata sulla propria situazione in quanto a risorse (sia umane, sia monetarie) e tempistiche, così da ottenere per davvero il miglior risultato possibile senza effettuare tagli di design in corsa (che prima o poi si pagano in termini di mantenimento del codice) e senza trovarsi a distanza di mesi con una base totalmente da riscrivere in quanto inadeguata alle proprie esigenze. L’equilibrio tra teoria e pratica però, e aggiungerei sfortunatamente, non è sempre così semplice da raggiungere e spesso si vedono team sbilanciarsi dall’una o dall’altra parte con i più variegati risultati (architetture inadeguate, tempi di sviluppo lentissimi e chi più ne ha più ne metta).
P.S. Io, come si sarà già ampiamente compreso, sono un programmatore molto più incentrato sul lato pratico che teorico, ma non nel senso che tendo a dimenticarmi del secondo, quanto che preferisco affrontarlo su una base che non mi porti a distaccarmi dalla realtà.
