L’argomento in questione è di grande attualità in ufficio ed è per questo che mi sento in dovere di condividere in questo post la mia visione sull’organizzazione ideale dei team di sviluppo, frutto di un decennio di osservazioni delle dinamiche lavorative.
Il mio ragionamento parte dalla costatazione che la suddivisione dell’intero organico in diversi gruppi è necessaria ed inevitabile, e non per ragioni organizzative ma antropologiche. I gruppi sociali si formano spontaneamente, pertanto è meglio crearli secondo logiche di produttività.
A scuola abbiamo imparato che per risolvere un problema è utile creare un modello, ovvero una astrazione semplificata della realtà in esame, che contempli solo gli elementi necessari alla descrizione del problema in questione. Ristretto il cerchio alle poche entità che costituiscono il modello individuato, sarà più facile individuare le logiche che ne governano il funzionamento e quindi risolvere il problema.
Ma è proprio necessario che il modello attorno al quale realizziamo una applicazione debba essere costruito sul dominio del problema?
Fatemelo dire a chiare lettere: nell’industria IT non c’è più spazio per gli sviluppatori nerd. Mi riferisco a coloro che sono attratti dalle soluzioni complesse, dagli hack, dalle over-ingegnerizzazioni e da tutto ciò che, per essere compreso, richieda un QI elevato e, al contempo, mostrano seri problemi nelle relazioni interpersonali.
KISS La letteratura dell’ingegneria del software parla chiaro, basta citare il principio KISS (Keep It Simple, Stupid) con cui si esorta a mantenere il codice sorgente semplice, lineare e comprensibile.
