Tribal Knowledge

Qui in Intentional il modello di sviluppo è abbastanza flessibile. Però ogni mattina c’è un meeting in cui ognuno racconta quello che ha fatto il giorno precedente e quello che farà nelle successive ore lavorative. Nei miei primi meeting mi sembrava di essere sbarcato su un altro pianeta: oltre allo slang tipico aziendale, c’era da assorbire uno strato abbastanza spesso di notazione ungherese.

Durante uno di questi meeting ho ascoltato per la prima volta le parole tribal knowledge per descrivere un insieme di conoscenze tramandato per via di esperienza lavorativa di gruppo, magari tramite striminzita documentazione scritta.

Era un concetto che nel tempo ho inconsciamente assimilato e già conoscevo e a cui veniva per la prima volta associata una definizione pseudo-formale. La tribal knowledge esiste ovunque ma è estremamente preponderante nei progetti software, secondo una visione estremamente personale della cosa.

Personalmente è il motivo per cui, il rilascio di software tramite codice sorgente, è irrilevante rispetto alle metriche di qualità. Chi ha a disposizione codice sorgente può chiaramente modificarlo, ma molto difficilmente migliorarlo senza assorbire la tribal knowledge necessaria laddove le modifiche da apportare non siano estremamente semplici. TK fatta di “se cambi questo parametro vai ad incidere su questo fattore che non è assolutamente ovvio, in quanto abbiamo fatto delle prove e scoperto che”.

Bottomline: avere il codice sorgente è senz’altro un valore in più, ma non si dovrebbe barattare per nessun’altra qualità del software che si va ad usare.

-quack