O trabalho de um analista de sistemas, como eu, é o de desenvolver sistemas e/ou solucionar problemas de sistemas já existentes. Essa segunda parte, a de solucionar problemas, é a parte onde a Lei de Murphy brilha fulgurante em toda a sua magnanimidade...

Desculpe, mas só com esse pleonasmo pra explicar o tanto que Murphy impera nesses casos.

A coisa funciona mais ou menos assim:

1) Você é notificado de um problema no programa X.

2) Quando você está investigando o problema no programa X, e vai usar o programa Y para te ajudar a detectar a causa, você descobre que o programa Y não está funcionando. Aí você começa a solucionar o problema no programa Y, porque depende dele para continuar investigando o problema do programa X.

3) Quando você descobre e conserta o problema do programa Y, a solução do problema no programa Y causa um problema em outro módulo do programa Y. Aí você tem que consertar este outro pedaço do programa Y.

4) O passo 3 se repete umas 3 vezes, até que você finalmente consegue botar o programa Y nos eixos.

5) Quando você roda o programa Y, descobre que ele usa um banco dados de teste, Z, que não está atualizado. Você vai na máquina de café e toma um "extra-forte" pra contrabalançar o desânimo que começou a bater.

5) Quando você tenta atualizar o banco de dados Z, você obtém uma mensagem de erro porque Z compartilha umas tabelas com o banco de dados W e se você tentar mexer só em Z vai causar um erro de integridade em Z e W.

6) Quando você finalmente consegue atualizar Z e W (depois de resolver outro problema de integridade com outro banco de dados K), você bota o programa Y pra rodar. E tudo funciona certinho, o erro que você estava procurando não acontece e você não sabe por quê. Você descobre que tem que copiar uns dados do banco de dados real, R, onde o problema acontece, para o banco de dados de teste, Z, para poder reproduzir o erro corretamente. Aqui é a hora do segundo café.

7) Nessa cópia o passo 5 se repete algumas vezes. O café também.

8) Você limpa o suor do rosto quando finalmente o banco de dados de teste (o Z) está no jeito. Esperançoso, logo que você bota o programa Y pra rodar, ele dá zilhões de erros e fica maluco de uma hora pra outra: são os dados novos que você botou no banco de dados...

9) Repita o passo 3, o de consertar o programa Y, mais algumas vezes. Entre elas, palavrões à vontade.

10) Ao rodar o programa Y de novo, nada de erro, tudo funciona certinho. Você fica repetindo pra si mesmo: "Coragem, coragem" enquanto mexe no banco de dados Z para tentar fazer o erro acontecer pra poder investigá-lo, quando de repente o banco de dados dá uma mensagem maluca contendo as temidas Quatro Palavras do Apocalipse, "Unknown", "Fatal", "Failure" e "Unrecoverable". Alguma coisa desconhecida invalidou o banco de dados e ele está inacessível. Todinho. Você bate na mesa, xinga palavrões à vontade, pega o telefone e tenta parecer calmo ao pedir ao administrador de banco de dados pra restaurar um backup pra você.

11) Após restaurar o backup (coisa rápida, umas duas horas), você, obviamente, tem que copiar de novo aqueles dados pra atualizar o banco de dados, e sofrer todos os problemas de integridade tudo de novo.

12) Quando finalmente está tudo nos trinques, tem uns cinco copos vazios de café na sua mesa, a Barra de Tarefas do Windows está com umas 12 janelas abertas (você nem se lembra mais pra quê abriu a maioria delas), seus batimentos cardíacos já estão em 140 e sua pressão sanguína nem se fala. Aí, você bota o programa Y pra rodar e ele dá pau. O motivo? Quando restauraram o banco de dados esqueceram de dar permissões para o programa Y acessá-lo...

13) Você pega o telefone e liga pro administrador do Banco de Dados, mas já são mais de seis horas e ele já foi embora. E, sim, é só ele que pode dar as permissões. Você bate a cabeça na mesa, quase chorando ao se lembrar que isso tudo é pro maldito programa Y, que nada mais é que uma ferramenta besta pra te ajudar a consertar o programa X, onde o problema realmente está e onde você sequer começou a trabalhar. Sentindo-se o pior dos fracassados e de mãos atadas já que o administrador de BD foi embora, você vai embora também.

14) No dia seguinte, logo de manhã tem um abacaxi enorme pra descascar e você não tem tempo de retomar o problema no programa X. Isso se repete por uns três dias, tempo suficiente pra você se esquecer do que estava fazendo com o programa X..

15) Uma semana depois, quando as coisas estão mais tranquilas, você vê o email notificando do problema no programa X... mas não consegue se lembrar de onde parou na investigação. Não tem outro jeito: volte ao passo 2 e recomece todo este roteiro novamente...

E eu estudei quatro anos pra isso.