SoftwareMarketSolution: Joel, qual è il più grande errore che possa fare un'azienda produttrice di software?
Joel Spolsky: Decidere di riscrivere da zero il codice di un prodotto basandosi sulla solita teoria che tutto quel codice è un casino, è tendenzialmente bacato ed è ingestibile e che, di conseguenza, va completamente ripensato e riscritto.
SMS: Uh, e cosa c'è di sbagliato in questo?
JS: Perché non è quasi mai vero. Un codice non arrugginisce senon viene utilizzato. Ritenere che un nuovo codice sia certamente migliore del vecchio è assurdo. Il vecchio codice è testato. Sono stati individuati chissà quanti bachi, che poi sono stati anche risolti. Cosa c'è che non va con questo codice?
SMS: E per quale motivo, secondo te, i programmatori sono soliti recarsi negli uffici del management sostenendo che il codice esistente è una schifezza e che, conseguentemente, va riscritto?
JS: Secondo la mia teoria questo accade perché è molto più difficile leggere il codice piuttosto che scriverlo. Un programmatore arriverà sul punto di piangere per una funzione che secondo lui è un casino. Magari si tratta di una funzione molto semplice, magari per aprire una finestra, ma per qualche motivo c'è bisogno di due pagine di codice, di tutte quelle parentesi e freccette delle quali nessuno capisce niente, per riuscire a farla funzionare.
OK. Te lo dico io a che serve tutta questa roba.
Si tratta di bug-fixing.
Una serve per risolvere un baco che Jill ha individuato quando ha provato a installare il prodotto su un computer che non aveva Internet Explorer. Un'altra a fissare un baco che capita quando il sistema non ha sufficiente memoria. Un'altra ancora fissa qualche baco che capita quando il file si trova ancora sul floppy disk e l'utente lo tira fuori per errore mentre il file è ancora aperto. Tutti quei commenti sono certamente orribili a vedersi, ma fanno sì che il codice possa funzionare sulle vecchie versioni di Windows 95. Se decidi di buttare via quella funzione e di riscriverla da zero, butti via tutta questa esperienza.
Tutti quei fissaggi dei bachi messi insieme. Anni di lavoro.
SMS: Bene, ammettiamo che uno dei tuoi programmatori migliori venga da te e dica: "Dobbiamo assolutamente riscrivere tutto il codice da zero, riga per riga': Cosa risponderesti?
JS:
Quello che ho imparato dal grande libro di Charles Ferguson (High St@kes, No Prisoners) è che l'importante è assumere programmatori che sappiano comprendere gli obiettivi di business.
Persone che sappiano rispondere a una domanda del tipo "Quanto costerebbe all'azienda la riscrittura completa del codice? "Di quanti mesi dovrà essere ritardata la data di pubblicazione del prodotto?", "Venderemo un numero sufficiente di copie per giustificare il tempo perso e le quote di mercato lasciate per strada?'
Se, dopo queste domande, i tuoi programmatori insistono sul fatto che si debba riscrivere tutto il codice, probabilmente non sono in grado di comprendere gli aspetti finanziari dell'azienda per cui lavorano o gli aspetti competitivi legati alle tempistiche di rilascio.
Allora prova a spiegargli questi fattori. Dopodiché chiedigli una stima onesta dello sforzo necessario per la riscrittura e mostragli il tuo foglio elettronico con il quale è possibile fare insieme un'analisi dettagliata del rapporto costi/benefici che comporta questo lavoro.
SMS: Grande, ma i programmatori sono famosi per non essere molto sinceri quando si parla di queste cose.
JS: Si tratta della famosa strategia del programmatore: "tutte le funzioni che voglio svolgere io necessitano di l ora di lavoro, tutte quelle che non voglio necessitano di 99 anni'~ Se sospetti
che il programmatore stia mentendo, lascia stare. Prepara un piano di lavoro con una sequenza espressa in ore, non in mesi.
Fai in modo che tutte le attività non durino mai più di due giorni, meno se possibile. Se l'attività richiede più tempo, spezzala in più parti, altrimenti il piano di lavoro non può essere realistico.
SMS: Ci sono delle circostanze in cui ritieni che sia effettivamente appropriato procedere alla riscrittura totale del codice?
JS: Probabilmente no. La circostanza più estrema che mi viene in mente è il caso in cui devi contemporaneamente spostarti su una nuova piattaforma e cambiare sostanzialmente l'architettura
del codice, ma anche in un caso come questo credo sia comunque preferibile sviluppare il nuovo codice preservando il vecchio.
SMS: Hmm. Proviamo a prendere la tua teoria e a metterla in pratica. Per esempio, cosa è successo a Netscape?
JS: Tempo fa, nell'aprile del 2000, ho scritto sul mio sito che Netscape, quando ha deciso di riscrivere da zero il suo codice, aveva fatto l'errore strategico più grosso che un'azienda di software
possa fare. Lou Montulli, uno dei cinque grandi programmatori che hanno realizzato la versione originale di Navigator, mi ha mandato una e-mail per dirmi "Concordo pienamente, questa è una delle ragioni principali per cui mi sono licenziato da Netscape'
Questa singola decisione è costata a Netscape quattro anni. In tutto questo tempo non ha potuto aggiungere nuove funzionalità, non ha potuto reagire alle innovazioni competitive di lE ed è dovuta rimanere seduta a guardare con le braccia incrociate Microsoft, che si stava mangiando tutta la torta.
SMS: OK, cosa mi dici di Borland? Un altro caso famoso ...
JS: Borland, a sua volta, ha preso l'abitudine di buttare via tonnellate di ottimo vecchio codice per scriverne del nuovo. Persino dopo l'acquisto di Ashton-Tate ha comprato Arago e ha provato a inserirlo in dBASE per Wmdows, un progetto segnato, che ha portato via così tanto tempo da consentire a Microsoft Access di imporsi. Con Paradox ha deciso d'intraprendere un enorme lavoro di riscrittura in C++ per preparare la versione di Windows del prodotto. Quel che ne è risultato è stato un codice bacato e lento, mentre quello di Paradox per DOS era solido e veloce.
Dopodiché hanno rifatto lo stesso errore con Quattro Pro, riscrivendolo da zero e riuscendo a stupire il mondo con la scarsità di nuove funzionalità che avevano inserito.
(...)
SMS: Avendo lavorato alla Ashton-Tate devo dire che il codice di d.BASE IV non era certamente una bellezza. Ma ho compreso il tuo punto di vista. Personalmente ho visto casi del genere nella divisione degli editor di testi di Ashton-Tate. Dopo aver acquistato MultiMate ha speso circa due anni per pianificare una riscrittura completa del prodotto e ha buttato via mesi per valutare nuovi "motori" per la nuova versione. Alla fine non è successo proprio nulla. Quando è stata pubblicata una nuova versione del prodotto, questa si basava sempre sul solito "scadente" motore.
Naturalmente, in quei due anni, WordPerfect e Microsoft si sono mangiati la torta di Ashton-Tate.
JS: Ashton-Tate aveva un editor di testi?
SMS: Si ma, attenzione, niente del valore di WordStar!
JS: Hmm. Questo mi fa ricordare che anche Microsoft ha imparato la lezione del "non si riscrive nulla" nel modo più duro. Ha provato a riscrivere Word per Windows partendo da zero, con un progetto chiamato "Pyramid;' che poi è stato gettato nel dimenticatoio.
Fortunatamente per Microsoft, si è imbarcata in questa sciocchezza servendosi di team paralleli, cosi non ha mai dovuto fermarsi con la scrittura del vecchio codice. In questo
modo ha potuto pubblicare qualcosa, rendendo quel progetto un semplice disastro finanziario, non un disastro strategico.
(...)
SMS: WordPerfect?
JS: Questo è un caso interessante che ci porta a un altro grossolano errore nello sviluppo del software che spesso commettono le aziende: ovvero, servirsi di strumenti sbagliati per un lavoro.
Alla WordPerfect tutto, e dico tutto, doveva essere scritto in assembler.
Era una politica aziendale. Se un programmatore aveva bisogno di una piccola utilità, questa doveva essere scritta e ottimizzata a mano e in assembler. Erano le uniche persone al mondo a scrivere applicazioni per Windows in assembler. È assurdo.
È come far vestire delle ballerine con palle di ferro e catene e poi legare le braccia intorno alla vita.
SMS: In che cosa avrebbero dovuto scrivere il loro codice?
JS: A quei tempi? In C o magari in Pascal. I programmatori dovrebbero sempre utilizzare degli strumenti di basso livello, per realizzare quelle parti dei programmi cui conferiscono loro stessi maggior valore aggiunto. Per esempio, se stai scrivendo il codice di un gioco, dove gli effetti 3D rappresentano il punto di forza, non puoi servirti di un motore 3D comprato in un normale negozio; devi prepararti il tuo. Ma se il punto di forza del tuo gioco è la storia, non stare a perdere tempo per preparare grafiche 3D strabilianti - vai in un negozio e comprati un prodotto adeguato.
Ma WordPerfect stava scrivendo il codice UI che opera "a tempo di utente" e non necessita quindi di essere particolarmente veloce. Scrivere in assembler è da malati e non aggiunge alcun valore.
SMS: OK, ma non si tratta di un tipo di codice semplice e sottile?
Non si dovrebbe scrivere in questo modo per evitare la
temutissima etichetta bloatware, che indica quei software che richiedono una sproporzionata quantità di memoria e di spazio su disco per poter operare?
JS: Non farmi cominciare! Se sei un produttore di software ci sono un sacco di ragioni, anche di business, perché tu possa amare il bloatware. Per prima cosa, se i programmatori non devono stare a pensare quanto sia grande il loro codice, possono consegnarti il lavoro più in fretta. E questo significa che ottieni anche più funzionalità, e le funzionalità rendono la vita degli utenti più bella (se ne servono) e certamente non fanno male a nessuno.
Come utente, se il tuo fornitore si ferma, prima di aver pubblicato il prodotto, e passa due mesi a
cercare di ridurre il codice del 50 percento, il beneficio diretto che ne trai è quasi pari a zero, mentre l'aver aspettato due mesi senza poter usufruire di nuove funzionalità, può essere un problema.
(...)
JS: Esiste una falsa credenza, estremamente comune, che viene insegnata nelle scuole commerciali e viene chiamata la legge 80/20. È una legge falsa, ma sembra essere seducente per molta gente, soprattutto nel campo del software, perché sembra avere anche un senso. L'80 percento della gente usa il 20 percento delle funzionalità che ha a disposizione.
Così pensi che mettendo a punto solo il 20 percento delle funzionalità tu possa comunque vendere l'ottanta percento delle copie del prodotto.
Il problema, ovviamente, è che quelle funzionalità non sono mai le stesse. Tutti si servono di differenti funzioni.
(...)
JS: Questo è un problema piuttosto serio. Ho avuto modo di vedere un sacco di aziende che sono quasi fallite a causa dei solito programmatori con l'atteggiamento da primadonna. Se la direzione di una società ha conoscenze tecniche (pensiamo a Bill Gates), il management non si fa troppi scrupoli ad argomentare con loro e
imporre il proprio punto di vista o, al massimo,licenziarli e assumerne altri.
Se, al contrario, la direzione dell'azienda non ha conoscenze tecniche (pensiamo a John Sculley), agisce come un coniglio impaurito, credendo per chissà quale motivo che
questa persona sia la sola persona al mondo a sapere come si scrive del codice; questo rappresenta il primo
passo verso il fallimento dell'azienda.
Se sei un amministratore delegato con poche conoscenze tecniche e hai dei programmatori che non intendono fare quello che chiedi, l'unica cosa che
puoi fare è licenziarli. È la tua unica speranza. Ovviamente significa che devi andare a cercarti altri talenti tecnici, cosa che comporta che le tue possibilità non siano molte. Ma è questo il motivo per cui personalmente non credo alle aziende tecnologiche che, alloro vertice, non hanno un ingegnere.
SMS: Joel, grazie mille.
Originariamente inviata da MySQL
Rispondi quotando
Le idee che ho esposto in precedenza erano mirate più che altro a rendere il codice più comprensibile a terzi. Grazie a tutti per le vostre risposte, mi hanno aiutato a comprendere molti aspetti(sopratutto sulla OOP).
