O que ensina a robótica sobre as falhas silenciosas do software?

Porque importa

Escrevemos software que atua sobre ERPs, processos e, ultimamente, máquinas. Nos três casos aparece a mesma falha: a execução foi correta e o efeito não ocorreu. Um sistema não falha apenas quando um componente se parte; falha também quando cada componente cumpre o seu contrato e o conjunto produz um resultado que ninguém queria.

A robótica dá isso como assente há décadas e desenha em conformidade. Leveson formula-o como um problema de controlo e de restrições ausentes; Thrun, Burgard e Fox partem do princípio de que o estado do mundo se estima e nunca se lê. No software de gestão continuamos a descobri-lo projeto a projeto.

O que sabemos até agora

Deixámos de tratar o registo de uma ação como prova do seu efeito. Distinguimos executado, confirmado e observado, e quando não existe sinal independente declaramo-lo como limite em vez de dar a ação por comprovada.

A transferência a partir da robótica tem uma condição. Um robô opera num ambiente que pode instrumentar com sensores próprios; um processo sobre um ERP depende de sistemas de terceiros que nem sempre oferecem um sinal de verificação. Copiar o método sem essa possibilidade produz uma falsa sensação de rigor.

O que continua em aberto

Fica em aberto que parte do método robótico — estimação de estado, restrições explícitas, verificação independente — pode sustentar-se quando o sinal tem de ser criado de propósito e custa mais do que a própria ação.

E até onde chega a analogia em processos que atravessam várias aplicações, onde o estado do mundo é a soma de registos que nenhuma parte do sistema observa por inteiro.