Perversões curiosas do mundo da TI

O Daily WTF coleciona histórias engraçadas, selvagens e / ou tristes do mundo da TI há 14 anos. Traduzi várias histórias que me pareciam interessantes. Todos os nomes e nomes de empresas são alterados.

Para trabalhar por 3.000 milhas

Uma história verdadeira da experiência pessoal de nosso autor Snoofle. [Original]

Muitas décadas atrás, a empresa de defesa DefCon Inc. trabalhou para o Exército dos EUA e tentou obter um novo contrato para criar algum tipo de aplicativo usado em batalha. A empresa queria demonstrar em sua proposta que tinha pessoal suficiente para realizar esse projeto. Portanto, ela contratou mais de mil programadores, gerentes de projeto, gerentes e assim por diante. Os militares, que estudaram várias ofertas comerciais, viram vários novos funcionários que não estavam familiarizados com os processos, procedimentos e requisitos necessários, e transferiram o contrato para outra empresa. O empreiteiro, por sua vez, demitiu todas essas mil pessoas.

Alguns meses depois, outro contrato semelhante surgiu. A empresa contratou novamente mil pessoas para mostrar que possui funcionários. Alguns meses depois, o contrato foi novamente transferido para outro contratado, e a empresa novamente dispensou todo o mil.


Ao longo de dois anos, isso foi repetido várias vezes.

Depois de tudo isso, a maior parte do pessoal disponível para contratação já estava ciente do ciclo muito curto de demissão na empresa, de modo que o contratado não podia atrair ninguém, exceto os recém-chegados que acabavam de se formar em instituições de ensino. Por fim, um gerente de alto nível ficou impressionado com o fato de que todas essas pessoas apenas por causa da mesa eram muito mais baratas do que desenvolvedores experientes na equipe da empresa, e aqueles que a empresa contratou, demitiram por causa de contratos. Portanto, ele emitiu uma ordem para que todo o pessoal experiente da empresa fosse substituído por jovens funcionários baratos . O processo levou dois anos, mas ainda aconteceu.

Agora que os custos salariais caíram significativamente e irritaram todos os candidatos a desenvolvedores experientes, a empresa poderia aumentar sua equipe permanente sem aumentar o orçamento salarial. Ela só podia contratar desenvolvedores jovens e inexperientes para finalmente conseguir um contrato.

Infelizmente, todos esses jovens desenvolvedores tinham muito pouca experiência e a empresa não tinha mais pessoas nas trincheiras que poderiam treiná-los. Portanto, o resultado do contrato de dois anos foi esse projeto não confiável, que muitas vezes falhou, se comportou de forma imprevisível e que não pôde ser modificado. Tais propriedades são indesejáveis ​​quando se lida com um sistema que deve disparar e detonar.

Em algum momento, um dos executivos seniores percebeu o que havia acontecido, forçou a empresa a parar de agir como um elefante em uma loja de porcelana e a contratar consultores altamente pagos. Infelizmente, consultores altamente remunerados lembraram-se bem do ciclo de demissões e não queriam ter nada a ver com a organização. Depois de algum tempo, a empresa teve que melhorar significativamente os termos de emprego, até que finalmente vários funcionários experientes concordaram em conseguir um emprego como empregados em período integral. Isso aconteceu em Nova Jersey.

Depois que a gerência designou esses novos funcionários para o projeto para agilizar o trabalho, os novos funcionários disseram: "Espere um pouco, há um enorme buraco no meio deste projeto!" A gerência respondeu que essa parte do projeto foi classificada e só pode ser estudada por pessoas com acesso a informações classificadas e apenas em uma empresa na Califórnia. Aprovações apropriadas foram solicitadas e recebidas, após o que os funcionários experientes foram enviados por duas semanas a uma instalação na Califórnia.

Antes de concordar com a viagem, os desenvolvedores queriam saber como eles poderiam acessar o material depois de estudar. Afinal, o acesso é possível apenas no local na Califórnia, e todos os funcionários moram e trabalham em Nova Jersey. Eles foram informados de que aprenderiam os detalhes na Califórnia.

Bem, todos voaram para a costa oeste, se hospedaram em hotéis e dirigiram para o escritório.

Nesse momento, eles foram informados de todos os problemas que precisam ser abordados. Na quinta-feira, segunda semana de trabalho, foi decidido que seriam necessários aproximadamente dois anos para concluir todas as atualizações necessárias. Os desenvolvedores novamente perguntaram: "Como teremos acesso a materiais de Nova Jersey?" Os gerentes responderam que todo o trabalho deveria ser feito localmente e eles permaneceriam na Califórnia pelos próximos dois anos. A partir da próxima segunda-feira.

Mas espere, eles não tiveram a oportunidade de discutir isso com a família! Como a ausência de 90% do tempo de um dos pais afeta os filhos? Eles querem morar em hotéis e aeroportos por dois anos? Por que diabos a empresa não contratou funcionários localmente na Califórnia, mas em Nova Jersey?

Acontece que, como o contratado está localizado em Nova Jersey, a equipe que ele contrata também deve ser registrada lá. Obviamente, se isso tivesse sido relatado antes do emprego, a maioria dos funcionários (se não todos) teria se recusado a trabalhar. Se soubessem, nenhum dos trabalhadores entraria no avião e voaria para a Califórnia para se familiarizar com o projeto.

Você nem pode dizer que o restante do trabalho dos gerentes foi afetado pela necessidade das vítimas em benefício da empresa, e os desenvolvedores se perguntaram: "Que diabos?" A noite de quinta-feira estava ocupada com intermináveis ​​ligações para casa. Na manhã de sexta-feira, todos os funcionários pararam e foram para o aeroporto para voltar para casa.

Representantes do exército se comportaram com dignidade e simpatizaram com o fato de as pessoas não quererem deixar suas casas e famílias por dois anos. No entanto, eles se tornaram muito mais difíceis quando se tratava de conversar com o contratado e de cumprir suas promessas de ter uma equipe experiente no local de trabalho.

Como resultado, o contrato com o contratado foi rescindido e foi contratado para substituir o novo.

Caso de falha

[Original]


No primeiro dia no novo emprego, Sebastian não estava particularmente entusiasmado. Ele já tinha visto muito e ganhou indiferença e pessimismo. Este novo trabalho não deveria ter sido diferente: um monte de colegas irritantes, requisitos mal pensados, antigas bases de código, cheias de código espaguete. Mas ela pagou bem, e ele estava cansado de seu antigo grupo, estava cansado dos mesmos rostos familiares. Portanto, ele se preparou internamente para tons ligeiramente novos da mesma política de escritório e tarefas sombrias.

Ele não ficou particularmente chateado quando procurou suas credenciais no departamento de TI e ouviu os zumbidos e cliques dos antigos servidores da Packard Bell. Sebastian simplesmente reduziu sua barra de requisitos para um computador em funcionamento a vários níveis e voltou ao seu novo escritório. Sim, sua posição significava seu próprio escritório e o pagamento correspondente. Para isso, ele poderia chegar a um acordo com muitas outras coisas.

Seu login funcionou na primeira tentativa, o que foi uma surpresa agradável. Ele estava esperando o Windows XP; quando o Vista foi inicializado, ele não tinha certeza se deveria se alegrar com o sistema operacional mais recente ou se horrorizar com o fato de ser o Vista. Ao completar os privilégios de administrador e aparar o UAC, ele poderia até fingir por um tempo que eram "sete". "Vai levar algo mais para me assustar", ele pensou, e iniciou o Outlook.

Já havia correio na caixa de entrada: algumas cartas de boas-vindas com informações para novos funcionários, bem como a primeira tarefa do gerente. Impressionado, para dizer o mínimo, pela eficiência na atribuição de tarefas, ele abriu uma carta de seu novo líder.

A primeira letra era algo assim:

Olá Sebastian, seja bem-vindo ao nosso ambiente de trabalho perfeitamente aprimorado. Tudo é feito corretamente. Ao criar documentos do projeto, você trabalhará com o Bonk-Word (aplicativo de documentação baseado na Web da IBM). Lembre-se de salvar seu trabalho frequentemente! Se o Bonk-Word travar, você precisará escrever uma carta para o departamento de TI para reiniciá-lo.

A empresa elabora a documentação do projeto. Escreva tudo com uma voz passiva, use violeta para indicar os títulos dos capítulos e verde para indicar os títulos das seções. Os documentos são verificados diariamente pelo presidente da empresa às 9 da manhã, portanto, esteja preparado para isso. Erros nos cabeçalhos se tornarão uma marca negra em seu arquivo pessoal.

Comece projetando uma solução para o problema de fonte do Macintosh que não conseguimos resolver por quatro anos. Amanhã, às 9 horas da manhã, você deverá ter um documento do projeto pronto de seis páginas. Obrigada

"Seis páginas para amanhã?" - Sebastian preocupado. “Acho que me alegrei com eficiência muito cedo. Bem, pelo menos não será chato ”, ele quebrou os nós dos dedos, abriu o Bonk-Word e começou a lidar com os chamados problemas de fonte.

A primeira coisa que descobriu foi que o gerente não estava brincando sobre economizar com frequência. No final do dia, ele fez apostas mentais: o que será o primeiro - Bonk-Word ou Vista. Ambos caíram após cada meia hora. Mas manter as estatísticas das partidas em um pedaço de papel tranquilizou Sebastian por algum motivo. Isso o lembrou: algo mais estava funcionando no mundo. As operações matemáticas mais simples não eram impressionantes, mas eram confiáveis. Regular. Estável.

Talvez Sebastian estivesse sozinho neste escritório. Mas ele estava quieto e separado. Embora as constantes manobras fossem irritantes, Sebastian ainda seguia em frente. Ele fez uma pausa no trabalho para estudar uma variedade de literatura sobre renderização de fontes, incluindo a especificação Postscript, a literatura sobre como usá-la e centros de informações na World Wide Web, projetados para coletar a sabedoria das melhores mentes do setor em um formato familiar e conveniente de pergunta e resposta . Ele descreveu extensivamente no documento "criando um programa Python para renderizar cada caractere". Ele passou duas páginas descrevendo o que poderia ser dito em poucas palavras.

"Se eles precisarem de seis páginas, receberão seis páginas", pensou Sebastian.

O primeiro dia acabou por ser estranho, mas Sebastian viu que ele aguentava bastante por pelo menos vários anos. Ele terminou o trabalho, deixou o prédio (que cheirava desconfiado a roupas íntimas de couro velhas) e caminhou lentamente para o seu "espaço de estacionamento gratuito" (outra vantagem que justifica esse trabalho em seus olhos). Lentamente - porque o estacionamento estava completamente corroído pela ferrugem e, em muitos lugares, o concreto caiu completamente, expondo o reforço do piso e das colunas.

Na manhã seguinte, exatamente às 9 horas, Sebastian estava no escritório de seu gerente, aguardando a primeira verificação do projeto pelo presidente da empresa, que telefonou. Sebastian sentiu-se desconfortável com a conversa diretamente com o presidente, já que havia sessenta funcionários na empresa, mas ele teve que suportar.

“Fiz como solicitado e na quantidade certa. Provavelmente, isso é apenas uma formalidade, após a qual eu posso começar a trabalhar. ”

Uma hora depois, humilhado e exausto, Sebastian voltou ao seu escritório. As críticas absurdas, mas cruéis, que ele recebeu ainda ecoavam em seus ouvidos. Segundo o presidente, seus títulos de seção não eram "esverdeados", nem verdes, como exigia a empresa, e os títulos dos capítulos eram imperdoáveis ​​"avermelhados" em vez do esperado roxo. Além disso, ele foi informado explicitamente que era "impossível" depurar fontes usando o Python. Em vez disso, Sebastian recebeu ordem de trabalhar em C ++ e usar as “maravilhosas” bibliotecas de software da empresa. Esperando a ligação do presidente, o gerente de Sebastian elogiou o documento, mas durante a verificação não disse uma palavra, olhando inseparavelmente para a parede de tijolos em sua mesa.

Sebastian fechou a porta do escritório, afastando-se do resto da empresa. Ele se sentou em sua luxuosa cadeira de couro e olhou para a tela de um computador que mal funcionava. Ele reabriu o documento e, em seguida, reiniciou a máquina porque o Vista decidiu sair do ar. Quando o computador inicializou novamente, ele verificou sua conta bancária, pensou em pagamentos de hipotecas e cerrou os dentes.

"Bem, então", disse ele em voz alta no escritório vazio. "Dê uma olhada nessas bibliotecas."

A primeira coisa que ele começou a procurar foi a documentação. Naturalmente, em uma empresa obcecada por documentos, a documentação para as bibliotecas “maravilhosas” deve ser digitada com precisão na fonte correta com uma tonalidade idealmente precisa, com os títulos de capítulo e nomes de seção corretos. Mas a documentação ... não era. Havia muitos documentos de design com cores perfeitas em verde e roxo. Mas eles descreveram apenas a metodologia de desenvolvimento de bibliotecas e não disseram nada sobre seu uso.

"Estou perdendo a cabeça?" Sebastian se perguntou quando o carro foi reiniciado pela terceira vez. "Talvez o código seja auto-documentado ..."

Ele experimentou horror, mas não houve muita surpresa: as bibliotecas consistiam em invólucros mal projetados de funções de string da biblioteca padrão.

Apesar do constante desastre, Sebastian deu o golpe. Ele era chamado diariamente por mais uma rodada de intimidação verbal. Por quatro anos, a empresa não conseguiu lidar com esse problema de fonte; no entanto, nenhuma das propostas por ele não se adequava ao presidente. Sebastian abandonou sua própria biblioteca da empresa, começando a resolver o problema no conhecido Python; no final, se eles ainda espalham podridão, por que o que eles dizem? Mas o que quer que ele tenha usado: seu próprio testador em Python, ou um testador da Microsoft, Apple ou Adobe - a fonte permaneceu em completo caos. 488 erros irradiáveis, incorrigíveis, insolúveis por patches de projeto.

O presidente recusou-se categoricamente a admitir a verdade. Ele alegou que a culpa era de Sebastian, porque ele não usou as excelentes bibliotecas C ++.

Tendo esgotado todas as opções, Sebastian deixou a chave da garagem enferrujada na mesa do gerente, juntamente com uma carta de demissão. Ele se despediu de seu doce escritório e da máquina de escrever infernal que eles distribuíam como computador. Ele respirou fundo, sentindo a pele sombria cheirar pela última vez e saiu, completamente e irrevogavelmente.

Por alguma razão, ele duvidava que sentiria falta da empresa.

Você pode ficar doente com esse tipo de assistência médica.

[Original]

Em qualquer setor, há informações que precisam ser transferidas entre sistemas incompatíveis. Se você viveu a vida dos justos, esses sistemas eram apenas aplicativos diferentes na mesma plataforma. No entanto, se você se desviou do bom caminho, esses sistemas foram escritos em diferentes idiomas para diferentes plataformas executadas em diferentes sistemas operacionais com ordem de bytes diferente. Imagine algum aplicativo Java no Safari em alguma versão do Mac OS , que precisa se comunicar com alguma versão do .NET em alguma versão do Windows , que, por sua vez, precisa se comunicar com alguma versão do COBOL com EBCIDIC binário em execução em qualquer mainframe.

Muito antes que alguém pudesse imaginar tal pesadelo, trabalhamos com o SGML que degradou e evoluiu para XML , que deve ser uma maneira aceitável trivial de especificar o formato e os campos contidos no documento com o analisador disponível em todas as plataformas, para que as informações possam ser trocadas, Não sabendo nada além de DTD e / ou esquemas de validação e análise.

Sem esperar o melhor, para simplificar o trabalho, escrevemos no topo da biblioteca de wrapper XML.

Infelizmente, eles não lidaram com a tarefa.


No setor de assistência médica, alguns profissionais de fontes copiadas criaram o projeto (H) ealthcare (API), ou HAPI , que é essencialmente um analisador de mensagens de texto orientado a objetos para o setor de assistência médica. Infelizmente, eles pareciam estar sofrendo da síndrome do "não sei quando parar" .

Em vez de implementar um analisador generalizado que simplesmente quebra uma sequência delimitada ou uma sequência de formato fixo em uma lista de valores de campos de texto, a versão mais recente implementa 1205 analisadores diferentes, cada um dos quais com sua própria estrutura de dados de alto nível. As estruturas de nível mais alto têm dezenas de subestruturas. Cada analisador possui um ou mais métodos de acesso para cada campo. Um campo pode ser uma única instância ou uma lista de instâncias; nesse caso, é necessário determinar programaticamente qual método de acesso usar.

Esta é uma API com aproximadamente 15 mil chamadas de método! O que esses desenvolvedores estavam pensando?

Por exemplo, a classe: EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO pode ter de zero ou mais seções de serviço do produto . Então, imediatamente começo a pensar em algum tipo de matriz ou lista. Portanto, em vez de algo como isto:

  EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO info = ...;
     Lista <EHC_E15_PRODUCT_SERVICE_SECTION> prodServices = info.getProductServices ();
     // itera

... precisamos fazer um destes:

  // Pega a subestrutura
     EHC_E15_PAYMENT_REMITTANCE_DETAIL_INFO info = ...;
	
     // Obtenha o serviço de produto interno da subestrutura

     // ... se tivermos certeza de que ele tem apenas uma mensagem:
     EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION ();
	
     // ... se não soubermos quantos haverá:
     int n = infos.getPRODUCT_SERVICE_SECTIONReps ();
     for (int i = 0; i <n; i ++) {
         EHC_E15_PRODUCT_SERVICE_SECTION prodSvc = info.getPRODUCT_SERVICE_SECTION (i);
         // use isso
     }

     // ... ou você pode simplesmente pegá-los e iterar
     Listar <EHC_E15_PRODUCT_SERVICE_SECTION> allSvcs = info.getPRODUCT_SERVICE_SECTIONAll (); 

... e você precisa chamar o método desejado, caso contrário corre o risco de receber uma exceção. Porém, se existem muitas maneiras de executar uma tarefa por meio da API, existem várias maneiras de executá-la no código usando a API, o que inevitavelmente leva a problemas.

Você pode dizer: "Vamos lá, nem tudo está tão ruim" ; basta usar o que você precisa. Mas então você percebe que algumas dessas estruturas de dados são incorporadas em dez ou mais níveis de profundidade, cada uma com dezenas de subestruturas e / ou campos, e todas elas têm vários métodos de acesso. Além disso, todos eles têm nomes muito longos.E então você percebe que os desenvolvedores do HAPI estão cansados ​​de digitar texto e começaram a usar estruturas de dados como LA1, ILT e PCR para a abreviação.

A API tenta ser útil: se não encontrar a esperada no campo cuja análise você está solicitando, lançará uma exceção e você precisará descobrir o que deu errado por conta própria. Obviamente, isso implica que você já sabe o que está sendo transmitido a você no fluxo de dados.

Anônimotrabalhou na área da saúde e apoiou a biblioteca envolvida no HAPI. Ele recebia tarefas regularmente (para as quais levava várias semanas para concluir) analisando simplesmente um campo adicional. Depois de gastar muito tempo mastigando volumes de documentação da API, ele escreveu um analisador comum de uma classe de 300 linhas com várias divisões, substring, parseDate e parseInt, como um substituto para toda a interface.

Depois disso, a adição de um novo campo não levou mais que dez minutos.