Credo che tutti abbiamo avuto questa esperienza: scrivere applicazioni che dopo x giorni si sono rivelate non più mantenibili, per le quali si impiegava meno tempo a riscriverle che a modificarle. Complice la tecnologia utilizzata, l’effort per riscrivere parti dell’applicazione  lasciava comunque il committente non contento dei nostri tempi di risposta e quindi del costo del software. In sostanza la bassa qualità del software prodotto si traduceva in alti costi di manutenzione.

La frustrazione provata in queste occasioni ci ha portato a chiedere: dove cercare la soluzione?

Sostanzialmente vi sono due strade opposte:

• addossare la colpa alla tecnologia utilizzata, e quindi cambiarla alla luce di questa affermazione
• cercare di migliorarci per costruire skill e capacità che ci permettano di non cadere nella trappola dell’applicazione zombie

Read the rest of this entry »

Nel mio aggregatore figura questo blog, che regolarmente presenta post molto stimolanti.

Un post del mese scorso riflette su come insegnare alle persone ad avere un approccio mentale rivolto all’eccellenza per mezzo del miglioramento continuo. Imparare ed insegnare ad essere sempre volti verso l’(auto)miglioramento è l’investimento più grande che si possa fare su se stessi o sulle persone che si gestiscono. Purtroppo le aziende che si concentrano su questo aspetto per liberare e far esprimere tutto il potenziale dei propri dipendenti, sono pochissime. Si preferisce “investire” su altro: controllo o totale mancanza di sistematicità.

Il miglioramento continuo ha un aspetto fondamentale: il fare. Solo attraverso l’azione è possibile migliorarsi: senza azione non c’è feedback e senza feedback non può esserci apprendimento.

Questa citazione (che traduco) chiude l’articolo:

“Il pessimista si lamenta del vento; l’ottimista si aspetta di poterlo cambiare; il realista aggiusta le vele.”

Per me questo significa: responsabilizzarsi ed essere proattivi.

Ultimamente in TV c’è una pubblicità che mi piace molto: la pubblicità della Mostra Internazionale d’Arte Cinematografica di Venezia. La frase cardine della promozione, che credo appenderò in ufficio è la seguente:

E’ il desiderio di qualità che ci ha sempre permesso di sognare.

Stamattina ho letto inoltre un post di uno dei miei blog preferiti: AgileAdvice. Il post si intitola Quality is Not Negotiable (consiglio vivamente una lettura) ed affronta il tema della qualità come condizione irrinunciabile ed imprescindibile ad un processo efficiente che minimizza gli sprechi e che voglia ottenere il massimo dal business di cui è a supporto. In caso contrario ci si ritrova ogni 2-3 anni a dover ricostruire da capo sistemi e prodotti, o nel caso migliore (si verifica raramente) a dover fermare la produzione per lunghi periodi di tempo al fine di rimettere ordine in un prodotto mal costruito e di bassa qualità. Mi viene in mente uno dei cardini del Toyota Production System e di tutta la filosofia del Lean Manufactoring: in ogni momento ogni componente del team ha il diritto di fermare la produzione se nota un artefatto di bassa qualità ed in questo caso la produzione non riprende fino a quando tale difetto non sia stato risolto e non se ne siano comprese le cause. Questa continua ricerca di qualità e la responsabilizzazione di ogni sviluppatore garantisce che il mostro venga ucciso in poco tempo quando ancora piccolo e non quando avendo raggiunto dimensioni ciclopiche un suo abbattimento renderebbe necessario un dispendio di forze (=soldi) molto alto; per non parlare degli ingenti danni che tale mostro avrà compiuto durante la sua crescita.

Una delle armi più efficaci in mano agli sviluppatori per identificare il prima possibile questi difetti è l’enfasi su brevi cicli Test Sviluppo Refactoring, in Toyota come nello sviluppo del software.

Per applicare questi brevi cicli e per continuare a sognare il team non può permettersi compromessi, e non deve accettarli da parte dell’organizzazione e del management: sareste disposti a calpestare la vostra dignità e a vivere senza sogni?

Chi mi segue da questa piccola finestra (la puntata precedente è comunque qui) sa che da circa un mese non mi è più “permesso” di scrivere codice in PP: il mio attuale e unico collega infatti è allergico alle coppie. Non solo, purtroppo io ed il mio collega abbiamo anche principi prospettive di visione del codice molto differenti, direi addirittura opposte. Ma non è del mio collega (per altro simpatico e di vecchia data) che vi voglio parlare, quanto invece delle mie reazioni e dei miei peccati in questo mese.

Nell’ultimo mese e fino a qualche giorno fa ho prodotto software di bassa qualità, voglio cercare di capire il perché con voi. Sicuramente e per onestà nei miei confronti il motivo principale è la scarsissima conoscenza dei tool utilizzati. Ma questo lo sapete già. Più interessante è invece come il rapporto tra me ed il mio collega, i miei timori e il disallineamento di valori hanno influenzato la mia capacità di creare qualità.

Read the rest of this entry »

Ho sentito parlare più volte dell’importanza delle condivisione dei valori all’interno di un team. Fino a qualche giorno fa non ne avevo avuto esperienza diretta all’interno del team di sviluppo, e soprattutto non l’avevo vissuta sulla mia pelle. Negli ultimi due giorni ho invece avuto la fortuna di sperimentarlo, grazie ad una pratica che mi ha permesso di confrontarmi in modo molto stretto con il mio collega sviluppatore: il pair programming. Read the rest of this entry »