Manifesto

Perché SIForge.org

SIForge.org nasce dall'idea di tre giovani ragazzi (Stefano Fago, Giovanni Giorgi, Marco Lamberto), usciti dal Dipartimento di Informatica di Milano, con in comune la passione per tutto ciò che è informatica. L'obiettivo è quello di creare una community che parli di IT contestualizzata nella realtà italiana. SIForge.org nasce dalla nostra esperienza di lavoro sul campo, e da un'attenta riflessione basata sul nostro background culturale. Intendiamo presentare una serie di articoli, non solo tecnici, il cui scopo sia quello di stimolare la discussione da parte dei lettori, confrontando le reciproche esperienze.
Veniamo tutti e tre da un mondo universitario in cui si dà ampio spazio agli aspetti teorici delle tecnologie informatiche (come è giusto che sia). E dopo un periodo di adattamento nel mondo del lavoro, un po' di esperienza e qualche riflessione, siamo qui a raccontare la nostra visione del mondo IT.

Il sogno idilliaco: il software è tecnologia

La cosa bella del software è che non servono macchinari costosi per realizzarlo. Mentre per realizzare una casa di due piani non basta un badile, per realizzare un piccolo software serve magari un buon PC, un compilatore gratuito e un ottimo "talento". Non è necessario partire con grossi investimenti, almeno all'inizio.

Ci sono studi, iniziati più di trent'anni fa, che ci dicono quale sia il modo migliore per progettare (UML), implementare (algoritmi, design pattern) e vendere il nostro piccolo pezzo di ingegno creativo.

Sembra facile, eh?

Il brusco risveglio: il software andava realizzato ieri...

Vediamo cosa succede quando il nostro fiducioso informatico, fresco di laurea, viene assunto in un'azienda di consulenza. Qui ci si accorge che il lavoro è il risultato di una complessa mediazione tra diverse parti:

• Da una parte c'è il committente (il Cliente) che ha una esigenza pressante. Un po' come un malato che va da un medico, e non vede l'ora che il "preparato informatico" gli risolva il problema.
• Dall'altra parte c'è la Nostra azienda, formata da:
  • Un account, che si preoccupa di farsi pagare il giusto.
  • Un responsabile tecnico della consegna del progetto (Client Delivery Manager)
  • Un Project Manager, che realizza e coordina un team di Software Engineer.
  • Varie ed eventuali figure "di contorno".

Non sempre tutte queste figure sono necessarie: per esempio un progetto che deve integrare due semplici componenti legacy potrebbe non aver bisogno di un Project Manager ma solo del CDM, mentre un progetto da vendere a scatola chiusa (es un videogioco) potrebbe non richiedere un CDM ma magari un dipartimento di marketing molto articolato.

Il software risultante quindi può nascere per 1/3 dalla specifica, per 1/3 dalle esigenze sui costi, e per 1/3 dai tempi.

Il professionista con il solido background tecnico, si trova qui ad affrontare una realtà ben più complessa, ove discorsi quali la "politica tecnologica" del cliente, le "convenienze e sinergie" interne all'azienda, le certificazioni di qualità e i costi hanno un peso spesso superiore alla scelta della "tecnologia più elettrizzante per sviluppare il progetto".

Le capacità da una parte di delimitare le esigenze del Cliente, dall'altra di saperle prevenire per offrire nuovi prodotti (e quindi commesse) diventano essenziali e forse più importanti che saper scegliere il tool migliore per quel compito.

Per cui i tempi necessari per un progetto vengono dimezzati, o allungati a seconda degli eventi che si presentano all'orizzonte. Le priorità vanno riviste con il cliente, che cancella alcune attività e ne anticipa altre, e capita di aver già scritto 1000 righe di codice di una cosa che non si vuole più!

Questo porta a dover accelerare il processo di sviluppo software, magari costringendoci spesso a compromessi che non vorremmo fare...e bisogna ricordare all'Account che "nove donne non fanno un bambino in un mese".

...e deve essere efficiente

Ovviamente però nessuno vuole un software brutto, lento e sporco; inoltre le stime per il completamento delle attività devono essere sempre precise, in modo che gli Account possano formulare offerte ragionevoli e sensate.

Il riuso magari non serve al cliente1, ma fa comodo se il cliente2 vi chiede una cosa leggermente diversa.

Per cui spesso si è costretti a correre, con le scadenze prossime, con molte esigenze, come quella di scrivere un codice che sia comprensibile anche ai colleghi intorno, oltre che a noi, ecc, ecc.

Il software è una salsiccia?

Forse il software è una salsiccia, o forse rischia di esserlo solo se noi non tentiamo di guidare consapevolmente il suo processo. Da una parte infatti abbiamo una spinta data dalle esigenze del Cliente, dall'altra la realtà dell'informatica attuale, ove scelte sbagliate di progetto non possono essere corrette radicalmente mentre siamo "in corsa", a meno di non reinvestire risorse in tempo e denaro.

Il mondo dello sviluppo di oggi propone dei tempi molto brevi e questo ha dato il via alla nascita di diverse metodologie, tra cui l'eXtreme Programming (XP).

Quest'ultima suggerisce, nel caso in cui una porzione vitale di codice sia scritta in modo inadeguato, di bruciarla e riscriverla totalmente, piuttosto che tenerla così come è confidando nel fatto che il codice intorno la isoli. Spesso, anche se si trattava di più di 1500 linee di codice, la riscrittura ha richiesto meno tempo di quello che si pensasse, e alla lunga ha portato diversi vantaggi.

L'eXtreme Programming spinge tutto questo ai massimi livelli, sostenendo che lo sviluppo evolva da uno stadio prototipale, coinvolgendo l'utente finale, e operando un refactoring e un testing continui.

SIForge.org aspira a discutere di tutti quegli aspetti (metodologie, tecnologie, "buon senso sviluppato sul campo") che possono aiutarci a consegnare progetti non solo funzionanti, ma che significhino qualcosa e non siano una accozzaglia informe di codice-a-spaghetti-che-non-si-sa-bene-che-faccia.

E ricordatevi che spesso non facciamo il software per le macchine, ma per altre persone!