Levar 6 dias para mudar uma linha de código (2015)

• Quando a taxa de utilização da fábrica caiu 10%, a empresa tentou acumular estoque antes da alta temporada em vez de demitir, e para isso começou um pedido para mudar o limite de backlog de 3 meses para 4 meses
• O responsável de TI entendeu que bastava alterar um único valor hardcoded em uma rotina crítica, mas primeiro foi preciso abrir ticket, descrever o impacto no negócio, obter aprovações e ajustar a prioridade na fila
• O programador alterou o valor de MonthsOfBacklog de "3" para "4" na linha 1252 do Module ORP572 e passou nos testes, mas na revisão de código a mudança passou a incluir também correções de violações de política já existentes
• O escopo da alteração cresceu para incluir procedimentos acessórios como transformar em registro no arquivo Parameters, remover comandos de debug, alertas de variável não atribuída, Employee ID hardcoded, permissões de acesso, ambiente de teste, plano de teste e assinatura do usuário
• A mudança necessária para o trabalho era 1 linha e 1 byte, mas o tempo total decorrido foi de 6 dias, e procedimentos e políticas internas aumentaram muito o lead time real de uma alteração pequena

---

Pedido para mudar o limite de 3 meses para 4 meses

• O presidente Philip disse que a fábrica estava com 10% de ociosidade e queria produzir mais backlog para formar estoque antes da alta temporada, em vez de demitir
• O gerente de operações Lee disse que, pela política da empresa, só era permitido criar 3 meses de backlog, então mudar o limite para 4 meses geraria trabalho suficiente
• David, responsável de TI, avaliou que provavelmente bastava mudar uma única linha de código na rotina central do software legado e pediu que fosse aberto um ticket no IT Services
• A gerente de TI Judy atribuiu o pedido como Ticket# 129281, mas disse que era necessário preencher a seção Business Impact e obter aprovação do Director
  • Quando David mencionou a possibilidade de demissões, Judy mesma preencheu a seção e elevou a prioridade para processamento rápido
  • Mesmo 2 dias depois, o pedido continuava na Developer Queue como o primeiro Enhancement, atrás de 14 Bug Reports
  • David marcou a solicitação como urgente e mandou encaminhá-la diretamente para Ed

Como uma mudança de uma linha vira uma mudança de processo

• Ed alterou a variável hardcoded MonthsOfBacklog de "3" para "4" na linha 1252 do Module ORP572
  • Passou no teste unitário e executou 2 testes de batch
  • A fila de trabalho de Operations aumentou os esperados 10%
  • A mudança seguiu para Code Review e para o User Acceptance Testing de Homer
• Shirley, responsável pela revisão de código, exigiu que a variável hardcoded fosse transformada em um registro no arquivo Parameters, por violar a política da empresa
  • Ela também disse que 2 comandos de Debug já existentes, um alerta de variável não atribuída e um Employee ID hardcoded precisavam ser corrigidos antes de ir para produção
  • Como Ed recebeu a atribuição do ORP572, a posição dela era que ele também deveria responder por erros preexistentes que violavam a nova política da empresa
• O ambiente de teste também virou fator de atraso
  • Homer estava indisponível por causa de testes de controle do fechamento contábil de fim de mês, então seria preciso usar a Marge
  • Ed não tinha permissão de acesso à Marge, e Joe, da IT Security, disse que não poderia conceder o acesso sem assinatura de David
• O trabalho no registro Parameters se ampliou com exigências adicionais
  • O nome MonthsOfDemand precisaria ser melhorado porque programadores estrangeiros teriam dificuldade para entendê-lo
  • O novo registro de Parameter precisava ter trilha de auditoria, mas essa política não estava documentada e a atualização da wiki já estava 3 meses atrasada
  • Ed mudou o nome para SelectedMonthsOfBacklogDemand e adicionou o Module PAR634 para manter esse registro e a trilha de auditoria
• Tony, responsável pelos testes, apontou que o 129281 aparecia na Marge, mas não havia Test Plan
  • Ed disse que bastava executar do jeito antigo e do jeito novo e confirmar o aumento no total do relatório WorkOrdersHours, mas Tony exigiu Test Cases escolhidos pelo usuário, Expected Results, Test Runs documentados e sign-off do usuário, por afetar a fábrica inteira
  • Dois dias depois, Philip mandou David instruir Tony a colocar imediatamente em produção o programa de Ed
• O tempo total decorrido foi de 6 dias, e a mudança no mission critical code foi de 1 linha e 1 byte
  • Foram consumidos 24 Excedrin
  • O tempo gasto com irritação no Hacker News foi registrado como 14 horas

[GN⁺]

Comentários do Hacker News

• O ponto central é que o revisor exigiu: “para mudar isso, você também precisa corrigir outros problemas pendentes na base de código”
  Nesses casos, é preciso devolver algo como: “A direção de melhorar a qualidade do código é boa, mas mudar Y exige aprovações de X/Y/Z e levará mais alguns dias. Vou transformar o que você mencionou em uma tarefa de dívida técnica e tratar em um PR posterior, conforme prioridade e capacidade. Por enquanto, vamos nos concentrar no que é necessário para colocar este PR localizado em produção”
  O maior aprendizado foi criar PRs focados e aprender a rebater quando revisores tentam ampliar o escopo. Em geral, outros engenheiros aceitavam isso de forma pragmática. Não tem relação com o número de linhas. Você pode apenas reformatar o código inteiro sem nenhuma mudança lógica, ou mudar só algumas feature flags e ainda assim causar grande impacto. Deve haver apenas uma mudança focada por vez

  • Não concordo que “para mudar isso, você também precisa corrigir outros problemas pendentes” seja o ponto central. O pior aqui é que levou 6 dias para mudar uma linha de código, e quase metade desse tempo passou antes de um engenheiro sequer olhar a issue
    Se isso era uma prioridade tão alta que, se não fosse tratada imediatamente, a empresa teria que chegar ao ponto de demitir alguém, aqueles 2 a 3 dias antes de alguém olhar jamais deveriam ter acontecido. Mas, nesse processo de desenvolvimento, isso parece ser o “caminho rápido”
    Os últimos 2 dias também parecem ter passado sem nada acontecer porque o plano de testes foi considerado insuficiente. “Para mudar isso, você também precisa corrigir outros problemas pendentes” ocupou só 2 horas aqui, e mesmo antes de chegar a essa parte há pelo menos 2 ou 3 outros pontos que poderiam ser apontados como problemas centrais desse processo
  • Normalmente evito melhorias que não estejam diretamente relacionadas à tarefa em mãos. Só acrescentar um ponto e vírgula ausente já pode chamar a atenção de um revisor excessivamente zeloso e arrastar você para uma toca de coelho de correções legadas
    Em vez de deixar FIXME ou TODO, tento criar uma issue discretamente para não esquecer. Essa parte da revisão está quebrada. Resolver dívida técnica deve ser planejado separadamente, não ser uma condição para concluir a tarefa
  • Pessoas que fazem aumento de escopo não percebem o dano arquitetural que causam. Quando se apegam demais a um bloco de código, as pessoas tentam contornar aquilo pelas bordas
    Quando essas camadas se acumulam, no fim o código se torna moralmente equivalente a Atlanta, GA, famosa por ter muitos anéis viários
  • Acho que uma solução melhor é automatizar as regras
    Quando uma nova regra for adicionada, a automação deve colocar comentários de exceção da regra em todos os pontos existentes que a violam, e permitir rastreamento. Se um código que precisa ser colocado em produção com urgência tiver que violar a regra, basta adicionar um comentário de exceção e colocar o próprio nome como responsável por corrigir depois
    Com o tempo, dá para criar uma cultura de corrigir essas violações de regras separadamente do desenvolvimento de funcionalidades
  • Quando isso acontece, basta adicionar um ticket TODO. O bloqueio de produção é removido, e o sistema também não piora

• É verdade. O processo de code review da maioria das empresas está cheio de implicância e comentários triviais
  Antigamente sugeri substituir isso por ferramentas de análise estática para eliminar esse tipo de comentário e acelerar o feedback, mas ouvi que esse tipo de code review era necessário para todos. Porque ajuda as pessoas a serem promovidas, dá a sensação de que impediram problemas no código, e faz as métricas de code review parecerem boas para a alta gestão, que olha a quantidade de comentários dos revisores

  • Não gosto do uso excessivo dessas ferramentas. Não é raro ver o código ficar pior só para satisfazer uma ferramenta burra
    A solução real é aceitar que nem todo código precisa parecer ter sido escrito por mim, e se perguntar: “este comentário trata de um erro objetivo no código?”. Em muitos casos, a resposta é “não”
  • Às vezes há aqui um verdadeiro dilema do prisioneiro. Quando um sênior revisa o PR de um júnior, muitas vezes há pontos que poderiam ser melhores, mas que não são importantes
    Se for só um nome de variável um pouco verboso ou espaçamento irregular entre métodos, o ideal seria ser “feedback para considerar na próxima vez se virar um padrão”. Mas, do ponto de vista do revisor, isso pode ser visto como uma métrica de quantos comentários de orientação ele fez por PR, ou ele pode se preocupar com uma reação do tipo “quem deixou isso ser mergeado?”, então acaba deixando o comentário
    A pessoa revisada, por medo de parecer pouco responsiva ao feedback se não tratar o comentário, ou de receber uma avaliação ruim do revisor se contestar, faz a alteração. Aí a versão atualizada precisa ser aprovada de novo, e o ciclo de atraso recomeça
  • Em alguns ambientes, isso é verdade. Mas o processo de revisão também ajuda a construir conhecimento compartilhado e entendimento sobre as mudanças e a base de código
  • A implicância certamente existe de verdade. Talvez venha da sensação de que é preciso encontrar algo errado no código
    Mas também há problemas que algumas pessoas consideram apontamentos triviais, quando na realidade não são nada triviais. Isso pode acontecer porque elas não conseguem ver o problema com os próprios olhos, não entendem o problema, ou não têm capacidade de deixar as emoções de lado e repensar o código que escreveram
    Todos nós já nos apegamos ao código que escrevemos e talvez tenhamos achado que era o código mais elegante do mundo. Mas às vezes é preciso admitir que eu estava errado, que ele é difícil de ler ou defeituoso, e que prejudica a base de código
    Certa vez apontei uma condição de corrida que poderia ser um problema real no código de alguém mais sênior que eu, e fui chamado de implicante. Para mim, a condição de corrida era um problema fundamental do código escrito e precisava ser corrigida; para essa pessoa, como ela ainda não tinha visto aquilo quebrar naturalmente, era um estado aceitável
  • Ferramentas de análise estática e revisão por pares conseguem detectar tipos diferentes de problemas. É como linguagens compiladas estaticamente capturarem alguns bugs que linguagens dinâmicas não capturam, mas não todos
    Gosto muito de revisão por pares e normalmente me concentro em: “este código não vai se comportar como esperado”, “isso vai bloquear a implementação ou torná-la muito mais cara”, “funciona, mas é difícil de entender e vai prejudicar a manutenção; considere outra abordagem ou adicionar uma explicação”, “o código está ok, mas poderia ser mais legível ou funcionar melhor. Não vou reprovar a revisão por isso, mas vale considerar no próximo código”

• “Julie: entre em contato com o Joe, da equipe de segurança de TI. Ele vai te dar a permissão. Daqui a 2 horas.” é completamente irrealista. Equipe de segurança nenhuma responderia tão rápido

  • A exceção seria se você rodasse “npm install” e aparecesse um alerta de segurança P1
  • Nossa equipe de segurança na verdade responde mais rápido. Ela recusa automaticamente todas as solicitações, mas recusa na hora
  • Onde eu trabalho, a experiência é bem diferente. Quando alguém abre um ticket pedindo acesso a um sistema específico, normalmente é resolvido em poucos minutos, independentemente da prioridade
    Às vezes até acho que o pessoal do help desk pega o ticket assim que ele entra para melhorar as métricas individuais, já que é um tipo de ticket que dá para fechar rápido
  • Leva semanas para adicionar alguém ao grupo do AD necessário para permissão de edição na wiki

• Dito como no título, 6 dias para mudar uma linha de código, parece horrível
  Mas o sistema melhorou de algumas formas. A configuração passou a ser configurável em uma tabela de parâmetros, em vez de hardcoded, e também surgiu uma função de auditoria para rastrear essa alteração de configuração
  Não quero defender burocracia. Eu detesto de verdade esse aspecto de organizações grandes. Só quero apontar que, além do objetivo inicial, algum valor adicional foi criado durante esses 6 dias
  Por isso, as estimativas precisam incluir certa quantidade de custos indiretos, e, se você usa story points, também deve considerar esses custos de processo

  • O único motivo para a tabela de parâmetros ser útil é que havia coisas demais impedindo mudanças no código. Da mesma forma, a auditoria dessa configuração também parece desnecessária. Antes ela estava no código, então o controle de versão já era a trilha de auditoria
    No fim, os dois resultados foram uma “conquista” por evitar o ritual extra em torno de mudanças de código e uma “conquista” por recuperar a funcionalidade perdida pela primeira “conquista”, já que, daqui em diante, essa alteração não entraria mais no código
  • Verdade, mas também fizeram algo que podia ser muito mais arriscado do que a solicitação original. Em uma situação de interrupção imediata ou de problema real em produção, acho tolice transformar um valor hardcoded em parâmetro. Há muito mais armadilhas potenciais
    O certo teria sido dizer: “É urgente, então por favor aceitem este PR de um caractere. Criei um ticket de acompanhamento para as melhorias que vocês pediram. Vamos resolver primeiro o problema em produção e tratar o resto depois”
    O revisor só precisava dizer “LGTM!”. Se a maioria dos engenheiros não consegue navegar entre regras e diretrizes, a organização está insana, e é exatamente aí que a senioridade tem valor
  • O primeiro passo é avaliar a prioridade real. Todos deveriam saber quanto esse trabalho pode atrasar antes de afetar os empregos das pessoas
    Se levar uma semana não afeta o emprego de ninguém, então siga o processo ou mude apenas o mínimo. Se pessoas estão em licença não remunerada por causa da TI, todos os necessários deveriam estar na mesma sala, física ou virtual, até o problema ser resolvido
    Esse contexto não aparece aqui. Mas, se Ed e toda a cadeia de aprovação não conheciam esse contexto, isso é uma falha do sistema. Se soubessem que o aluguel de alguém estava em jogo, o sênior provavelmente teria sugerido criar um segundo ticket para corrigir logo em seguida. Se não fizesse isso, também seria um problema para a gestão resolver
  • “6 dias para mudar uma linha de código” apenas descreve o fato. As partes em que o sistema melhorou no meio do caminho não eram requisitos obrigatórios
  • Acho que o requisito de auditoria poderia ter sido atendido pelo histórico de versões do arquivo que continha aquele valor hardcoded. Se eles não usavam controle de versão, havia um problema maior

• Esta história é um caso em que a alteração de uma linha de um valor hardcoded na verdade deu certo
  Dá para imaginar um cenário em que alguém, tentando parecer esperto e engenhoso, armazenou o número de meses de backlog em um valor de 2 bits. Algo que só permite 0, 1, 2, 3. Durante os testes, o problema pode não aparecer por estar escondido várias camadas abaixo, em um subserviço não testado ou em um serviço de automação low-code
  Se você mudar esse valor para 4, o backlog pode virar 0. Não dá para saber o que vai acontecer. Esse serviço pode cancelar todos os trabalhos na fila de produção ou enviar e-mails aos clientes dizendo que seus trabalhos foram cancelados
  Por fora parece uma mudança fácil, mas, se uma mudança de política chegou à equipe de software como um problema urgente, a gestão deveria planejar melhor, não sair mexendo arbitrariamente na prioridade das issues

  • Nada na mudança solicitada tinha a ver com testes adicionais ou redução de risco
    Pelo contrário, aumentaram o risco ao exigir a refatoração de várias partes ao redor como “custo” da mudança
  • Há todo tipo de forma de dar errado. A pergunta real talvez seja para onde vai a responsabilidade quando der errado
    Se o chefão disser “eu decidi assumir o risco e seguir em frente, e aceito as consequências”, ótimo. Se quem apanhar forem os programadores, não é bom
  • Acho que seguiram as pessoas e os processos corretos. Mas poderiam ter economizado muito tempo se reunissem os leads e alinhassem a importância e a prioridade do trabalho
    Se era uma atualização importante e sensível ao tempo em uma funcionalidade essencial, o responsável por operações deveria conhecer o tempo médio de deploy do software e deveria ter montado uma equipe para tratá-la rapidamente, em vez de colocá-la com alta prioridade no pipeline normal de desenvolvimento
  • Me lembrou a Knight Capital

• Code review começa com boas intenções. Mas algum gatekeeper acaba se estabelecendo e começa a rejeitar tudo por motivos triviais
  Ele diz que está interessado em proteger a “qualidade do código”. Mas não há nada pior do que deixar por muito tempo um código com bug que já tem correção pronta, ou atrasar uma funcionalidade para que ninguém possa sequer testá-la
  Recomendo um processo em que comentários sejam permitidos, mas o revisor não possa bloquear o commit. É preciso confiar que cada desenvolvedor terá cuidado e fará mudanças adequadas ao trabalho. Também dá para usar CI e, dependendo da equipe, isso pode funcionar muito bem

  • Então o líder de engenharia precisa parar essa pessoa. Disfunções aparecem de várias formas, e revisões excessivamente zelosas são uma delas
    Mudar o processo para permitir ignorar um revisor patológico é, na melhor das hipóteses, uma meia-medida
    Tenho sentimentos mistos sobre bloqueios. Entendo que aquele grande sinal vermelho de bloqueio é frustrante, então em muitos casos faço um “bloqueio suave”, pedindo mudanças sem bloquear. Mas, quando um PR saiu completamente dos trilhos, geralmente no caso de um desenvolvedor júnior, acho adequado enviar uma mensagem clara
  • Essa abordagem funciona bem quando a cobertura de testes e a qualidade dos testes são altas. E isso também não surge magicamente só por deixar os desenvolvedores se moverem na velocidade que o gerente acha necessária naquele momento
  • Detesto a regra de que “toda mudança de código precisa de um revisor”. É uma interferência enorme e não leva necessariamente a um código melhor

• Esta é uma discussão meta sobre trabalhadores de fábrica e desenvolvedores de software
  O líder dessa empresa está disposto a demitir trabalhadores de fábrica por causa de 10% de subutilização. Dá para ajustar algumas variáveis e aumentar a produtividade, mas, no fim, as opções são utilização total ou desemprego. Provavelmente isso é possível porque esses trabalhadores são substituíveis, podem ser recontratados na alta temporada e o lucro gerado por funcionário não permite ineficiências
  Eu trabalho como desenvolvedor de software. No nosso lado, só se pensa em dispensar alguém quando a subutilização passa muito de 90%. Muita gente trabalha só 4 horas por semana. Ninguém gerencia nosso tempo minuto a minuto nem nossas pausas para ir ao banheiro
  Agora estamos em um período de capitalização em larga escala do software. Isso não vai durar para sempre. Um dia, a infraestrutura principal do mundo de TI estará construída e o setor passará para o modo de manutenção. A maioria de nós deixará de ser necessária, passará a ser substituível, e o lucro que geraremos no modo de manutenção será minúsculo em comparação com o que vemos hoje
  Quando se percebe que a produtividade individual de um operário de fábrica está baixa, ele normalmente é demitido em alguns minutos ou horas. Acho que isso também começará a acontecer com desenvolvedores de software ainda durante nossas vidas

  • “Esses trabalhadores são substituíveis e podem ser recontratados na alta temporada” é justamente a diferença. Uma fábrica é um sistema de processos projetado para remover de cada pessoa a tomada de decisão e a variabilidade
    É preciso avaliar em que medida isso também é possível para o seu próprio conjunto de habilidades
    Concordo com o ponto básico de que a capitalização em larga escala do software não é eterna. Nem toda empresa sempre precisará de engenheiros para desenvolver software novo. É mais parecido com um negócio criativo, com ciclos de alta e baixa, como a produção de filmes. Se você escolher desenvolvimento em vez de TI, precisa aceitar esse risco. Só não sei por que o pico teria que ser agora

• Pela minha experiência pessoal, depois de trabalhar por alguns anos em uma equipe com code review formal, mudei para uma equipe/empresa sem code review. Qualquer um podia commitar e fazer merge livremente em qualquer branch
  Quando entrei, tive sentimentos um tanto contraditórios, mas na prática foi muito revigorante e me senti empoderado, e em poucos dias já estava produtivo

  • Já trabalhei em uma equipe que fazia “code review católico”, ou seja, push and pray
    Considerando os objetivos da equipe, a abordagem sem code review se encaixava muito bem. Era um grupo de pesquisa e desenvolvimento cujo principal objetivo era demonstrar “novos recursos legais” para executivos. Havia muitas solicitações com pouco aviso, mas também muito código descartável
    Depois da demonstração, o executivo dizia “parece bom, mas não tem viabilidade de negócio”, e o repositório nunca mais era tocado. Claro que, às vezes, algo que fazíamos virava produto; nesse caso, uma subequipe ficava responsável por transformar aquele código rabiscado em qualidade de produção. Essas pessoas nos odiavam com um ódio ardente
  • Vi essa abordagem funcionar muito bem em uma equipe pequena, com alta confiança e cerca de 80% de cobertura de testes. Era um processo sem PR: se os testes passassem, a demonstração de UX para as partes interessadas, quando aplicável, tivesse sido bem-sucedida, e a própria pessoa estivesse satisfeita, fazia merge em master
    Um novo integrante recebia um mentor que sentava ao lado dele durante os primeiros 2 a 3 meses, fazia pair programming com frequência e revisava o código
    Foi um projeto de 2,5 anos, entrou no ar no 20º mês, cumpriu prazo e orçamento e entregou mais funcionalidades do que o escopo original. Em muitos dias, passávamos 2 a 3 horas discutindo diante do quadro branco. Era informal e nem sempre todos participavam
    Curiosamente, durante esse projeto, o PM mudou três vezes. Tínhamos uma regra rígida de não usar e-mail nem contato fora do stand-up, e dois dos três conseguiram “trabalhar” nesse arranjo. O diretor de TI do aeroporto só percebeu depois de 2 anos que não precisávamos de um PM
    Havia uma regra de que, se você fosse fazer algo novo na base de código, precisava conversar com pelo menos outro desenvolvedor. Sentávamos a poucos metros uns dos outros, em escritórios individuais amplos com grandes quadros brancos. As histórias eram gerenciadas com cartões de índice presos em um quadro branco dedicado; se não conseguíssemos explicar o essencial ali, era preciso dividir em partes menores
    Cada um podia montar sua própria máquina e usar quantos monitores quisesse. Era o sistema de faturamento e tarifas de um grande aeroporto internacional, e o chefe da contabilidade, o diretor e outros usuários ficavam a poucas portas de distância. Eles quase nunca faltavam aos stand-ups e tinham uma política de responder a perguntas em tempo real a qualquer momento
    O stand-up normalmente não era um relatório de status, mas uma conversa informal, demonstrações e perguntas e respostas. Para atualizações de status, bastava olhar os cartões no quadro branco
    O sistema final melhorou a receita em 8% desde o primeiro mês e em todos os meses seguintes. A diretora de contabilidade teve que explicar isso diante do conselho da autoridade aeroportuária. Disputas e ajustes de faturamento com companhias aéreas caíram de 9 dias por mês para 1 dia, e a carga mensal de trabalho de faturamento caiu de 18 dias para 5 dias. Foi possível transferir a usuária principal de uma contadora sênior para uma única contadora júnior com 3 anos de experiência
    Houve 6 bugs em produção no primeiro ano e 0 faturas incorretas. Não tenho dados posteriores. A tentativa anterior de reescrita havia fracassado depois de 3 anos
  • Sinceramente, do ponto de vista de segurança e auditoria, isso parece um pesadelo. Ainda assim, consigo imaginar isso funcionando em uma agência ou algo parecido que faça projetos pequenos

• Usar o processo de code review para manter mudanças como reféns até que elas se encaixem em ideais de equipe elevados e em constante mudança é uma disfunção
  Uma política de “atualizar pelo caminho” deixa uma longa cauda de transições pela metade, tornando mais difícil para novos desenvolvedores se adaptarem à base de código. Como não há garantia de que o foco do produto passe regularmente por todas as partes da base de código, a transição nunca termina. Algumas áreas do produto ficam abandonadas por anos
  Se migrar para a nova política é importante, isso deve ser separado e tratado como um projeto concentrado; se não for, então não é importante

  • Exato. É terrível porque a gestão está basicamente abandonando o plano
    Eles estão esperando que bombas-relógio de trabalho não planejado espalhadas pela base de código explodam por meio de tarefas aleatórias e não relacionadas
    Se o novo padrão é importante, o código deve ser atualizado; se não é, não deve. Atrasar trabalho urgente apostando na aleatoriedade não é um plano

• Ler isso como um problema de code review é equivocado. O problema é que a empresa colocou um processo formado por barreiras internas acima dos princípios
  Todo processo precisa de uma saída de emergência. Se uma mudança impede uma demissão, todas as saídas de emergência deveriam ser acionadas