E’ già da diverso tempo che ho in testa questo argomento. Spesso la progettazione e lo sviluppo vengono paragonate all’architettura, da cui vengono presi a prestito vari modelli. Un esempio su tutti è la qualifica software architect.
A mio parere assimilare il processo di realizzazione di un software al processo di realizzazione di un edificio è decisamente fuorviante e ci sono più divergenze che similitudini.
Consideriamo come viene fatto un edificio: si parte dal progetto che viene approvato (a volte accompagnato della presentazione di un plastico) e da lì si comincia a costruire. Una volta che si comincia alcune cose diventano immutabili, per esempio non è più possibile (se non con costi ed oneri esagerati) spostare la costruzione o cambiare forma alle fondamenta. E’ possibile cambiare i particolari, le collocazioni di alcuni muri, ma la natura dello stabile rimane quella del progetto. La costruzione viene fatta da una serie di figure completamente diverse e spesso molto specializzate, chi tira su i muri difficilmente monta gli infissi o fa l’impianto elettrico o quello idraulico o posa i pavimenti. L’architetto o l’ingegnere o il geometra vanno in cantiere per assicurarsi che il direttore lavori segua fedelmente il progetto, ma sicuramente “non vanno alla betoniera”. Un altro fattore importante è l’interscambiabilità, un muratore un giorno fa un pezzo di muro che il giorno dopo può essere finito da un collega, senza particolari passaggi di consegna.
In sostanza tutto procede secondo logiche preordinate e basate su standard accettati. (Se qualcuno pensa che nei cantieri edili ci sia il caos legga quello che segue).
Nell’informatica invece non accade nulla o quasi di tutto questo. Il committente spesso aprrova un progetto non conoscendo i dettagli di cosa verrà fuori e capisce cosa vuole solo quando vede funzionare un pezzo di software. Ne risulta che spesso è necessario un ciclo di prototipi e rilasci per tarare il tiro. Chi di noi andrebbe ogni giorno in un cantiere cantiere che ha commissionato dicendo “mi sposti la finestra più in qua” o “le piastrelle che ho scelto e che avete montato non mi piacciono più” o ancora “mi sposta la casa altri di 30cm dalla strada”? aggiungendo “tanto quanto vuoi che costi”?
Chi costruisce una casa sa benissimo che dopo che un pezzo è stato fatto c’è un costo ben preciso per buttare giù e rifare. Chi commissiona un software evidentemente no.
Un altro aspetto è la specializzazione che nell’informatica è molto meno sviluppata, proviamo a lasciare una classe o anche una funzione a metà ed assegnare ad un altro programmatore il compito di finirla; quanto tempo ci vuole per la presa in carico di quanto già fatto? Inoltre spesso unprogrammatore svolge diversi compiti (design dell’interfaccia grafica, modellazione/definizione di parti della base dati, etc)
Un altro indicatore che indica quanto la produzione del software sia diversa e più arretrata rispetto alle costruzioni edili è la presenza dei building block ovvero dei componenti riusabili. Nell’edilizia si usano, mattoni porte e finestre già fatte, nell’informatica molto meno. Cosa succederebbe se un giorno entraste nel cantiene dove stanno costruendo casa vostra e vedeste un muratore che con un camino acceso fabbrica dei mattoni? Immaginiamo il dialogo:
Noi: Buongiorno, cosa sta facendo?
Muratore: Buongiorno, sto facendo i mattoni per costruire la casa
Noi: Perchè?
Muratore: Sa, quelli che sono in commercio non mipiacciono tanto, poi hanno quegli spigoli così ruvidi, me li faccio io così faccio prima e sono come mi servono.
Il risultato sarebbe: fuori dal cantiere a calci nel sedere.
Nell’informatica molto pochi si scandalizzano se qualcuno nel 2008 si fa un package di logging in java o in .net eppure la fine dovrebbe essere quella del mutatore sopra citato.
Un’altra differenza sostanziale è che chi comincia a programmare fa una carriera in cui pian piano diventa coordinatore e poi project manager o commerciale; quanti muratori-architetetti o elettricisti-ingegneri conosciamo?
Si conclude qui questa riflessione sul processo di costruzione software e sulle sue differenze rispetto al processo di costruzione edile. Tutti i fattori elencati fanno parte della fase costruzione, manca ancora la fase “manutenzione e post vendita”, ma credo che già si intuisca come parlare di software architect sia una cosa che non ha fondamento reale. Nei prossimi articoli proverò ad illustrare altre differenze e delle metafore più appropriate.
