In economia esiste il concetto di isoquanto, ovvero

l’insieme delle combinazioni efficienti di input che forniscono lo stesso livello di produzione.

Questa arcana formula equivale a dire che più di una combinazione di ingredienti potrà darmi lo stesso risultato valido. Un esempio classico è quello del rapporto tra lavoro e capitale: fermo restando l’obiettivo di una start-up (il nostro output), se ho molto capitale e poco know-how potrò finanziarne una senza scrivere una riga di codice – il concetto di venture capital; se ho invece molto know-how e poco capitale potrò chiudermi in un garage tutte le notti e lanciarmi nell’impresa nerd.
Per opportune coppie capitale/know-how le chance di successo saranno le stesse e queste, in un diagramma cartesiano, saranno disposte lungo linee continue.

Isoquanti (fonte Wikipedia)

Un concetto simile esiste in fotografia: date certe condizioni di luce, sulla carta infinite coppie tempo di scatto/apertura diaframma mi garantiscono una corretta esposizione del fotogramma. Potrò chiudere il diaframma ed esporre per tempi più lunghi o potrò aprire il diaframma ed esporre per tempi più brevi.
Anche in un diagramma tempo-apertura perciò tutte le coppie accettabili saranno disposte lungo una linea continua. Ognuna di quelle linee corrisponderà ad un valore ISO della pellicola e sarà analoga all’isoquanto (hai notato qualcosa?) di cui sopra.

Cosa cambia di isoquanto in isoquanto? E di in ISO in ISO?

Banale ed intuitivo: se io posso disporre dello stesso know-how e di più capitale di un concorrente, avrò, ceteris paribus più chance di successo; se io posso disporre di un sensor… ehm di una pellicola caratterizzata da maggiori ISO, avrò, in condizioni per esempio di scarsa illuminazione, la possibilità di usare tempi di esposizione rapidi a parità di apertura diaframma, evitando un indesiderato effetto mosso.

Bene. E la competenza?

Si parla spesso di scegliere nel design del software fra una soluzione quick & dirty e soluzioni più “lente” ma più pulite. Se ne parla sempre. Se ne parla troppo. Il compromesso che si stabilisce è fra la massimizzazione del lavoro non svolto oggi e quello non svolto domani, tra 3 mesi o tra un anno. È possibile però ipotizzare l’esistenza di uno sviluppatore molto bravo che riesca a trovare una soluzione gagliarda oggi e facilmente estendibile in futuro, riuscendo quindi ad operare scelte win-win che trascendano il compromesso apparentemente inevitabile.

Un trade-off spinoso: semplicità a breve termine vs. a lungo termine.

Il diagramma qui sopra spero sia sufficientemente chiaro da farti afferrare che a parità di lavoro non svolto nel futuro – il nostro A, la competenza può farci saltare da una linea all’altra (le linee di isocompetenza? ) permettendoci di raggiungere i livelli crescenti B’, B” e B”’ di semplicità sul breve termine, salvando capra e cavoli.

Ipotizzare l’esistenza di uno sviluppatore molto bravo è utile ai fini di questo post. Diventarlo, una missione impossibile. La parola d’ordine è competenza, la sua espressione più diretta il refactoring.

Non resisto alla tentazione di integrare con una metafora sportiva: in una squadra di football ci sono i manager e c’è il coach. Non credo debba aggiungere altro, secondo me messa così rende bene l’idea.

Kent Beck, papà di Extreme Programming, Test Driven Development e Manifesto Agile, per dirne giusto due o tre, in questo suo post fa una breve analisi del poker e ne trae una interessante lezione: nelle negoziazioni in cui non siamo al corrente di tutti i retroscena – caso peraltro abbastanza tipico – è possibile scambiare un certo valore in denaro con un corrispondente valore in informazioni.

Nel poker lo facciamo tutte le volte che vediamo il gioco avversario, raccogliendo informazioni sulle sue attitudini strategiche, o le volte in cui dichiariamo accettiamo il gioco in apertura – versando la quota opportuna nel piatto, per avere una prima impressione sul gioco in mano agli avversari. Nei negoziati a monte di tutti i nostri progetti lo facciamo tutte le volte che scopriamo di aver chiesto meno di quanto avremmo potuto, rinunciando quindi ad una certa quantità di denaro ora ottenendo informazioni sul vero valore del nostro lavoro preziose nel futuro.

È importante capire che tutto ciò è vero su entrambi i fronti del negoziato; anche il nostro cliente si chiede se il nostro lavoro vale la somma esborsata ed è pronto a sborsarne meno la volta successiva se scopre che il gioco non vale esattamente la candela. Questo significa che, a lungo termine, gli accordi, per mantenersi sostenibili, rischiano di attestarsi su valori più bassi del migliore possibile a causa dell’esborso necessario a raccogliere informazioni strategiche. Un po’ come dire che l’etica può essere pragmatica, no?

Ciò detto scritto, ti sembrano più ricchi accordi fatti in trasparenza o quelli fatti in un contesto opaco? Tu hai mai scoperto il bluff di un tuo cliente? E non hai mai bluffato? In quale caso il progetto ha avuto più successo?

Questa visione dei test come side effect di una tecnica di design – Test Driven Dev… Design – mi ricorda un mio vecchio post in cui sostenevo la maggiore importanza della manovrabilità delle specifiche rispetto al codice sorgente, relegando quest’ultimo al ruolo di mero strumento. Ovviamente la decentralizzazione del software che ho sostenuto in quell’occasione e in molte successive non ha nulla a che vedere con una presunta dequalificazione del codice stesso, che anzi, essendo espressione efficace dei nostri obiettivi, deve essere garantito di qualità eccellente. Nel corso dell’ultimo anno però ho potuto riflettere parecchio sul legame tra (sviluppo) software e user experience e sono quindi giunto ad una conclusione ulteriore, che integra quelle precedenti, estendendole.

Io credo che l’intero concetto di software sia in realtà un concetto collaterale. Noi sviluppatori vendiamo sì manovrabilità, ma non per ottenere software come prodotto finale. L’elevata qualità del nostro prodotto, il codice – che a questo punto scopriamo essere un semilavorato – serve infatti a garantire il successo del prodotto finito vero e proprio: la user experience. Il flusso di cassa diventa positivo nel momento esatto in cui il primo utente vive con successo l’esperienza che il nostro software contribuisce a realizzare. Non un solo attimo prima.

Una prova del 9 semplice semplice? Prova a sviluppare del software e a non farlo usare mai a nessuno. Pensi possa valere qualcosa?

Un professore, prima di iniziare la sua lezione di filosofia, pose alcuni oggetti davanti a sé, sulla cattedra. Senza dire nulla, quando la lezione iniziò, prese un grosso barattolo di maionese vuoto e lo riempì con delle palline da golf. Domandò quindi ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.

Allora, il professore rovesciò dentro il barattolo una scatola di sassolini, scuotendolo leggermente. I sassolini occuparono gli spazi fra le palline da golf. Domandò quindi, di nuovo, ai suoi studenti se il barattolo fosse pieno ed essi risposero di sì.

Il professore, rovesciò dentro il barattolo una scatola di sabbia. Naturalmente, la sabbia occupò tutti gli spazi liberi. Egli domandò ancura una volta agli studenti se il barattolo fosse pieno ed essi risposero con un sì unanime.

Il professore tirò fuori da sotto la cattedra due bicchieri di vino rosso e li rovesciò interamente dentro il barattolo, riempiendo tutto lo spazio fra i granelli di sabbia. Gli studenti risero!

“Ora”, disse il professore quando la risata finì, “vorrei che voi consideraste questo barattolo la vostra vita. Le palline da golf sono le cose importanti; la vostra famiglia, i vostri figli, la vostra salute, i vostri amici e le cose che preferite; cose che se rimanessero dopo che tutto il resto fosse perduto riempirebbero comunque la vostra esistenza.”

“I sassolini sono le altre cose che contano, come il vostro lavoro, la vostra casa, l’automobile. La sabbia è tutto il resto, le piccole cose.”

“Se metteste nel barattolo per prima la sabbia”, continuò, “non resterebbe spazio per i sassolini e per le palline da golf. Lo stesso accade per la vita. Se usate tutto il vostro tempo e la vostra energia per le piccole cose, non vi potrete mai dedicare alle cose che per voi sono veramente importanti.

[...]

Un po’ come le feature marginali o addirittura inutili che occupano tempo e testa degli sviluppatori al posto delle core feature. Un po’ come assegnare sempre la priorità più alta ai task che promettono una conclusione più immediata tentati dalla possibilità di sembrare più produttivi.

Un po’ come rinunciare alla gallina oggi per l’uovo domani.

p.s. ho scoperto che odio la retorica un po’ new age delle catene di Sant’Antonio…

Gabriele fa riferimento nella sua mail al rigore di un processo, all’autorità all’interno di un team e alle buone pratiche scrivendo:

Durante il primo stadio dell’apprendimento (di qualsiasi cosa) si
devono seguire delle regole per non farsi male e per non fare male,
non c’è molto spazio per la democrazia, se fossi sotto i ferri e ci
fosse un team di medici pronti ad operarti vorresti che per democrazia
vincesse il “per questa volta non ci laviamo le mani prima di
operare”?

Leggere queste righe mi ha fatto subito pensare che avevo intenzione da un po’ di parlare di buone pratiche e di processi di decisione nei gruppi facendo riferimento al dottor Ignác Fülöp Semmelweis, noto come il Salvatore delle madri.

Semmelweis è amaramente celebre per aver scoperto che l’elevata incidenza di febbre puerperale tra le partorienti della sua epoca era dovuta alla scarsa igiene dei medici. Semplicemente i medici non si lavavano le mani, ciò causava un alto tasso epidemico nei reparti ospedalieri e di conseguenza un’alta mortalità tra le pazienti. Fin qui, oggigiorno, nessuna sorpresa. Ti potrai chiedere quindi perché la sua sia stata una storia amara.

Semplicemente i colleghi di Semmelweis decisero di non credere alle sue parole. Anzi, peggio, di non credere ai numeri che Semmelweis portò in sostegno ai suoi argomenti. Lo isolarono, lo screditarono e, sebbene in qualche occasione Semmelweis riuscì anche ad implementare i protocolli igienici che salvarono già in quelle prime occasione vite preziose, il riconoscimento dovuto alle ricerche del medico ungherese arrivarono solo postumi. Addirittura il povero Semmelweis venne estromesso dalla comunità scientifica dell’epoca in virtù di un risentimento diffuso nella classe medica dell’epoca: noi medici causa di queste morti??? Non ci si permetta!

Purtroppo anche in quell’occasione la maggioranza ebbe la meglio, perlomeno in prima battuta – ad un costo comunque alto, anche fosse stato di una sola vita umana.

Il regime democratico assiste spesso ad una sua degenerazione verso un mero criterio numerico maggioritario: “siccome siamo tanti a dire questa cosa, abbiamo ragione sicuramente; tanta gente non può sbagliarsi tutta insieme.” Una specie di principio di autorità distribuito, con tutti i difetti dialettici tipici del principio di autorità.

Nello sviluppo agile si centra molta dell’attenzione sulla condivisione delle responsabilità e delle decisioni e si punta a non ignorare nemmeno le sensazioni che le persone, poste al centro del processo di sviluppo, devono usare come spunto per andare avanti, motivarsi, analizzare la qualità di ciò che si fa e di come lo si fa. Questo potrebbe indurre a pensare che si possa quindi

1. dirigere i nostri sforzi solo dove ti porta il cuore
2. ignorare l’oggettività di dati rilevati, anche solo qualitativamente

E invece no! Un solo membro del team che misurasse con precisione sufficiente e in base ad una metrica valida che una scelta di processo porta dei concreti vantaggi al progetto su cui si lavora basterebbe da solo a controvertire il parere congiunto di una muraglia di colleghi più istintivi.

Per questo l’adozione dei metodi agili può essere così ardua nelle aziende che non siano nativamente basate su queste metodologie: perché richiedono l’adozione di un compendio culturale ed etico che deve necessariamente essere presupposto del processo e non conseguenza del processo stesso. Un compendio che permetta da una parte l’individuazione delle vere sorgenti dei problemi, con franchezza, onestà e, perché no, spirito di sacrificio, dall’altra di essere rigorosi quanto basta perché si possa essere certi che la mancanza di risultati sia dovuta ad una vera inappropriatezza di una data pratica al contesto di applicazione e non all’imprecisione nell’attuazione.

Si tratta di essere disposti a guardare in faccia lo stato delle cose, qualunque verità rischi di saltare fuori. Il movimento open source, esponendo il codice e i relativi bug, ci ha abituati al successo di questo approccio riguardo la qualità del codice. Non credi che per la qualità del processo di sviluppo esistano altrettali margini di miglioramento?

Negli ultimi decenni i marchi più famosi hanno capito che può essere molto remunerativo mettere in atto il cosiddetto attitude branding ossia l’estensione della percezione pubblica del marchio – il brand – fino a rappresentare non più il solo prodotto inizialmente identificato ma un sentimento più ampio, talvolta spinto fino a costituire un sincero senso tribale di appartenenza. Ecco quindi che vediamo il marchio usato ora su un paio di scarpe, ora su un orologio e ora per dare il nome ad un campionato di calcio. In ogni senso, quindi, vediamo il logo trascendere il prodotto iniziale e rappresentare qualcosa di più astratto, un vero e proprio modo di essere. Se hai letto No Logo di Naomi Klein – o altri reportage simili – sai cosa sto cercando di comunicarti in breve: le grandi multinazionali non vendono più un prodotto – la scarpa – la cui riconoscibilità è garantita dal logo – accessorio; bensì vendono un’identità – il brand – utilizzando come supporto la scarpa – accessorio.

Bene, in questi ultimi tempi mi sto convincendo del fatto che un team agile non deve pensare di vendere semplicemente software. Mi sembra sempre più chiaro che un team agile debba acquisire una mentalità più alta in cui si senta elemento chiave di un processo che miri a consegnare manovrabilità, nel senso cirilliano del termine. Una mentalità che ponga la possibilità di cambiare direzione come il vero prodotto.

Tutto questo si ottiene sicuramente partendo dal basso, da ogni riga di codice, non va dimenticato, mai. Ma, considerando che manovrare per il cliente significa reagire agli stimoli del mercato, il mantra di ogni team deve diventare questo: non consegno più un software – il prodotto – la cui manutenibilità è garantita da un design flessibile – accessorio; bensì vendo manovrabilità – il prodotto – utilizzando come supporto il software – accessorio.

E tu? Oggi consegnerai al tuo cliente righe di codice o manovrabilità?

Bene.

Ora ridici un po’ su.