Correção de erros off-shore

Se um possível empregador disser que "terceirizou a correção de bugs porque os desenvolvedores odeiam corrigir bugs", o que você acha? Quais podem ser suas preocupações?

Corrigir nossos próprios erros realmente nos torna um desenvolvedor melhor . E é um momento muito agradável para mim. Especialmente quando eles são bem relatados.

Se eles não gostam de corrigir bugs, o problema está em outro lugar.

Eu suspeito que o problema é como os bugs são percebidos pela gerência ou, pior, pelas decisões ruins de design e / ou pelo teste (de unidade), causando uma correção dolorosa.

A terceirização de correção de bugs provavelmente piorará as coisas.

Os desenvolvedores podem ficar tentados a reduzir a qualidade. Quem se importa? Alguns caras do exterior estão lá para limpar sua bagunça.

Até os caras offshore substituirem os caras onshore.

Saia , fuja ... rápido e nunca olhe para trás ...

Eu trabalhei para uma empresa assim, eles pensaram que eram inteligentes,

• ei, temos todos esses bugs, mas nossos idosos reclamam que gastam muito tempo corrigindo bugs.

• vamos abrir um escritório offshore e deixar os outros lidarem com isso.

para um gerente que parece realmente um bom plano e os desenvolvedores foram finalmente libertados para enfrentar a tarefa mais interessante de criar a próxima melhor coisa !!

ho ... mas espere ...

depois de dois anos, eles passaram de uma equipe de 5 desenvolvedores em seu escritório principal que lidou com tudo isso para uma equipe de 2 que cria coisas novas e uma equipe de 30 pessoas que encontra e corrige bugs.

você sabe o que ... a equipe de correção de bugs está lutando, eles não conseguem acompanhar.

isso tornou os "idosos" completamente irresponsáveis ​​por seus próprios erros. Pior ainda, porque tudo aconteceu tão longe, a gerência também não percebeu e a qualidade do código despencou MUITO rapidamente, a partir de um nível de qualidade já abismal.

Quando saí, eles já abriram mais dois escritórios para solucionadores de problemas e ainda não conseguem acompanhar o agora único desenvolvedor que os cria. eles realmente acham que é porque os novos caras não são inteligentes o suficiente ...

então sim, a partir de agora, se uma empresa disser que terceirizou a correção de bugs para um escritório no exterior, confie em mim ... eu corro ... rápido.

Essa é a metodologia de gerenciamento do Paper Bag .

Fique em uma estrada de ferro, espere o trem chegar, quando o vir, coloque um saco de papel sobre a cabeça e ... POOF .. o trem partiu !!. Magia !

Ter a empresa pagando a alguém para limpar minha bagunça parece uma boa idéia, exceto quando devo pegar o código 'limpo' e adicionar novos recursos. E se eles ficarem tão estragados que não podem consertá-lo, você estará depurando a depuração.

Não é recompensado adequadamente porque eles precisam contratar desenvolvedores adicionais não é desejável.

Ter que gastar uma quantidade desproporcional de tempo educando os outros desenvolvedores quando você mesmo poderia consertá-lo é contraproducente.

Parte de mim sente que quem cria problemas deve ser quem os corrige ou não há incentivo para evitar a criação de bugs.

Os desenvolvedores não estão interessados ​​em aprender com seus erros? Você pode corrigir erros sem conhecimento específico do domínio e o parceiro de terceirização possui esse conhecimento? A parte de fixação é a mais fácil na maioria das vezes, é a parte de análise que leva o tempo. Na minha perspectiva, é uma decisão idiota.

Se um possível empregador disser que "terceirizou a correção de bugs porque os desenvolvedores odeiam corrigir bugs", o que você acha? Quais podem ser suas preocupações?

Eu correria muito, muito, muito longe. Um desenvolvedor é sempre, sempre, sempre responsável por corrigir seus próprios erros. Comer comida de cachorro é um princípio básico da boa engenharia.

Além disso, a correção de bugs é tão importante, talvez mais que o desenvolvimento. Quero dizer, desenvolvimento é escrita de código, teste e depuração / correção.

O que recebo dessa empresa é que eles estão tratando a correção de bugs como uma tarefa de segunda classe. Isso, por si só, é bastante perturbador e eu questionaria muito a qualidade do trabalho (e, portanto, o ambiente de trabalho). O mais perturbador é que eles delegam o que, para eles, é um trabalho de segunda classe a trabalhadores no exterior. Isso é mais perturbador. Claramente, há estratificação social consagrada em seu processo de engenharia.

Um defeito sempre é causado pela raiz de uma alteração e, geralmente, o erro é de responsabilidade de quem a introduziu. Quem melhor que o autor para entender a natureza do bug e sua resolução?

Se for delegado em todo o mundo, como garantir que o autor original esteja disponível para o engenheiro terceirizado?

Ele estará disponível, deixando o engenheiro terceirizado que não tem nada além de uma lista de bugs e prazos, mas nenhum apoio do Metropole ? Que tipo de correção de bug uma pessoa poderia esperar executar? Quem conserta seus bugs? E o que impede que os desenvolvedores do Metropole aprendam através da correção de erros post-mortem?

Existem idiotas em todos os campos. Isto é especialmente verdade no software. Como é inevitável, sua única opção é trabalhar com idiotas que sabem mais do que você ou estão fazendo as coisas corretamente. Esta empresa não parece se encaixar nessa descrição.

Em resumo, fuja.

Eles realmente esperam que um monte de desenvolvedores juniores off-shore consigam consertar um monte de código de desenvolvedores seniores? É como ter uma enfermeira checando todos os neuroligistas trabalhando e refazendo-a onde ele fazia espigões. PÉSSIMA IDEIA!

Eu ficaria preocupado com o quão bem seus funcionários realmente sabem o código que estão desenvolvendo.
Eu também gostaria de saber a razão pela qual existem bugs suficientes para justificar os custos adicionais que isso traz. Eu também me preocuparia com o futuro a longo prazo da empresa, existem muitos artigos na Web que reivindicam essas empresas, usam o mesmo código para vários projetos, mesmo no mesmo setor.

A correção de códigos quebrados faz parte do processo de gravação de códigos, permitindo que você tenha uma melhor compreensão do que você fez de errado há 6 meses, para que você não cometa o mesmo erro, se algum outro desenvolvedor corrigir os erros, como evitar isso? bug de acontecer de novo e de novo?

Isso soa vagamente como meu empregador anterior, exceto pelo pouco "empregador em potencial". Eles estão perdendo os desenvolvedores por atrito e perderam muitos para oferecer suporte aos produtos existentes, além de adicionar novos recursos exigidos por alterações nas leis e regulamentos (60% da receita do escritório vem de um produto baseado em VB6, e a MS afirmou que os tempos de execução do VB6 não será distribuído em nenhum sistema operacional futuro, por isso será como quando o Vista saiu - uma corrida louca para consertar as coisas). Os futuros poderes querem trazer a empresa a público em breve, para que estejam morrendo de fome de todos por recursos para fazer com que o balanço pareça melhor do que é - portanto, contratar no exterior é a única maneira de chegar perto de permanecer no mercado.

Com base nas minhas experiências, o que a citação diz é que seu possível empregador é barato.

Depende do que eles querem dizer com "consertando bugs". Se isso estiver corrigindo erros durante o ciclo de desenvolvimento / teste, é muito estranho, esse é o trabalho dos desenvolvedores originais. Se, por outro lado, eles significam que terceirizaram a manutenção de um produto liberado, isso não é incomum e não é algo que me preocuparia.

Minha experiência foi que trazer uma equipe externa após o fato consumirá tanto tempo quanto consertar seus próprios bugs - eles precisam ser atualizados e incorporados ao processo de desenvolvimento. E, em seguida, manteve a velocidade continuamente. A coordenação é mais difícil do que escrever código.

Se eu vou trabalhar em uma base de código, gostaria de alguma garantia de que todos com privilégios de confirmação são razoavelmente competentes. Isso inclui muitas pessoas na Índia, por exemplo, mas não aquelas que geralmente são de fora do país.

Além disso, a maioria dos meus bugs está em seções mais complicadas do código, e essas são as que o programador offshore provavelmente menos entende antes de aplicar uma correção.

Essa política realmente existe subconscientemente em algumas empresas. Eu trabalho para um contratante; eu e meus colegas somos programadores mais proficientes do que os caras no local, eles nos pedem para ensiná-los a usar ferramentas etc., mas o outro lado disso é que identificaremos problemas em seu código mais rapidamente do que eles.

Geralmente, os programadores do cliente estão fisicamente localizados no mesmo prédio que pelo menos alguns dos usuários, portanto, é mais provável que tenham um contexto que não alcança os hemisférios. Achamos que funciona bem, a parte que falta para mim é que eles não estão revisando nosso código; portanto, quando o contrato termina, eles podem ter algumas surpresas ou perguntas, não devido a práticas ruins de nossa parte, necessariamente, mas apenas aos problemas usuais que você tem quando assumindo o projeto de outra pessoa.

De qualquer forma, fico feliz que, no nosso caso, não seja uma política oficial, como tal, acho que isso faria com que os programadores no local passassem a ser pouco mais que BAs.