Tra le diverse arti che competono al mestiere dello sviluppatore software, possiamo provare ad identificare quali siano irrinunciabili per la costruzione di un progetto che possa ritenersi tecnologicamente degno di nota.
Scommetterei senza dubbio sulle pratiche del Software Engineering, su alcune lezioni estratte dalla scuola del Project Management, su insegnamenti pescati dal calderone della System/Network Administration e necessariamente su altre discipline inerenti alla natura del progetto. In tutti questi casi tuttavia, quasi imprescindibilmente, sarà necessario produrre del codice sorgente. Uno o più sviluppatori infatti dovranno:
- Analizzare i requisiti.
- Riconoscere i componenti.
- Individuare i task.
- Determinare le ore/uomo.
- Stimare i costi di sviluppo.
- Produrre il progetto.
E qui viene il cruccio.
L’ottimizzazione di questi step è uno dei più ricorrenti obiettivi delle ricerche in campo IT. Verte infatti sull’incremento della produttività dello sviluppatore – direttamente o indirettamente – la maggior parte degli sforzi accademici. Per evidenziare un aumento di produttività è tuttavia necessario (quantomeno) saper osservare, poter misurare ed esser in grado di comparare analiticamente i risultati nel tempo, compito che è risultato impossibile nonostante gli sforzi secondo Martin Fowler.
Vani i tentativi di unire diverse misure legate alle metriche del codice, all’efficacia del lavoro svolto in un’unità di tempo, alle linee di codice prodotte, al numero di funzioni costruite o modificate, alla variazione della complessità computazionale. Tutte misure risultate troppo astratte e interdipendenti per far chiarezza su quali effettivamente siano le leve che governano l’evoluzione e la crescita di un progetto software.
Per contro, per un programmatore, la percezione della giornata produttiva è generalmente chiara: quando c’è, c’è. Si avverte, altrimenti oggi non ne ho cavato fuori nulla.
Sono pertanto stati cercati dei risultati su base soggettiva. La personale percezione di produttività espressa dai candidati tramite sondaggio è stata commisurata al completamento degli obiettivi assegnati, al numero di ruoli assolti dal programmatore, al numero di cambi di contesto ed altri potenziali fattori impattanti.
Il primo risultato ha dimostrato – senza troppa sorpresa – che poche interruzioni ed un numero prefissato di obiettivi raggiunti durante una giornata sono in testa tra i fattori scelti che soggettivamente descrivono una giornata produttiva. Più sorprendente invece è il risultato che pone i meeting contemporaneamente tra le attività più e meno produttive, definendo un comportamento controintuitivo.
La stima di un programmatore dipenderà quindi da come percepirà personalmente la propria produttività, che dipenderà fortemente dal contesto in cui è inserito.
Si evince pertanto che la grandezza, la complessità e la fattibilità di un progetto saranno più legate al management ed alla sensibilità delle singole parti in causa che dalla natura del lavoro in sé.
A quanto pare lavorare con le macchine ci ha reso fortemente umani.