Il diritto di sbagliare ed il dovere di aiutare

Sono ormai tanti anni che lavoro scrivendo programmi. In particolare i programmi che realizzo fanno conti molto complessi. Si prestano a comportamenti strani ed anomali nel momento in cui l’utente, per sbaglio o per prova, fornisce come input valori anomali.

Ora qui le linee di pensiero divergono. C’è chi, in nome della velocità e della pulizia del codice, evita ogni tipo di controllo sui dati in ingresso. Il problema è del chiamante che non ha rispettato il protocollo dichiarato.

Il problema è del chiamante che non ha rispettato il protocollo dichiarato.

Per fortuna, mi sono trovato dal lato sbagliato di algoritmi scritti con questa filosofia, ricordando ancora il tempo speso a ricercare errori, per carità miei, ma senza nessun ausilio da parte del software chiamante. Nemmeno una assert.

Da allora ho fatto mia una linea guida che mi aiuta a scrivere algoritmi più amichevoli. Il chiamante ha il diritto di sbagliare ed il chiamato ha il dovere di aiutare nella ricerca dell’errore.

Il chiamante ha il diritto di sbagliare ed il chiamato ha il dovere di aiutare nella ricerca dell’errore.

A questo proposito voglio fare due esempio di software famosi. Il primo che segue questo principio, da prendere a modello, ed il secondo che non lo seguiva.

Era circa l’anno 2000, ormai 20 anni fa, ed usavo un vecchio PC per ospitare un DBMS Oracle. Se ricordo bene, la versione era la 8. I software si installavano da CD che ti veniva spedito per posta perché eri registrato come “developer”. Era la prima volta che usavo Oracle e commettevo errori molto facilmente. Nonostante questo, non ho mai sperimentato criticità oppure la necessità di operare come amministratore per recuperare questioni strane. Insomma, Oracle garantiva il mio diritto a commettere errori. E mi forniva tutti gli strumenti per trovarli e correggerli.

I software si installavano da CD che ti veniva spedito per posta perché eri registrato come “developer”.

Come esempio di software che invece non garantisce il diritto di sbagliare, voglio citare Clear Case. Clear Case è la cassaforte delle aziende che basano il loro business sulla realizzazione di software commerciale. Tutto il codice sorgente è versionato e configurato in maniera automatica, rendendo facile la collaborazione tra gruppi di sviluppatori.

Purtroppo, però, era molto facile, anzi troppo facile bloccare il repository di Clear Case. Bastava cancellare un file oppure rinominare una directory per mandare in uno stato inconsistente il sistema di versionamento. Purtroppo non sono riuscito a trovare un esempio concreto, ma gli errori venivano segnalati con messaggi criptici e l’unica speranza era quella di inserire il testo del messaggio nel portale di Rational Rose, il produttore di Clear Case, dedicato alla gestione degli errori, per cercare una soluzione al problema.

Ricordo che ad un certo punto mandai una email con oggetto “rm -fr /clearcase” per chiedere un sistema più robusto.

rm -fr /clearcase

La morale di questa storia è che nel calcolo del valore di un software ci va aggiunto anche quanto questo è robusto alle condizioni inattese o poco probabili. Quindi, consiglio a chi scrive software di aderire alla regola “il chiamante ha il diritto di sbagliare ed il chiamato ha il dovere di aiutare nella ricerca dell’errore”. Analogamente, consiglio a chi acquista i software di pagare volentieri qualcosa in più per una maggiore robustezza, perché è un investimento che ritorno presto e con interessi molto alti.