Avete mai sentito parlare di
SEMA? Lasciate stare quel link: se seguite questo blog, vuol dire che siete assolutamente incapaci di comprendere le cose spiegate in quelle pagine.
Proverò ad imboccarvi io.
SEMA sta per
Software Engineering Measurement and Analysis. È un sistema di misurazione e analisi dell'ingegneria del software. Un sistema
scientifico, diciamo.
Da questo sistema deriva un test molto semplice, chiamato
test di joel (lasciate perdere anche questo link, è per referenza, non c'è bisogno che lo seguiate).
Joel Spolsky - che dirà molto poco a tutti voi chiusi nelle cantine di Merdaillogic - non è proprio l'ultimo arrivato, anzi.
Il primo consiglio che vi do infatti, è quello di fare un po' d'ordine sul comodino.
Dovreste subito dare fuoco a quel ridicolo romanzetto, si, quell'
oceano blu regalatovi qualche anno fa.
Dai: quello che sta proprio sul vostro comodino, sotto all'altro libricino arancione che non avete ancora avuto il coraggio di aprire. Quello regalatovi più di recente, LA CASTA (da che pulpito, poi...).
Ecco, già che ci siete, prima che arrivi l'estate, date fuoco a tutti e due e leggete
Joel on Software. Già ai primi capitoli, capitolerete comprendendo in maniera capitale dove siete capitati: l'azienda in cui vi fate il culo è
destinata al fallimento!
Se proprio non ce la fate, nelle prossime righe affronteremo l'argomento in maniera semplice.
For merdalogichers, diciamo (
for meedalogichers è il livello successivo a
for dummies, superato solo dall'ultimo gradino:
for silviers, metodo conosciuto anche nell'antichità con il suo nome latino,
ad Regis)(se nemmeno ad Regis funziona, ripete ad Libidum)(sfumando).
Quello che segue è il test con le risposte proprio come se le avesse date Merdaillogic, in prima persona. O nella persona di un super top mega manager a scelta
fra quelli nella foto (i licenziati non valgono. E nemmeno quelli con la maglia rossa)
Eccoci, quindi, al nostro personale test di joel.
- Gli sviluppatori utilizzano un tool per il versionamento dei sorgenti?
Eh, come no. Utilizzano il gianfilinux, un tool molto più avanzato di qualunque CVS. Non serve nemmeno che lo installi. E poi è una invenzione del GRANDE CAPO, e TUTTE le invenzioni del grande capo vanno rispettate religiosamente.
- Esso è in grado di creare una build con un unico comando?
Si, certamente. Il comando è: [urlando come una pazza isterica che non scopa da meeeeesi] GIORGIOOOOOO. [quello che segue va pronunciato fra lo stizzito e il porca troia] Per favore mi compili il pacchetto nxporc.tro.6.UNA-STR-VAFF-NCL.tar.gz. E mi raccomando, non dimenticare la baseline.
- Vengono fatte build giornalmente?
Ehm, per build, intendi build funzionanti?
- Si lavora con una base dati dei malfunzionamenti?
Certamente, c'è una enorme base dati dei malfunzionamenti. Da ignorare perché stiamo ancora decidendo come deve funzionare la feature mentre lo sviluppatore la sta già sviluppando. Così, se cambiamo idea, facciamo prima. E, in genere, cambiamo idea.
- I bug vengono corretti prima di scrivere nuovo codice?
In realtà, prima scriviamo tutto il codice e poi quello che non funziona lo rilasciamo commentato (se ce ne accorgiamo in tempo).
- Viene tenuto aggiornato lo stato di avanzamento del lavoro?
Certo. Lo stato di avanzamento viene aggiornato ogni volta che al capo viene un'idea nuova che sostituisce quella vecchia che stavamo sviluppando che quindi viene lasciata a metà o cambiata prima di finirla e si prosegue con quella nuova.
Più si avvicina la data del rilascio, più idee vengono al capo. In generale, siccome la data del rilascio viene decisa PRIMA delle idee che gli sono venute, più si avvicina il giorno del rilascio e più lo stato di avanzamento arretra.
- Si lavora con un documento di specifiche?
Certo, il documento di specifiche è costituito da una mail che si chiama FEATURE REQUEST. Questa mail l'ha scritta una che non sa nemmeno dove sta di casa il codice. È il riassunto di quello che le ha spiegato il super mega grande capo che ha parlato una lingua che quella che ha scritto la mail non capisce. Spesso succede che lo sviluppatore sta sviluppando qualcosa che è molto, molto lontano da quella che era l'dea originale del capo. Quando il capo se ne accorge, generalmente se lo incula.
- L'ambiente di lavoro risulta essere tranquillo?
Come il Vietnam nel '67. E io amo l'odore del napalm al mattino.
- Vengono utilizzati i migliori tool disponibili sul mercato?
Certo. Scarichiamo tutti i migliori software crackati del momento e li facciamo girare su macchine del 1993.
- Vi sono dei tester nel team?
Certo, tutti gli sviluppatori.
- Nei colloqui dei candidati che dovrebbero entrare nel team, viene fatto scrivere del codice?
A che servirebbe. Tanto sono dei deficenti che non saranno mai bravi come il super mega grande capo migliore di tutti. Quindi presupponiamo che siano degli idioti che non sanno fare niente e che devono imparare ogni cosa che gli diciamo di fare.
Noi assumiamo chiunque.
Li teniamo 2 mesi a macinare gratis, e se sono abbastanza deficenti da rimanere oltre imparando da soli tutto quello che noi desideriamo, allora li teniamo con uno stipendio da fame, li spremiamo come limoni del gange e quando non ce la fanno più li sbattiamo fuori a calci nel culo senza dargli la possibilità di trasmettere la loro memoria storica ai nuovi assunti.
Ma li costringiamo a ringraziarci, prima.
ps. questo da al software una certa eccentrica vivacità: è il nostro punto di forza.
- Vengono effettuati dei test di usabilità?
Certamente. Li fanno tutti quelli che comprano il software.
Il test finisce qui.
Purtroppo con queste risposte non è stato possibile classificare la bontà del software, ma se ci dovesse essere qualcosa che si distacca dalla realtà, vi preghiamo di segnalarlo nei commenti a questo post.
Per quelli che me lo chiedono, il titolo del post è un acronimo. Leggete le iniziali.
