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:

• Non ci sono più gli sviluppatori di una volta: è un problema di competenza e, a volte, di consapevolezza dell’esistenza di un’estesa letteratura su come, indipendentemente dai framework e dai linguaggi utilizzati, creare SW di qualità.
• Non sono motivati: lo stipendio lo hanno comunque, non hanno consapevolezza dell’utilità di quello che fanno, non gli si dà autonomia decisionale sulle soluzioni (e forse non vogliono averla), non gli si dà la possibilità di acquisire competenze o comunque misurarsi con attività sfidanti ma alla portata.

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:

• Lo sviluppo SW è un’attività individuale non creativa che, dato un problema, ha una unica (o comunque poche) soluzione ben individuabile. Molto simile al lavoro di un operaio (al limite specializzato) in una catena di montaggio. In quest’ottica non è necessario spiegare alle persone che realizzano il SW quale sia il problema, loro deve solo implementare la soluzione individuata dagli “esperti”. (NB avrei voluto portare l’esempio di un traduttore che traduce un testo da una lingua ad un’altra ma immagino che il lettore abbia esperienza di quanto una traduzione possa essere errata nel caso non si abbiano nozioni del contesto e del messaggio che si vuole trasferire)
• Il costo del SW si limita al costo del suo sviluppo. Il costo della manutenzione correttiva è trascurabile rispetto al costo dello sviluppo e il costo della manutenzione evolutiva non dipende da criteri di qualità del SW sviluppato.
• La competenza è una grandezza binaria o la si ha o non la si ha, quindi a parità di competenza si “compra” la “risorsa” che costa di meno.
• Il lavoro è lavoro: non deve essere una cosa divertente, né interessante né ispirante. Se le persone sono “professionali”, lo stipendio a fine mese è l’unica motivazione necessaria e sufficiente affinché loro facciano il loro lavoro al meglio (vedi la Teoria X di Douglas Mc Gregor).

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 teoria della finestra rotta
• La teoria dell’attribuzione esterna (anche detta della attribuzione situazionale).

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:

• Definire gli obiettivi come un qualcosa di oggettivo e misurabile: evitare la situazione in cui una cosa è fatta bene se è approvata da un’entità superiore; la conseguenza è che l’unica cosa che si possa fare sia ciò che ti viene ordinato.
• Definire i principi in base ai quali si possa definire una cosa “giusta” o “sbagliata” a prescindere. Il motivo è analogo a quello del punto precedente.
• Evidenziare le “leggi”, le regole esplicite ma soprattutto quelle implicite secondo cui si opera al momento attuale.
• Agire come uno “specchio”, evidenziando le dissonanze tra “leggi”, principi e obiettivi, mettendo in guardia dagli effetti indesiderati di un determinato comportamento e portando evidenze oggettive (misure) (Es. senza fare i test i costi della manutenzione in 3 mesi hanno eguagliato i costi dello sviluppo).

In questo modo si possono raggiungere, a mio avviso, le condizioni necessarie a creare empowerment e presa di responsabilità delle persone.