Tra il codice e la realtà

Nell’uso comune del termine, con ‘ottimo’ s’intende principalmente ‘molto buono‘.

In informatica (e in matematica) con soluzione ottima s’intende ‘la migliore possibile’ e ovviamente non è affatto detto che sia ‘buona’.

La differenza principale tra i due termini è (a mio parare) soprattutto il fatto che ottimo è necessariamente contestuale. E’ quindi (spesso) concretamente definibile: ad esempio l’algoritmo che utilizza meno RAM o è il più veloce a produrre i risultati, etc, etc. Ha però anche implicitamente più gradi di libertà, nel senso che il contesto nel quale va ricercato l’ottimo è spesso difficile da definire; anzi è spesso l’aspetto più difficile da definire.

Il fatto è che quasi sempre gli architetti del software non credono di avere certi gradi di libertà o, al contrario, assumono sbagliando di averli.

Io ad esempio ho sempre considerato concettualmente sbagliati i meccanismi di monitoraggio attivo del software (un software che al crash di un altro lo riavvia): non solo si rischia di non risolvere il vero problema (il crash), ma -peggio- si rischia di sviluppare un sistema di monitoraggio complesso che AGGIUNGE problemi alla piattaforma nel suo complesso.

Non per questo però non è detto che (in pratica, in un certo contesto operativo) sviluppare e mantenere un sistema di monitoraggio attivo non sia la soluzione ottima (magari pure non buona in assoluto). E’ quello che hanno pensato anche a reddit all’inizio della loro storia: in sostanza riavviare il server in modo automatico era senz’altro meglio che farlo “a mano”, svegliandosi ogni poche ore 🙂

Più seriamente l’aspetto focale è che un architetto software deve essere sempre ben conscio di dover ricercare dei massimi locali e che spesso, gli intervalli all’interno dei quali cercarli sono parte del problema e che quasi sempre sono tempo-varianti.