Esiste una specie di fissazione nel mondo dello sviluppo secondo cui raggiunta la versione 1.0 è bene puntare immediatamente alla major release successiva. O a saltare direttamente alla 2.0.
Ciò può avvenire perchè la versione 1.0 di un programma non sempre riesce bene e non sempre viene neppure rilasciata (anche se c’è chi dice che dice che è meglio farlo comunque).
Si sprecano le affermazioni sul genere:
Per ora questa cosa la lasciamo così. Sistemeremo nella versione 2.0 o successiva.
In alternativa – e si spera che le cose vadano sempre così – la prima versione ha avuto successo e si mette in cantiere la successiva, pensata per essere migliore e molto più completa della 1.0 sotto tutti i punti di vista.
E qui iniziano i problemi.
La Second-System Syndrome
Il problema del successo non è solo ottenerlo ma mantenerlo nel tempo. Per cui per una sorprendente v1.0 ci si aspetta una 2.0 all’altezza e se possibile ancora migliore.
Parlando di sviluppo significa inserire nel calderone una moltitudine di nuove feature finchè il programma iniziale risulta totalmente stravolto al punto da costituirne uno essenzialmente nuovo di zecca, tuttofare ed omniscente.
In gergo questa frenesia di migliorare a tutti i costi una buona versione 1.0 prende il nome di “sindrome da secondo sistema” ed è così definita su Wikipedia:
In computing, the second-system effect or sometimes the second-system syndrome refers to the tendency, when following on from a relatively small, elegant, and successful system, to design the successor as an elephantine, feature-laden monstrosity.
Ovviamente il risultato è un spesso (sempre?) un disastro, al limite dell’ammasso gelatinoso difficilmente maneggiabile senza sporcarsi le mani (e la tastiera).
Oltre la ragionevolezza e senza alcuna necessità
Sono certo che qualunque sviluppatore con qualche anno alle spalle sa di cosa parlo, soprattutto se costantemente pressato a far di meglio, a “innovare” qualcosa che magari già funziona egregiamente.
Idem gli utenti comuni, quando da una versione all’altra di un software si trovano più funzioni (spesso non richieste e nemmeno necessarie!) e per giunta nuove interfacce grafiche, nuovi modi d’uso, … Non fanno in tempo ad abituarsi a qualcosa, che quel qualcosa cambia repentinamente e senza un vero perchè.
Potrei fare un lungo elenco di software che da una v1.0 alla successiva (e seguenti) è cambiato così tanto – senza migliorare davvero – da farmi infuriare al punto di abbandonarlo perchè non riuscivo più ad usarlo come volevo.
Non faccio nomi per non penalizzarne alcuno specificatamente ma questa sindrome pare colpire indistintamente qualunque programma, sia proprietario che FOSS.
Tanta è la foga di migliorare che poi invece si peggiora e di molto.
La Legge di Zawinski
Parlando di espandere un programma – ed il passaggio da una v1.0 ad una v2.0 di solito lo implica – non si può non citare la “Legge di Zawinski“, uno dei programmatori guru di cui avevo già parlato tempo fa.
Tale legge, scherzosa ma concreta, definisce il limite a cui tutti i programmi tendono prima o poi e recita così:
Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
Una versione più recente e aggiornata di questa legge, probabilmente includerebbe al posto di “mail” un qualunque servizio di Google, Facebook, Twitter o chissà chi altro, ma il succo non cambia.
Espandere il programma è qualcosa che va fatto in modo graduale, con criterio e lasciando fuori tutte quelle feature non veramente indispensabili ad un programma.
E’ assolutamente inutile ingolfare un programma di funzionalità che l’utente medio non userà mai (Chi ha detto telecomandi per televisioni con miliardi di funzioni? Chi ha detto milioni di funzioni inusabili/inusate concretamente in programmi come $FOGLIO_DI_CALCOLO?) o dare per scontato che se non è “Web 2.0-compliant“, “cloud-enabled“, … sarà un fallimento.
A ogni programma il suo scopo. Non serve che sappia fare anche il caffè nè tantomeno ce lo si aspetta da una versione 2.0!
Conclusioni
La vera sfida si gioca sul migliorare le funzioni per cui è stato progettato un programma, non nel numero grezzo di funzioni che dovrà avere. E in tutto ciò, il momento critico per la vita ed il successo di un programma è proprio nel passaggio dalla prima release alla seconda.
Ho perso il conto dei programmi che ho smesso di usare all’uscita della seconda release per manifesto “incasinamento globale“: sembra un prodotto dell’”ufficio complicazioni affari semplici“, non di un serio reparto di sviluppo software!
In ogni caso, buona versione 2.0 a tutti! 
Che ne pensate?
Ciao JP,
hai perfettamente ragione. Questa sindrome è molto grave e anche molto diffusa. Più che sindrome della seconda versione, la chiamerei sindrome della prossima versione. Un esempio, secondo me emblematico, di un software che ha questa sindrome è Nero (il famoso software di masterizzazione). Ora, se ricordo bene, dal passaggio dalla 7 alla 8, il software è stato completamente stravolto: UI completamente diversa, esplosione di features inutili, pesantezza generale etc etc. Il risultato? ho cambiato software…
Ciao!
Per quanto riguarda alcune Software House credo che il cambiamento derivi più da ragioni di marketing che altro, ossia il reparto vendite, o i capi dicono: “dobbiamo integrare nel software A le funzioni B e C, cosi che chi compra il nostro prodotto non compra anche altro”, questo è quello che penso, e credo sia riscontrabile (ad esempio in Office);
Per quanto riguarda il discorso di rilasciare sempre e comunque (indipendentemente dalla 1.0) è un discorso più legato alle startup: cioè sei all’inizio e senza fondi e normale che il tuo prodotto fa acqua, tu rilascialo, raccogli i feedback e se arrivano finanziamenti, perchè l’idea è buona, si migliora la qualità
il rilasciare la 1.0 credo sia più una cosa psicologica piuttosto che altro, come dire “questa è la release 1.0 , qui ci sono grossi cambiamenti e saranno stabili, da qui in poi sistemeremo solo i difetti”, per dirla in breve è solo un segno di voler dimostrare stabilità sia del software che della compagnia…
Il tutto IMVHO
Ovviamente hai Ragione (con la R maiuscola).
Quante volte mi son sentito dire: … intanto rilasciamo cosi’, poi lo miglioriamo in fase 2 …
Tristezza
succede anche che si parta con un milione di funzioni da fare nella versione 1.0, non si riesca a stare nei tempi prestabiliti e quindi si cominci a rimandare alla 2.0 molte features.
@Martino: guarda, non ho fatto nomi ma fra i “colpevoli” c’è anche quel programma. Mio papà, utente-medio, è impazzito a capire come far funzionare la versione Express e continuava a ripetere “Ma perchè l’hanno cambiato?! Funzionava così bene!“.
@fdicarlo: esatto. La point release è un fatto psicologico e molte feature derivano da un fattore puramente marketing. “L’ha fatto la concorrenza, lo facciamo anche noi” oppure “Questa è una cosa che potrebbe farci guadagnare clienti“. Ovviamente si tratta di pura teoria… -.-’
@Francesco: penso che sia davvero qualcosa di universale. Sigh…
@nemuriko: vero, ma buttare troppa carne sul fuoco è comunque rischioso. Meglio procedere gradualmente se non c’è una necessità ed un’urgenza tali da costringere ad accelerare i tempi…
Ciao & grazie di essere passati!
Diciamo che è una situazione che si ripete spesso, tanto da poterla definire ‘fisiologica’ in molte organizzazioni.
Non sarebbe nemmeno male se tutte le feature che si vogliono inserire nella 2.0 fossero fattibili nei tempi, con le risorse disponibili e con un adeguato processo di controllo qualità.
Invece spesso non è così, e ci si ritrova con un ‘pastrocchio’ nato dall’aver voluto fare troppo in troppo poco tempo (le pressioni per il rilascio della 2.0 sono più elevate. La 1.0 a volte non la attende nessuno).
E una ‘scarsa 2.0′ a volte genera un divertente paradosso, in cui il peggiore competitor del nuovo prodotto diventa la versione precedente, con gli utenti che non vogliono fare il passaggio.
.. grazie per il bel post !
Commento personale:
Io con Nemuriko non parlerei di carne
@Stefano: sì ripete perfino nelle ditte abituate al successo. Quanto al “competitor in casa” è assolutamente vero. Credo che l’esempio “XP vs Vista” sia un buon esempio ma, restando il clima familiare, mio papà sarebbe tornato seduta stante alla versione di Nero precedente se non fosse che gli ho spiegato ad usare quella nuova…
Grazie di essere passato! Ciau!
@fdicarlo: ahahahahah…
Interessante ed anche vero!
A questo però si contrappone un’altra sindrome: quella del non voler rilasciare la 1.0 perché non si è ancora convinti dello stato di sviluppo dell’attuale versione…. e così abbiamo tanti bei SW v0.99 …. v0.9999 …. v0.999.9.giurocheèlultima.9
@Vime: benevenuto, innanzitutto! E’ vero, a più riprese quel geniaccio di Spolsky (e non solo lui) lo ha detto a più riprese che se fosse per certi sviluppatori non si rilascerebbe mai nulla per uno stupido eccesso di perfezionismo… Le cose vanno rilasciate quando sono grossomodo presentabili, non quando saranno perfette (supposto che lo possano mai diventare). Il Time To Market è una regola che vale anche per gli sviluppatori!
Ciao e grazie di essere passato!
Arrivo solo ora causa release modello “cesareo” che mi ha tenuto lontano dal Feed Reader
Concordo pienamente, sopratutto quando si dice che spesso si ha paura di pubblicare… io ne ho il terrore ormai, odio correggere bug “live”.
Per quanto riguarda la crescita del programma, aggiungo features anche se non si tratta di una major release, in modo da non avere mai troppa roba da dover aggiungere nella nuova versione.
Il problema nasce quando c’è un cambio di architettura dell’intero sistema, che ti porta a dover stravolgere e rifare tutto da capo, dovendo per forza di cose cambiare quando di buono fatto in passato.
Il rischio del “era meglio prima” è sempre molto grande ma per questo lavoro chiedendo sempre pareri intorno a me, mentre osservo i competitors
@Joel: beh, ogni progetto parte con delle assunzioni, include quelle sull’architetura su cui poggiare più o meno preferibilmente. Inoltre non sempre si riesce a scrivere codice veramente “portabile” per cui è lecito impazzire se ti stravolgono le basi…
Quanto all’evitare di mettere troppa carne sul fuoco in una sola versione, ma distribuire le feature anche sulle minor, non mi pare una brutta scelta. A patto però di tenersi le feature più grosse per la major, in modo da garantirle una ragione di esistere…
Ciau & grazie di essere passato!
beh…
secondo me la storia della 2.0 schifosa e’ solo ed unicamente colpa dei commerciali o delle PR.
Per la prima versione si pensa a mettere una versione buona sul mercato, per la seconda si pensa ad “espandere” funzionalita’. Ma chi l’ha detto che l’espansione e’ un obbligo?
Sappiamo che uno dei segreti di Unix e’ la separazione dei compiti: un programma conta il tempo, un altro invia email, un altro fara’ dei backup.
Se voglio un prog che invia email ad una determinata ora dandomi lo stato dei backup organizzati, e voglio integrare tutte le funzioni nel mio software come pretendono i commerciali (o il pubblico), mi posso tranquillamente mettere a riscrivere _cron_ e compagnia bella.
Ma scherziamo? Il design di un prodotto dovrebbe essere fatto da chi comprende di cosa si sta parlando, non da **pinguini armati di powerpoint** .
E infatti la 1.0 per quanto immatura ha quasi sempre… non so, un’anima, un carattere tutto suo. Le altre versioni spesso diventano dei contenitori senza idee precise, spinte dalla corsa sfrenata del guadagno. Si torna alla normalita’ dalla 5 in poi, bene che vada
@roberto: il marketing è indiscutibilmente importante (“dai, fate qualcosa di nuovo che possiamo vendere!”), al punto che lo sviluppo spesso passa in secondo o terzo piano rispetto ad esso. Il punto sarebbe trovare un buon compromesso fra le parti coinvolte, sviluppo e marketing su tutte, senza che nessuno prevarichi sull’altro. Se fosse per gli sviluppatori, probabilmente un progetto non si concluderebbe mai per un eccesso di perfezionismo, no?
Ciao e grazie di essere passato!