La competenza che porta semplicità: mission possible.

La semplicità, l’arte di massimizzare il lavoro non svolto è una virtù strettamente legata alla competenza delle persone. Prendendo in prestito alcuni concetti dall’economia e dalla fotografia, mi sarà possibile dimostrartelo, perlomeno qualitativamente.

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 su Wikipedia

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.

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.

February 24 2011 06:58 pm | Visione agile

4 Responses to “La competenza che porta semplicità: mission possible.”

  1. Tweets that mention La competenza che porta semplicità: mission possible. | Sviluppo Agile -- Topsy.com on 24 Feb 2011 at 20:05 #

    [...] This post was mentioned on Twitter by April_Apricot, Jacopo Romei. Jacopo Romei said: [ITA] Appena pubblicato: http://www.sviluppoagile.it/semplicita-competenza-refactoring #refactoring #semplicità #competenza #agile #sviluppo [...]

  2. seralf on 27 Feb 2011 at 19:47 #

    Ciao
    il problema della competenza è che per crescere in tal senso bisogna secondo me superare quello che a me piace chiamare l’”istinto pratico” :-) I programmatori più efficienti tendono ad essere dei praticoni, degli “smanettoni”, ma come sappiamo questo atteggiamento non è sempre accompagnato da una capacità di lucida messa a fuoco di ciò che si sta facendo, e in genere premia più facilmente la velocità o il “basta che funzioni” sul metodo di lavoro e sulla sopravvivenza nel tempo di metodologie efficaci, capaci anche di sopravvivere al singolo.
    Chi è il programmatore bravo? quello che mi fa rilasciare (e fatturare) nell’immediato, o quello che mi rende possibile un grosso miglioramento a regime, a patto di un tempo di startup? Per quanto possa sembrare ovvia una risposta di mezzo, io sono convinto che permangano molti malintesi per cui quando si parla di queste cose molti project manager qui da noi pensano alla prima figura (percependo la seconda come macchiata di un classico idealismo di fondo :-) , senza rendersi conto della “terza via”, la via di mezzo.
    Secondo me in sostanza non ci si può definire “agili” se non si sta nel mezzo di questi due estremi: per spostarsi all’interno delle tue zone di “isocompetenza” io credo sia essenziale ritagliare pause di “messa a fuoco” che siano difese a prescindere dai rilasci, che ne pensi?

  3. Jacopo Romei on 28 Feb 2011 at 09:11 #

    > credo sia essenziale ritagliare pause di “messa a fuoco” che siano difese a prescindere dai rilasci

    Se intendi pause di refactoring per sistemare il codice allora ti rispondo che è meglio che non farle, certo, ma è peggio che scrivere il codice “giusto” da subito. Probabilmente la differenza tra quello che dici tu e la mia puntualizzazione – non ti sto contraddicendo – sta nelle finestre temporali: con il timeboxing è probabilmente meglio concedersi mezz’oretta di refactoring ogni ora di scrittura di codice che un’intera iterazione da una settimana dedicata al refactoring.

  4. seralf on 01 Mar 2011 at 16:56 #

    ah beh ma allora io sposo la tua puntualizzazione! :-)
    Ho solo la sensazione che spesso i programmatori più efficienti (a volte persino i più bravi) siano poco propensi a fermarsi un attimo a sistemare il codice, specie se sotto pressione, a mio avviso la competenza non può crescere se non si passa mai per queste fasi, perchè è durante queste “pause” che ci si abitua anche a buttare il codice e non affezionarcisi troppo per così dire, che ne pensi?

Trackback URI | Comments RSS

Leave a Reply