** Este é um problema de gestão**.

Antes de ser implantado, o código crítico deve ser controlado em versão, o código revisto e, pelo menos, a sua utilização deve ser documentada. Se estiver em causa a segurança, escolha os correctos revisores e proteja o reporte e os documentos. Não há razão para que isto não possa ser iniciado imediatamente.

** Existe um problema maior do que a segurança no trabalho**.

Qualquer um destes programadores poderia colocar código malicioso na empresa, por engano ou pelas suas próprias razões. Na pior das hipóteses, poderiam cometer actos nefastos utilizando a sua situação criada por si próprios (extorsão, sabotagem, espionagem industrial, etc.). Na melhor das hipóteses, a sua opacidade expõe todos a preocupações de segurança e deixa sempre um ponto de interrogação sobre qualquer auditoria ou responsabilização. Se algo correr mal, quem poderá dizer que não estiveram de alguma forma envolvidos?

É necessário elaborar um relatório para a direcção.

Escreva um pequeno documento que descreva exactamente a razão pela qual a actual abordagem está a conduzir a empresa por um caminho perigoso (ser atropelada por um cenário de autocarro, por exemplo). Descreva os riscos de segurança, talvez até cite histórias de cautela da sua indústria, com referências a artigos, etc.

Também inclua uma lista de formas em que a abordagem deste tipo está a prejudicar o seu próprio trabalho, bem como o trabalho dos seus colegas de trabalho.

Por último, mas não menos importante, certifique-se de listar as recomendações a serem implementadas imediatamente, tais como adicionar o código ao controlo de versões para todos verem, e executar o servidor num VM ao qual todos têm acesso. Esboce como estas medidas não devem de forma alguma ter impacto no trabalho desta pessoa, e simplesmente acrescentarão segurança e transparência a todo o processo - _ deixe claro que não há objecções razoáveis a estas medidas._

Talvez se sente com o seu chefe quando lhe entregar este relatório, e transmita verbalmente os receios exactos que aqui escreveu: que este tipo está a construir um império na infra-estrutura da empresa, e que, em última análise, ele é potencialmente perigoso . Se os seus chefes acham que esta pessoa pode tornar-se irracional, então talvez queira seguir o conselho de @BillLeeper e tomar o controlo da sua máquina para que ele não seja capaz de prejudicar a sua organização. Isto será, claro, para eles decidirem.

Infelizmente, ainda não disse se alguém falou sobre estas preocupações com o colega de trabalho ou com a direcção. É realmente malicioso? Ou será que o seu colega é apenas cego? Ou talvez a gerência seja cega?

Eu próprio já fui “aquele”.

No meu trabalho anterior, por vezes tinha várias tarefas secundárias para “fazer esta pequena ferramenta” ou para tornar algo simples. Acontece que nunca há recursos para software interno… Normalmente era algo do género:

– Alguém pode olhar para as soluções que escolhi para dizer se é apropriado? – Vá lá, só precisamos de uma ferramenta simples que simplesmente faça esta simples operação, faça-o e tudo correrá bem.

– Posso criar um servidor virtual no nosso servidor para esta coisa? – Meu, é só para uso interno. Basta montá-lo junto com outras coisas naquela caixa física partida. Ou coloque-o nessa caixa que faz com que não saibamos o que funciona. Ou coloque-o na sua própria estação de trabalho.

É claro, nunca houve tempo para escrever documentos. A não ser que eu tenha optado por fazê-lo no meu tempo livre. Claro, tudo o que eu podia dizer quando algumas ferramentas tinham problemas era “trabalhar nele”.

E depois decidi desistir. Foi o primeiro momento em que alguém à minha volta percebeu que as “pequenas ferramentas internas” eram realmente importantes e que as coisas “simples” não são assim tão simples. Passei alguns fins-de-semana a escrever documentos para lixar menos os meus colegas. Já passou quase um ano e ainda recebo vários telefonemas todos os meses sobre como fazer algo com as minhas ferramentas internas.

Editar

Alguns comentários apontaram que eu não os devia ajudar de graça. Isto é geralmente correcto. Gostaria de esclarecer que não estou a dedicar horas do meu tempo a resolver os seus problemas, estou apenas a gastar um minuto para responder a uma pergunta. Tecnicamente ainda é verdade que estou assim a permitir e a encorajar as práticas existentes. A propósito, a empresa ofereceu-me uma posição em part-time ou de pagamento à hora para resolver problemas como fiz antes e recusei-a.

A questão é que não estou disposto a forçar os meus ex-companheiros a “pesquisar melhor” em vez de me perguntarem simplesmente “Em que máquina está o Veeam a funcionar?” se posso simplesmente dizer o nome ou o endereço IP sem pensar ou dizer “Deve ser escrito em […]”. Para além de uma chamada telefónica de 2 minutos com um ex-collega é normalmente uma distracção tão positiva e relaxante como uma troca de stackex.

Edit end

Então o que posso sugerir? O seu colega parece bastante capaz, não parece? Discuta isto com a gerência. Não diga “ele está a tornar-se insubstituível”. Pergunte-lhes apenas - e se ele se for embora? E se ele ficar doente durante um longo período de tempo? Convença-os de que o problema é real. Eles próprios devem discuti-lo com aquele tipo para encontrarem soluções. Talvez lhe faltem apenas recursos? Talvez ele precise de outra pessoa na equipa de “software interno” para tornar tudo agradável e bonito?

A maior parte destas respostas é WAY OVERBOARD em assumindo intenções maliciosas por parte do programador em questão.

Antes de fazer uma imagem sub-reptícia do servidor e depois de o perp-para fora do escritório, porque não respirar fundo e tentar compreender o que se passa?

Pode muito bem ser que a pessoa em questão esteja sobrecarregada de trabalho, não tenha recursos suficientes e esteja mais do que disposta a partilhar conhecimentos. Ou talvez o tenha feito desta forma durante muito tempo e nunca tenha recebido uma indicação de que precisa de fazer o contrário. No mínimo, especialmente se as suas coisas funcionam, ele merece uma oportunidade para resolver preocupações e colaborar com os colegas de trabalho.

Não vejo qualquer prova de que nada disto tenha sido tentado na pergunta do PO. Antes de considerar opções draconianas, tente primeiro a comunicação. Se a pessoa não tinha a intenção de fazer mal, pode esperar cooperação da sua parte.

Há algo que ainda não vi nas outras respostas:

Começa casualmente a procurar um novo emprego

Começa casualmente a procurar um novo emprego

Claro que isto se baseia no pressuposto de que já falou com o seu gestor sobre isto. Outras respostas forneceram as razões pelas quais este não é o seu problema mas sim o do seu manager e também deram indicações sobre como abordar esta conversa com o seu manager.

Agora, estou a olhar para a situação em que já falou sobre isto com o seu manager e depois de ter passado um período de tempo razoável, nada aconteceu sobre isto. Tem a sensação de que o seu manager não considera isto um problema tão grande como sabe.

É aí que talvez queira começar a procurar um novo emprego. Não importa se o seu gerente simplesmente não acha que isto é um problema ou que ele simplesmente não o compreende suficientemente bem para ver o problema, há aqui algo de errado. (E não estou a falar do código “privado”, mas do problema de o gestor não fazer algo a esse respeito)

Esse problema é algo que não é provável que consiga mudar da posição de um programador. No entanto, existem outras empresas e não têm os mesmos problemas, pelo que poderá querer procurar um empregador diferente.

Olhando para isto pelo lado positivo, no entanto, não há demasiada pressão sobre si neste momento. Você tem um emprego e não espera perder esse emprego. Não terá de se comprometer para poder continuar a pagar os custos de renda/mortalagem/vida. Pode simplesmente começar a procurar casualmente e não deixar o seu emprego actual até encontrar o emprego que realmente gosta.

Parece haver aqui alguns bons remédios para evitar isto no futuro, mas não o que fazer agora.

1. Proteja o computador. Ou a gerência e um perito em TI vão lá quando está desbloqueado e sem vigilância, ou vão e exigem que ele desbloqueie a máquina e conceda o acesso. Depois tire este monstro da rede. Faça uma imagem imediata do HD no caso de ele ter um interruptor de homem morto.

2. Dispare este indivíduo imediatamente. Leve-o para fora da porta. Não se preocupe com a causa, haverá muitas provas do seu computador. Se a empresa estiver preocupada, peça ao seu advogado que faça a sua magia, é para isso que são pagos.

3. Reúna a equipa. Explique o que se passou. Este indivíduo estava a agir de uma forma imprudente e pouco profissional. Ele pôs a empresa em risco e foi demitido por isso. Vai ser preciso todos os recursos que temos para resolver esta confusão.

4. Use a equipa para reconstruir e reimplantar este trabalho de uma forma adequada em máquinas seguras, etc. A equipa vai ter de passar por aplicação por aplicação e tratar de tudo. Não se preocupe imediatamente com a reescrita, apenas certifique-se de que não há portas traseiras, etc., e depois ponha os serviços em hardware fresco e controlado.

5. Arranje um especialista em segurança. Este tipo provavelmente não vai entrar em silêncio e vai tentar ‘hackear’ de volta para sabotar ou ter acesso ao seu sistema. Ele também pode ter senhas globais para sistemas com os quais interagiu ou obteve senhas individuais ao longo do tempo. As TI devem desencadear uma redefinição forçada da palavra-passe em todos os utilizadores e bloquear qualquer acesso externo durante algum tempo (como a VPN).

Todas as respostas actuais e a maioria dos comentários actuais apenas referem a situação actual ou fornecem sugestões para tomar medidas extremas.

Apenas para resumir: Há duas situações possíveis: Os colegas de trabalho estão a fazer isto intencionalmente, neste caso são maliciosos de uma forma ou de outra, e depois é necessária uma extrema cautela. Ou os colegas de trabalho simplesmente não vêem os potenciais e reais problemas e perigos, eles estão a causar, então eles são “amigáveis”, mas deve ser pensado para fazer melhor.

Então, o seguinte roteiro tenta duas coisas ao mesmo tempo: 1) tentar minimizar os danos potenciais, esses colegas de trabalho podem fazer, se forem maliciosos, e 2) tentar mantê-los na empresa (para que possam desenvolver-se como colegas de trabalho cooperativos no futuro) se forem amigáveis:

(btw: Eu sei, você não é o chefe, mas com a informação, outros forneceram, acho que terá tudo nas suas mãos para convencer o seu chefe, para levar este tópico muito a sério, por isso este roteiro aborda o que o seu chefe poderia fazer, não o que você faria. A única coisa que pode fazer é chamar a atenção para o seu patrão. btw2: Se o seu patrão ainda não lhe der ouvidos, procure um novo emprego e desista assim que encontrar um novo. Porque esses colegas de trabalho são bombas-relógio, independentemente de serem amigáveis ou maliciosos - isso não importa nada).

1.) Faça silenciosamente cópias de segurança de tudo o que pode aceder. Não desligue os sistemas no processo, desligando os sistemas pode potencialmente activar alguns tipos de armadilhas.

2.) Construa uma razão, que os postos de trabalho precisam de ser desligados. Se precisar de uma ideia, contacte-me em privado.

3.) Extrair os discos rígidos, fazer uma imagem completa, voltar a colocá-los. Faça isto durante cerca de um fim-de-semana

4.) Se os sistemas têm material de detecção de intrusão de nível BIOS, e não consegue contorná-los, construa outra razão, porque é que esses sistemas de detecção de intrusão dispararam.

Esses colegas de trabalho estão a criar ferramentas para material interno, certo? Então eles não precisam de acesso aos sistemas dos clientes e afins?

5.) Se tiverem acesso aos sistemas, não precisam, mudar as palavras-passe, certificar-se de que não existe qualquer tipo de login de chave pública, verificar portas para processos que permitam o login não standard. Verificar cron/at jobs, verificar inetd, verificar tudo o que está a correr actualmente. Para cada pid, tem de ser capaz de responder, porque é que esse processo corre de todo.

6). Arranje um novo funcionário (realmente novo, completamente desconhecido. Ele deve ser um bom especialista, porque deve ser capaz de assumir o seu trabalho sozinho durante algum mês, se for necessário. Não se pode simplesmente pegar num aluno formado ao acaso (nem sequer um com a nota mais alta), precisa de alguns desses tipos, que nunca visitaram uma universidade mas ainda assim sabem tudo) e inseri-lo nessa equipa para os apoiar. Especialmente porque estão a causar bloqueios nos outros trabalhadores, isso pode ser facilmente justificado. A sua função oficial é apoiá-los, a sua verdadeira função é aprender, como eles funcionam.

O passo 6 é especialmente importante, porque desta forma, tem uma oportunidade, de realmente descobrir, se esses colegas de trabalho são mal-intencionados de todo.

Se o novo tipo está a ser bem integrado na equipa, então pode assumir que eles são amigáveis, que o novo tipo deve ser capaz de implementar as mudanças necessárias sem qualquer necessidade de dizer a esses tipos, que houve qualquer suspeita contra eles.

Se o novo tipo descobre, eles são maliciosos, mas eles integram-no, então o seu trabalho é alinhar. Aprender tudo, achar fixe o que eles estão a fazer, e assim por diante. Paga-lhe o dobro do dinheiro, porque ele tem de trabalhar duas vezes, porque quando chega a casa, tem de escrever tudo o que aprendeu e enviá-lo para uma equipa recém-formada que deve assumir o trabalho assim que o conhecimento suficiente for transferido.

Se os maliciosos não o integrarem, então a sua única hipótese é ter esperança, tem dados suficientes (só para o caso) e despedir essa equipa. Então pode precisar de dois ou mais super especialistas que eu estava a falar acima, para conseguir que uma nova equipa entre nesse código muito rapidamente.

Espero que este roteiro ajude - pelo menos como fonte de inspiração sobre como lidar com isto. Talvez, na vossa empresa, tenham algumas opções, que eu não possa considerar, talvez, existam algumas diferenças culturais, por isso ainda têm de pensar nisto e talvez ajustar o plano.

O programador em questão não deve receber qualquer trabalho novo até que a situação seja resolvida de uma forma ou de outra. Todos os novos requisitos devem ir para outro programador/equipa que deve seguir procedimentos adequados de controlo da fonte e de revisão pelos pares (se necessário, novas contratações). O programador em questão pode ser mantido ocupado a corrigir defeitos ou a “combater o fogo” do seu legado existente. Devem ser atribuídos recursos para a engenharia reversa do legado existente e para a sua reimplantação através de processos adequados. O custo de o fazer tem de ser justificado pelo risco existente - quanto custará à empresa se tudo o que este programador fez se perder subitamente? Ou pior, que dados proprietários (da empresa) são vulneráveis à perda para a concorrência?

Pode valer a pena perguntar a este empregado: “o que nos acontece se for atropelado por um autocarro ou se decidir fazer um cruzeiro de um mês à volta do mundo?” e avalie a resposta para decidir se ele vai entregar o seu código de livre vontade. Se cooperativo, não há necessidade de a situação se tornar contraditória; se não há sinais de preocupação da empresa da sua parte, tempo para se ocupar em assegurar tudo o que tocou.

Como abordar a gestão sobre isto?

Diga que a melhor prática é não permitir isto, por muitas razões.

Os programadores profissionais devem saber que isto não é maneira de gerir um negócio; e se os gestores não sabem mais nada, devem pelo menos saber isso (os programadores devem dizer aos gestores e/ou os gestores devem dizer aos programadores).

As razões são tão conhecidas que espero não precisar de vos dizer. Elas incluem “backup”, ou seja, você está em apuros se perder o programador (ou se ele for transferido para outra coisa), ou se o programador perder a sua máquina.

Pelo menos você tem “controlo da versão da empresa” para que não precise de travar essa batalha; basta fazer com que seja um requisito de trabalho/processo que seja realmente utilizado.

Provavelmente não deve executar software de produção na máquina do programador. Um primeiro passo pode ser insistir que:

• Os utilizadores não fazem ligações de rede à máquina do programador
• O software corre em/de um servidor de produção

• O software corre no servidor de produção deve poder ser compilado por outra pessoa (ou por uma máquina de compilação), a partir do controlo da fonte

• Implementação que requer que o código fonte seja verificado, as instruções de compilação publicadas. Sugiro que o faça como uma semi-emergência. Permita que o programador não aceda por escrito ao servidor de produção ou à máquina de compilação (para verificar se o código de produção é compilável a partir do controlo de versões).

Depois de o ter feito (depois de saber que o código fonte está no controlo de versões e que as instruções de compilação estão publicadas), os outros programadores podem pensar em inspeccionar o código fonte e ajudar a mantê-lo.

Note que * Get Rid Of Indispensable Programmer As Quickly As Possible *** foi publicado por Gerald Weinberg em 1971 (então, realmente, todos já deveriam saber disso). IIRC a citação original é,

“Se um programador é indispensável, livre-se dele o mais depressa possível”.

Este não é o seu problema, é a responsabilidade e o papel dos gestores, você é apenas um colega de trabalho e possivelmente não tem toda a informação necessária. Eu preocupar-me-ia mais com as minhas próprias tarefas do que com os meus colegas de trabalho. Não consigo ver como é que algo de positivo resultaria de fazer alarido sobre o seu colega de trabalho.

Vai fazer dele um inimigo, vai aparecer o seu gerente por ser incompetente e dar a impressão de que tem tão pouco trabalho que tem tempo para iniciar investigações internas sem que lhe seja pedido ou sem que tenha autoridade para tal.

A questão é: até que ponto quer sair deste ciclo vicioso? Porque não sejamos engraçados com isto, vai custar à empresa.

1. A empresa vai ter de gastar dinheiro para contratar alguém para escrever o código que a empresa controla.
2. A empresa tem de exigir o código ao programador e, se necessário, apoiar essa exigência com ajuda jurídica. Recordo que o código foi encomendado pela empresa, que o codificador sacou um cheque de pagamento da empresa enquanto escrevia o código, pelo que o código é da empresa. Uma falha por parte do codificador na produção do código seria, na pior das hipóteses, considerada um roubo, o que constituiria um crime.

A liberdade não é livre. Se a empresa não está disposta a gastar recursos para se libertar deste indivíduo, então tudo o que está a fazer é bater as suas gengivas. Vão todos ter de enfrentar a situação, porque se o codificador se afastar ou for atropelado por um camião, a empresa é a SOL.

Considerem a razão por que o estão a fazer. É perfeitamente possível que estejam a ser cortados cantos para corresponder às limitações de tempo, aos objectivos de desempenho e ao aumento consistente das exigências. Isto leva frequentemente a uma dívida técnica e a um codificador muito stressado que não tem outra escolha senão resolver todos os problemas fora do sítio.

Esta pessoa pode muito bem estar a escrever coisas de uma forma que só ela pode resolver porque não tem tempo para documentar, versionar e manter o código de forma atempada. Confie em mim quando digo que isto tem um efeito completamente negativo em qualquer pessoa que se encontre nesta posição. Não é um papel confortável onde alguém pode sentar-se e relaxar.

Se, como o seu título sugere, não estão a resolver problemas, não haveria problema nenhum. Deitaria fora o codificador, com todo o seu código, porque é inútil.

Prevenir situações como esta é uma tarefa de gestão extremamente básica. Daí resulta que a direcção que está consciente do problema não é competente, e a direcção que é competente não está consciente.

Infelizmente, desenredar situações como esta é uma tarefa de gestão difícil. Assim, uma vez que os gestores responsáveis por este empreendedor nem sequer foram capazes de prevenir a situação, não contem com a possibilidade de resolver a situação.

*A única forma de resolver esta situação é subir para um nível superior de gestão. * Se eles estiverem interessados e forem capazes de corrigir isto, não tem sequer de nos explicar mais nada do que nos explicou - basta torná-lo menos pessoal, concentrando-se nos programas, e nas questões com eles, em vez do programador.

Deve saber que esta é uma opção de alto risco - baixa recompensa. Se o fizer, mesmo que funcione, o programador e o seu manager (que provavelmente também é o seu manager) irão sofrer, e saiba que é o responsável. O único benefício de fazer isto é que você está (possivelmente) seguindo seu próprio código de ética e honra, mas você pode perder seu emprego por causa disso. É por isso que algumas das outras respostas recomendam que o deixe ir ou que procure apenas um emprego melhor, o que é a coisa inteligente a fazer.

\ * A outra forma de corrigir isto é tornar-se você mesmo gestor, e corrigir isto, mas há bastantes armadilhas envolvidas.

Após a sua própria avaliação, decidiu que não tem hipótese de ser promovido, e a única razão pela qual a empresa teria de mantê-lo é que ele lhes está a reter o código.

Não sei se concorda com isto, mas se concordar, o código poderia provavelmente ser feito por alguém melhor. Ou se não explicar por que razão este comportamento garante que ele nunca poderá ser promovido.

Penso que se trata de saber se esta situação vale tanto a pena corrigir como de como corrigi-la.

Trata-se de uma tarefa de gestão. A primeira gestão deve tentar descobrir se isto é intencional. Se assim for, deve ser feito um plano para despedir as pessoas infractoras. Se não for intencional, deve ser feito um plano para treinar as pessoas infractoras.

Eles concebem os seus programas … para que sejam gradualmente mais difíceis de substituir.

Não se eu fosse o chefe!

Há aqui dois problemas:

1. Mau programador.

2. Gestão incompetente.

Isto é, claro, assumindo que está a representar a situação correctamente.

Não consegue resolver o problema #1. Há uma ligeira hipótese de conseguir resolver o problema nº 2. Esta pequena hipótese é se o chefe, por algumas razões, simplesmente não estiver ciente do que se está a passar. Vá ter com o patrão e diga-lhe quais os problemas que vê e porque é que são maus para a empresa. Isso provavelmente irá falhar porque o chefe já sabe do problema e não é competente para o resolver, ou sabe tão pouco sobre software e engenheiros de software que nem sequer é competente para o entender.

A única solução real é começar por resolver o problema #2, no qual pode, na melhor das hipóteses, desempenhar um papel menor. O gerente incompetente precisa de ser substituído.

O novo gerente tem então uma reunião com este programador, pede-lhe que explique a arquitectura e diz-lhe para parar qualquer novo desenvolvimento e documentar todos os protocolos. Entretanto, ele recebe um novo engenheiro que está lá para “ajudar” o primeiro engenheiro a documentar os protocolos, a colocar o software no controlo da fonte e a certificar-se que o código em si está bem documentado. Este novo engenheiro faz qualquer novo desenvolvimento, e esperamos que conserte erros e pequenos melhoramentos do software existente.

O primeiro engenheiro não vai gostar disto. Ele pode desistir, fazer uma birra, fazer barulho, ou pior, sabotar coisas. É por isso que fazer uma cópia de segurança é a primeira ordem de trabalhos. Seria bom ter uma transição suave do primeiro para o segundo engenheiro, mas não espere que isso aconteça. O plano é acabar por despedir o primeiro engenheiro, se ele não desistir ou não se tornar (ainda mais) destrutivo contra a empresa primeiro.

Não se pode simplesmente deixar este disparate continuar. Quanto mais tempo o fizer, mais doloroso será consertá-lo. Não consertá-lo porque já vai ser doloroso é absolutamente errado pensar nisto.

Neste caso estava a usar a retórica “tu”. Para responder à pergunta sobre o que pode fazer pessoalmente, comece por levar as suas preocupações ao chefe, como já disse anteriormente. Mais uma vez, é pouco provável que isso resulte em algo útil.

O próximo passo depende de coisas que ainda não nos tenha dito. Pode ser muito perigoso passar por cima da cabeça do seu chefe. Se assim for, então pouco mais pode fazer para além de avaliar se quer realmente continuar a trabalhar lá. Se esta é uma empresa suficientemente pequena para poder falar confortavelmente com a administração superior, então vá em frente. É bem possível que a direcção superior já tenha a sensação de que o gestor de software de baixo nível é incompetente, mas é claro que não lhe vão dizer isso. Esta pode ser a informação adicional para eles tomarem medidas mais decisivas.

Outra possibilidade distante, se o seu objectivo principal é resolver esta confusão e se vê a longo prazo neste local, é oferecer-se para assumir você mesmo parte do desenvolvimento interno da ferramenta. Isso deve dar-lhe razões legítimas para falar com o primeiro engenheiro, compreender como as coisas funcionam, onde vive o código, etc. Eventualmente, você seria o tipo de ferramentas e a gerência pode se livrar do primeiro engenheiro. Depois pode pedir-lhes que contratem alguém para essa função, para que possa fazer a transição de volta para o que pretende fazer. Mais uma vez, isto não é algo que eu esteja a sugerir seriamente, mas é uma alternativa se você realmente quiser e estiver disposto a isso.