Articoli
di Stefano Muro
Qualche giorno fa, conversando insieme al mio amico coach Dino Ippoliti, ragionavamo sui motivi per cui alcuni team di sviluppo applichino cattive pratiche nello sviluppo del codice.
Il più delle volte la ragione che ci si dà è molto banale e appartiene a una tra quelle riportate in questo elenco:
Queste motivazioni su elencate sono assolutamente fondate: spesso mi è capitato di incontrare team che avevano questo tipo di problemi e, il più delle volte, la loro risoluzione, per quanto apparentemente semplice, si è rivelata piuttosto difficile da attuare a causa della diffusione nel management di convinzioni errate quali:
Sebbene le spiegazioni su riportate abbiano un senso, non sempre sono sufficienti a spiegare il comportamento di alcuni team che conosco: hanno la competenza (ad esempio la qualità del codice che sviluppano nell’ambito dei loro progetti privati è altissima) e hanno una sufficiente autonomia nello svolgere il loro lavoro della cui utilità sono abbastanza consapevoli.
Volendo utilizzare la metafora di Adam Tornhill del codice come una scena del crimine si potrebbero associare le cattive pratiche di design degli sviluppatori, ai crimini nella vita reale e, come i criminali, coloro che realizzano un SW spesso pagano in prima persona per la scarsa qualità del codice che producono … o forse no?
Quindi, cosa spinge i nostri sviluppatori a commettere e reiterare i loro “crimini”?
Ragionando su questa traccia, la discussione ha portato me e Dino all’analogia tra due teorie legate alla psicologia criminale e il comportamento dei nostri team di sviluppo SW. Queste due teorie sono:
La prima teoria, introdotta da James Q Wilson nel 1982 è piuttosto nota nel mondo del SW; volendola sintetizzare questa potrebbe essere enunciata così: i segni visibili dell’attuazione di crimini minori, spingono nel tempo a compiere crimini sempre più seri. Quindi le piccole scorciatoie, il non seguire le regole e gli standard di coding concordate, il tralasciare le buone pratiche di design e refactoring induce nel tempo a d applicare pratiche sempre più dannose e gravi, fino ad introdurre evidenti e gravi errori di design (ultimo esempio cui ho assistito: passaggio dell’implementazione di un DAO come parametro invece dell’interfaccia).
Poiché questo tipo di comportamento è piuttosto comune nel contesto dello sviluppo SW, esistono già delle contromisure ben consolidate: la pratica più diffusa è definire dei working agreements rigidi all’interno del team di sviluppo (spesso coadiuvati da strumenti di analisi del codice); nel Capitolo 1 del libro Clean Code di Robert C. Martin, c’è forse la regola più diffusa ed efficace: “la regola del boyscout” ovvero, lascia il luogo dove passi più pulito di come l’hai trovato al tuo arrivo. In ogni caso è importante sottolineare che di solito, per mantenere il codice pulito, le vie di mezzo non conducono ad un equilibrio stabile, l’equilibrio viene mantenuto solo attraverso il miglioramento continuo e la ricerca della perfezione.
La seconda teoria psicologica, quella dell’attribuzione esterna, non è di solito associata all’accumulo di debito tecnico nel codice, anche se, in relazione alla mia esperienza personale, è altrettanto pertinente. Questa teoria è stata resa famosa dall’esperimento carcerario di Stanford, quello che ha dato vita a 2 famosi film: secondo questa teoria individui comuni, non dediti al crimine, possono commettere atti orribili e cruenti se inseriti in un contesto esterno autoritario che li de-responsabilizza e autorizza, avallando i comportamenti criminali.
In quest’ottica gli sviluppatori SW commettono volontariamente violenti atti criminali (sul codice) se avallati da un contesto esterno in cui (riporto frasi collezionate durante la mia esperienza lavorativa) “Quello che conta è consegnare in tempo, il resto non serve a niente” o “L’importante è passare il collaudo (o le verifiche formali di qualità a seconda dei casi), non è necessario che funzioni”.
Questa ipotesi è molto legata ai concetti di “empowerment” e “accountability” del team, molto cari a noi coach agili. Se le persone del team non si sentono responsabili delle azioni che commettono, perché un’autorità superiore decide per loro, anche azioni controproducenti e dannose nello sviluppo del SW saranno considerate lecite se non addirittura giuste ad un livello più “alto”: ad esempio “non si fanno i test perché ci hanno detto (un’autorità superiore che deresponsabilizza) che ci impediscono di raggiungere gli obiettivi di business e poi d’altronde non sono necessari”.
Le persone in questo modo arrivano a pensare che sia davvero “giusto” il loro modo di agire (ne sono davvero convinte!), anche se poi li porta a lavorare nelle notti e nei weekend per riparare ai danni creati. Una frase che sento spesso dire è: “E’ normale, questo lavoro è fatto così! L’avrai fatto anche tu ai tuoi tempi no?”, oppure, con una marcata nota di pressione sociale, “Questo è un lavoro per persone toste, se uno non se la sente di lavorare la notte o nei weekend non è lavoro per lui, se ne può anche andare”. In alcuni casi cui ho assistito personalmente, la conseguenza è che la violenza non viene esercitata solo sul codice, ma anche sulle persone che non si uniformano al modo “istituzionale” di lavorare. Non a caso, in questi contesti, l’ambizione massima degli sviluppatori SW è quella di diventare il prima possibile “architetto” o “team leader” o “project manager”, così da potersi trasformare da vittima a carnefice il prima possibile, applicando gli stessi paradigmi che sono stati applicati verso di loro.
Come si può uscire da un contesto simile? In relazione all’esperimento di Stanford, o casi simili come la performance “Rythm 0” di Marina Abramovic, una volta terminati, le persone messe davanti alle loro azioni hanno provato vergogna e si sono dette incredule di aver potuto commettere determinate azioni: semplicemente “eseguivano gli ordini”; viene quindi istintivo ragionare su un approccio che metta le persone davanti alle conseguenze delle loro azioni e faccia sì che se ne prendano la responsabilità.
Il mio approccio è quindi di solito questo:
In questo modo si possono raggiungere, a mio avviso, le condizioni necessarie a creare empowerment e presa di responsabilità delle persone.
Condividi