Ebbene sì, REALIZZARE SOFTWARE è DIFFICILE! Questa affermazione può sembrare banale oppure scontata, ma racchiude una indiscutibile verità. è da tanto tempo che avrei voluto scrivere qualcosa in merito e condividere il mio pensiero con altre persone del settore, colgo l'occasione per farlo adesso che ho un blog tutto mio!

Negli anni passati ho fatto svariate esperienze in ambito lavorativo che mi hanno portato a ricoprire i ruoli più disparati nell'ambito delle aziende in cui ho lavorato, dal semplice programmatore al docente in corsi di project management e MS Project, da sistemista ad analista e progettista SW, da capo progetto a responsabile tecnologico. Sarà che nei durissimi anni dell'università mi hanno insegnato ad affrontare i problemi e i quesiti con un certo metodo e non in modo caotico, saranno le esperienze fatte quando lavoravo sulle tematiche legate al project management, sarà addirittura la mia indole personale, fatto stà che in tutte le occasioni lavorative che mi hanno riguardato ho sempre dato la massima importanza all'approccio. E proprio qui stà a mio parere il punto!

Realizzare software è difficile perchè il risultato è impalpabile, è astratto, non si vede e non si tocca. L'unica cosa che ci permette di interagire col software è l'interfaccia e possiamo qualificare un software come corretto solo se i risultati al termine dell'elaborazione sono esattamente quelli attesi. Il software rappresenta una sorta di scatola nera dentro alla quale inseriamo qualcosa per ottenere qualcos'altro: se il risultato è quello atteso, bene, altrimenti bisogna rivedere le cose. Il fatto che il software sia astratto (non si vede e non si tocca) rende le cose ancora più complicate: l'unico modo con cui possiamo difenderci dal rischio di fare un software tutt'altro che di qualità lontano dalle specifiche richieste, è quello di realizzarlo secondo certe regole dando ordine alle nostre azioni.

A chi non è capitato di dover mettere le mani in applicazioni realizzate male e in fretta e furia da persone più o meno qualificate a farlo? A me purtroppo è capitato e non una volta sola. Ecco (ahimè!) alcuni esempi: database non normalizzati dove lo schema è un disastro, tabelle e campi nei DB con i nomi più disparati e fantasiosi, uso dei tipi selvaggio e incongruente, applicazioni caratterizzate da una stratificazione inesistente o eccessiva (5 strati applicativi per realizzare un carrello di raccolta ordini mi sembrano francamente un'esagerazione), uso di classi ed oggetti dove le proprietà sono in realtà metodi, dove i metodi hanno i nomi più assurdi, dove i campi non esistono (a questo punto se le classi sono sempre e solo dei contenitori di funzioni, a cosa servono?), dove non esistono relazioni tra i vari oggetti nè di generalizzazione, nè di specializzazione (ereditarietà e interfacce: queste sconosciute!), interfacce utente incongruenti e confusionarie (come detto prima, l'interfaccia utente è l'unica cosa che si vede!), ecc... :'( SIGH! Perchè succede questo? Me lo chiedo ogni volta che mi trovo di fronte a questo tipo di applicazioni, pensate male e realizzate ancora peggio! Per chi come me ama il proprio mestiere (che in realtà è più una passione che altro), vedere certe "brutture" mette decisamente di cattivo umore e porta ad esclamazioni del tipo: "P0rK@#%H$#X$Y&@#!?!?!!".

Ma ritorniamo al punto. Perchè succede questo? Beh, la risposta non è unica secondo me, le motivazioni possono essere molteplici. Cercherò di spiegarmi in modo schematico.

Motivazioni:

a) Mancanza di analisi, pianificazione e progettazione
Mi è capitato di sentirmi dire che "scrivere documentazione di analisi e progettazione è un'inutile perdita di tempo, tanto le specifiche sono in continua evoluzione". Niente di più sbagliato, a mio avviso. La definizione del contesto in cui un team di sviluppo lavora è alla base della buona riuscita di un progetto. Una pianificazione che definisca le responsabilità e gli ambiti di ciascuno, l'individuazione delle notazioni e delle regole comuni da applicare in fase di analisi e in fase realizzativa, la raccolta "ordinata" delle specifiche, la creazione di un "manifesto" per il database e per il contesto applicativo (interfaccia utente, classi e oggetti BLL/DAL, stratificazione, architettura) condiviso da tutti sono il minimo per poter lavorare in maniera quanto meno decente. E lo stesso discorso si applica anche quando a programmare è solo una persona. Spesso invece si lasciano molti di questi aspetti al caso e il team di sviluppo diventa un insieme disgregato di persone che lavorano sulla stessa cosa, ma nessuno in realtà sa bene cosa! E le riunioni in quest'ottica non sono preziosi momenti per scambiarsi idee e definire attività e responsabilità, ma l'occasione per fare una pausa, bersi un caffè e fumarsi una cicca.

b) Mancanza di competenza
Non sempre chi progetta e/o realizza un software conosce a pieno la tecnologia. Questo è un errore, anche se in prima istanza l'analisi (quando viene fatta) è sempre slegata dalle scelte tecnologiche. Ma durante la realizzazione conoscere gli strumenti e le metodologie di sviluppo è un prerequisito importante per ottenere un risultato di qualità. E la competenza la si ottiene solo studiando (non si può pensare di sapere le cose se non si studiano prima), testando e sperimentando (se non provi, non sai!), maturando le proprie conoscenze e condividendole con gli altri (lavorare insieme significa anche condividere).

c) Mancanza di tempo
Quante volte il commerciale di turno ha svenduto il progetto? Quante volte ci è stato chiesto di realizzare il software in tempi strettissimi perchè i soldi erano pochi? E allora la prima cosa istintiva che viene da fare è quella di mettersi a smanettare a testa bassa per fare il più in fretta possibile. Niente di peggio!

Di motivazioni ce ne saranno senz'altro altre, ma in questo momento non me ne vengono in mente.

Per fortuna la tendenza di oggi è quella di andare verso soluzioni (vedi per esempio .NET oppure J2EE) che obbligano ciascun sviluppatore di software ad un approccio "ordinato". L'uso di oggetti strutturati quali sono le classi, l'uso di interfacce, i vari paradigmi propri della programmazione orientata agli oggetti, i design patterns come il design by contracts, ecc. portano inevitabilmente a scrivere codice fortemente strutturato ed ordinato, secondo certi schemi e regole pre-individuate. In questa ottica diventano fondamentali la pianificazione, l'analisi e la progettazione.

Ritornando al concetto iniziale (realizzare software è difficile), mi auguro che assisteremo ad una sorta di selezione naturale, dove avrà vita facile solo chi accetta l'idea che i prerequisiti indispensabili per realizzare software di qualità siano la pianificazione e la competenza nella progettazione e nello sviluppo. Ma sarà il mercato a decidere... come del resto è già successo negli anni scorsi.

Un saluto a tutti.