Sindrome di onnipotenza collettiva
da Mastollo, l'enciclopedia del pulito
La Sindrome di onnipotenza collettiva si ha in un gruppo a cui è affidato come compito parte di un progetto, quando il gruppo stesso si convince di essere in grado di poter svolgere da solo il progetto in questione nella sua interezza.
Indice |
Progetti OS
Nel mondo di Internet, questa malattia infetta la maggior parte dei progetti open source (OS) di media grandezza, a causa della natura dello stesso, natura che verrà testè esaminata.
Nascita
Un progetto OS nasce per opera di uno o più programmatori, che hanno un'"idea"(tm) e la capacità di tradurla in un codice funzionante. Una volta che si ha un software che "funziona dawero"(tm), il pubblico decreterà o meno il successo dello stesso. Dove "stesso" è riferito a "software", e non a "pubblico".
Il pubblico ha queste funzioni:
- incrementare la base di sviluppatori: una piccola percentuale di utilizzatori del programma, sarà anche in grado di contribuire attivamente al codice dello stesso
- bug report (BR): è un aiuto per chi poi il codice deve davvero aggiustarlo
- feature request (FR): dovrebbe essere un aiuto per i designer, di cui parleremo dopo
- incrementare la notorietà del programma: aumentando così a sua volta il numero di utenti (circolo vizioso positivo)
Se il meccanismo funziona, il software avrà successo e passerà alla fase successiva.
Successo
Un progetto diffuso e rinomato, ha abbastanza utenti da produrre sufficienti BR e FR, e abbastanza sviluppatori da potervi badare.
In questa fase possono nascere i primi, letali, problemi: l'assenza di designer e di direttori, elementi fondamentali in un gruppo, e l'assunzione da parte dei programmatori di tutti i compiti, porta spesso a scelte errate e problematiche.
Diverse cause possono portare al problema delle "FR fantasma", chiamate così perchè è come se non fossero mai state poste.
- bassa percentuale di assunzione
quando il pool di utenti cresce velocemente, può accadere che tra essi non ci sia un sufficiente numero di sviluppatori. L'immediata conseguenza è l'aumento troppo rapido di BR e FR, e l'impossibilità di badare a tutte.
- alta percentuale minorenne
è risaputo che i minorenni sono inferiori. Per definizione: altrimenti avrebbero il diritto di voto. Ora, se un progetto suscita particolarmente l'interesse dei minorenni, questi metteranno in moto la loro deleteria tendenza a fare una quantità ingiuriosa di FR, tutte inutili. Questo rallenterà il lavoro degli sviluppatori, che dovranno scartarne di più, rischiando di scartare anche quelle utili. Talvolta ciò può degenerare nella programmazione personale.
Programmazione Personale (freebooters)
Questa è una delle più gravi malattie che possono colpire un progetto OS. È purtroppo anche piuttosto diffusa, in quanto connaturata in molte interpretazioni dello stesso, quindi non riconosciuta in quanto patologia, ma accettata come cosa buona e giusta. Si manifesta quando i programmatori non mostrano più interesse nel migliorare il programma "in sè", quanto nel modificarlo "per sè stessi".
Questi, detti "freebooter", se sono in numero non eccessivo portano un degno aiuto, ma se l'intera troope di programmatori è composta quasi esclusivamente da elementi di questo tipo, il progetto proseguirà in direzioni casuali, senza più riuscire a evolversi e migliorarsi.
Il problema nasce da una scorretta visione delle meccaniche OS. Il punto di vista del freeboter generalmente è "Se io programmo, io decido cosa programmare". Apparentemente ha senso, ma guardando la questione col cervello attivo, è subito chiaro che se tutti seguissero questa filosofia, lo sviluppo procederebbe a tentoni, in modo casuale, alla mercè di "cosa vorrà fare il prossimo freebooter che passa".
Un software controllato dai freebooters ignorerà totalmente le FR, e considererà solo i BR critici. Nella fase di nascita, gli sviluppatori devono scrivere anche parti di codice che magari li annoiano, implementare funzioni che vanno fatte, anche se non sono la cosa più divertente da fare, e così via. Questo semplicemente perchè altrimenti il programma non nasce. Semplice.
È un atteggiamento stupido credere che questo non valga anche nelle fasi successive. Un programmatore di norma usa il programma a cui contribuisce, di conseguenza è necessario che lo mantenga in salute. Ignorare BR e FR è il metodo più veloce di diminuire il parco utenti, e, tanto quanto il numero di sviluppatori attivi cresce col crescere degli utenti, è anche vero il contrario: più utenti se ne vanno, meno sviluppatori nuovi arriveranno. Così un progetto va in stallo o in declino.
Sindrome di onnipotenza collettiva
Normalmente un programmatore sa programmare, sa scrivere il codice. Cosa ben diversa è fare il design di un programma, deciderne la struttura, e organizzare lo sviluppo del progetto. Quando questo progetto è ancora piccolo, è perfettamente normale che questi compiti siano svolti dalle stesse persone, ma una volta che è cresciuto, sorgono i problemi.
A questo stadio dovrebbe essere introdotta la figura del designer, una persona dedita unicamente a dirigere lo sviluppo al di fuori del codice, a istruire gli sviluppatori su cosa fare, lasciando a loro il compito del come.
Mentre ciò è parzialmente evidente nei software applicativi, risulta assolutamente vitale nei videogiochi. Questo perchè, mentre gli applicativi devono limitarsi a funzionare bene, e magari a essere comodi e intuitivi, i videogiochi devono risultare divertenti.
Uno sprovveduto qualunque, mediamente, e specie se già occupato nella programmazione (cosa non da poco), non è in grado di capire le complesse meccaniche di un gioco, e finisce per creare cose che a un giocatore scafato faranno storcere il naso, fino al punto da abbandonare del tutto il gioco in questione.
Ciò è evidente anche dalla scarsissima quantità di validi giochi OS presenti sul mercato, tendente allo zero.
