Ultimamente mi trovo spesso a leggere di sviluppatori che non conoscono determinati acronimi, o che si ritrovano a chiamarsi “sviluppatori” senza sapere cosa effettivamente significhi sviluppare software.

E come al solito mi triggero sulle basi e vado dritto come un pesce all’amo tentando di sviscerare un argomento che molti altri più bravi di me hanno tentato di sviscerare in libri interi spesso riuscendoci solo in parte.

Mi ripeto sempre che è una cattiva idea usare un blog per parlare di un argomento così vasto e che i grandi come Uncle Bob e Kent Beck si rivolterebbero nella tomba se ne avessero una.

Ma siccome sono entrambi ancora vivi, non temo questa reazione e quindi sbaglio con piacere, sperando anche di fare cosa gradita a quei 3 scappati di casa che leggono questo sito.

Inizio, dopo l’inizio, dicendo che le basi dello sviluppo di software sono tante, e lo sviluppo di software è un’arte complessa che merita tempo per lo studio e dedizione per la materia, mancanti le quali il software non può essere sviluppato oppure può esserlo ma sarà brutto, poco performante, difficile da mantenere e probabilmente pieno di problemi.

E soprattutto, un software sviluppato senza conoscere le basi sarà consegnato in ritardo, sempre. Qui non ci sono deroghe.

Il TDD è una di quelle metodologie che più spesso viene bistrattata qui in Italia. Spesso si sente definire questo approccio come troppo costoso o peggio come fallimentare.
Molto spesso la “colpa” va al budget, sempre troppo risicato quantunque esso sia, ma qui si sa che la coperta viene commissionata su misura per un watusso e poi arrotolata fino a non coprirci neanche un pigmeo. E quello deve bastarti, altra non ne srotolano.

Al di là delle facili critiche e delle superficiali battute tragicomiche, il fatto è che c’è molto ancora da fare per convincere i più biechi antagonisti di questa tecnica che vale la pena iniziare a fare dei test un componente necessario di ogni progetto.

Ho sempre lottato contro le cattive pratiche, chi mi conosce lo sa.
Ho sempre parteggiato per il codice di qualità, con la forte convinzione che questo possa essere un vantaggio strategico per il progetto e l’azienda che ne è proprietaria.

Proprio per questi motivi ancora oggi, da 12 anni, non riesco a comprendere perché certi project owners abbiano sempre l’idea di risparmiare il budget dello sviluppo tagliando sulla qualità. Che poi risparmiare sulla qualità non significa niente, non è che a comando siccome ti pagano di meno puoi fare un lavoro schifoso. E infatti, per forzare il programmatore a produrre codice schifoso spingono sul fattore tempo (che è sempre poco).