Ogni azienda fa il software a modo suo, scegliendo gli strumenti giusti e fabbricando gli strumenti e i componenti che servono per costruire il suo prodotto.
Non sempre ci si ricorda, però di quali siano le priorità , rischiando di sbagliare.
Non c’è sviluppatore senza le proprie librerie, ognuno passa molto tempo a costruirle e rifinirle e le considera il tesoro più importante accumulato in anni di lavoro.
Succede però che ci sono anche inconvenienti nel riempire la cassetta di attrezzi costruiti in casa.
La libreria per l’accesso a database, costruisce uno strato sopra le primitive del linguaggio che può irrigidire il software complicando la possibilità di seguire le evoluzioni di una piattaforma, può fare caching nel modo giusto in un dato periodo e magari sbagliato nel corso del tempo, crea uno strato proprietario che può rendere difficile riutilizzare immediatamente le competenze dei nuovi assunti o il codice scaricato dalla rete.
Ogni nuovo assunto deve essere dotato di un ambiente software complesso e configurato nel modo corretto per poter realizzare del software e eventualmente anche la realizzazione di una minima funzionalità richiede un ambiente software accuratamente confezionato per offrire servizi che forse non sono richiesti dal progetto.
Quando ci si trova in queste condizioni è evidente che si è esagerato con l’accoppiamento fra parti del progetto che non si riescono più a staccare, funzioni di libreria che si richiamano fra loro alzando il livello di complessità piuttosto che riducendolo.
Per evitare l’errore ci sono due strategie da tenere in conto.
In primo luogo bisogna avere l’accortezza di mantenere il più possibile sottile lo strato di collante e di servizi di base indispensabile, stando molto attenti alle dipendenze incrociate.
Bisogna anche creare parti riutilizzabili come componenti con un accoppiamento minimo. Se un oggetto fa un log deve bastare che possieda un logger, non deve essere richiesto che derivi da qualche oggetto primario con decine di dipendenze, fra cui un logger.
In secondo luogo conviene resistere alla tentazione di fare crescere l’ambiente software minimo necessario per un progetto qualsiasi.
Una regola semplice è concentrarsi su quello che è necessario per l’obiettivo aziendale. Se si fa commercio elettronico, il software che permette di navigare fra le categorie e di presentare prodotti correlati, recensioni degli utenti e offerte speciali è una ricchezza primaria.
La libreria per la comunicazione con web service, per fare un esempio, è invece assolutamente un pezzo di infrastruttura da reperire sul mercato e a cui non dedicare attenzione, meno che mai per creare un pezzo di software da tenersi sul gobbo per tutto il resto del tempo.
Insomma, il lingo aziendale deve assomigliare a un linguaggio specifico per il dominio centrato sull’obiettivo di business di un’azienda.