Sistemas e Software, muitas vezes são tratados como se fossem a mesma coisa. É preciso entender a diferença, ainda mais quando tratamos de Engenharia e discutimos débito técnico.
A Engenharia de Software é a arte que aplica de forma sistemática, disciplinada e quantificável técnicas e práticas para desenvolver, operar e manter software: programas de computador ou aplicativos que permitem realizar funcionalidades em uma ampla área de aplicações e em diferentes dispositivos e equipamentos computacionais.
A Engenharia de Sistemas é, por usa vez, a arte que aplica de forma sistemática, disciplinada e quantificável técnicas e práticas para desenvolver, operar e manter sistemas: grupos de sub-sistemas e componentes que vão do elemento humano aos processos, programas ou aplicativos (software), dispositivos e equipamentos (hardware) computacionais ou mecânicos que entregam funcionalidades esperadas.
Na Engenharia de Software
Um débito técnico na Engenharia de Software pode ser definido com a falta de implementação de uma funcionalidade do aplicativo, ou como um código mal construído, mas que opera de forma suficientemente correta.
Os débitos técnicos podem ser de várias tipos: deliberados ou inadvertidos, arriscados ou prudentes, e ter várias origens, em última análise, quem deve, por exemplo: arquitetura, projeto, codificação, infraestrutura, ou outros.
Débitos técnicos devem ser corrigidos. Precisam ser pagos com um esforço de desenvolvimento ou com retrabalho (refactoring). Caso contrário tendem a aumentar com o crescimento da complexidade do aplicativo ou impedem a implementação de outras funcionalidades. São os juros deste débito.
Mas o aplicativo deve funcionar, pode não estar completo, mas deve operar corretamente e ser estável, apesar do débito técnico.
Na Engenharia de Sistemas
Um débito técnico na Engenharia de Sistemas ou é a falta de um subsistema ou é um subsistema que terá que ser re-implementado. Mas quando se pensa em sistemas o que seria um débito técnico implica que o sistema não é completo, correto e estável.
Todo sistema complexo apresenta comportamentos emergentes que podem ser positivos ou negativos. A falta de um subsistema ou a sua implementação de forma não-ideal, que preciser ser refeita, pode gerar um comportamento emergente negativo pondo em risco todo o sistema, sua função e/ou operação. Não é coincidência que uma emergência seja um termo relacionado a um comportamento emergente negativo em um sistema.
São falhas potencias ou que ocorrem e levam a emergências ou permanecem como armadilhas prontas a atuarem em uma próxima cadeia de eventos que levam a uma emergência e a potencial perda do sistema.
Aprendendo do passado
Olhando o passado, para evitar a polarização em torno de soluções atuais. Um dos projetos de maior porte e mais bem documentados na literatura foi o projeto Apolo:
- o computador do Módulo Lunar ficar sobrecarregado dar um alarme e passar a executar só os processos críticos pode ser considerado um débito técnico do software. Debito deliberado, prudente, gerado pela incapacidade conhecida do hardware.
Porém,
- o ambiente a bordo do módulo de controle da Apolo 1 ser de puro oxigênio, permitiu um incêndio, ainda na fase de testes, levando a perda dos três astronautas,
ou
- um fio/conexão mal testado no agitador de um dos tanques do Modulo de Serviço da Apolo 13, levou a uma emergência que, como descrito em livros e filme, sem esforços extremos dos astronautas e das equipes em terra teria sido fatal.
Débitos em sistemas, são falhas, são problemas que podem levar a comportamentos emergentes negativos - emergências - e a perda de todo o sistema.
Não deveríamos levar os maus hábitos da Engenharia de Software para a Engenharia de Sistemas.