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?
Os desenvolvedores odeiam corrigir bugs? Eu acho que é mais que eles odeiam encontrar uma maneira confiável de reproduzir o bug, e é para isso que servem os testadores. Se você está terceirizando a correção de bugs, também pode terceirizar toda a equipe de desenvolvimento. Ninguém entende o código, assim como a pessoa que o escreveu .
12119 Rob
1
Parece uma péssima ideia.
Andres F.12 /
1
@AndresF. +1. Isso criará um ambiente em que os desenvolvedores apenas jogam lixo na parede e esperam que ele grude. Não é problema deles, se não, certo?
MrFox 12/12/12
Respostas:
25
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.
@ Aditya: nada assustador aqui, é exatamente o que está acontecendo no meu último empregador. Os caras do exterior tinham o suficiente de correção de bugs o tempo todo e seu gerente (amém) começou a fornecer treinamento. A certa altura, eles se tornaram bons o suficiente para iniciar refatores simples, limpezas etc. Nesse meio tempo, no escritório principal, nada mudou. I pode muito facilmente ver que no próximo ano os caras no exterior vai fazer a maior parte do trabalho e das principais caras de escritório ... bem ... muito ruim que não viu o trem vindo ;-P
Newtopian
15
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.
"Além disso, a correção de erros é tão importante, talvez mais que o desenvolvimento". Eu sei o que você quer dizer com isso, mas eu chego ao ponto de dizer: não consigo entender nenhuma dicotomia assim. A correção de bugs é um aspecto intrínseco e fundamental do desenvolvimento.
11111 Dan Ray
1
@ Dan - sim, sua afirmação é muito mais correta. Não existe essa dicotomia.
Luis.espinal
4
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.
+1 por ter o pior emprego possível de todos os tempos. Parece que eles não utilizaram o suficiente dessa receita de volta ao projeto.
Ramhound
exceto o bit "potencial empregador" <LOL
Greg B
Percebo a frase "empregador anterior". Parabéns.
21711 David Thornley
@ Ramhound, David, Greg, Era um lugar melhor quando comecei, deixei o local no final de dezembro (logo após meu 5º aniversário). Ninguém foi contratado desde que fui contratado e, nos últimos 2 anos, 6 desenvolvedores desistiram. O último a partir havia 11 anos.
Tangurena
3
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.
@ Greg & Steve - não acredito que seja honesto. Se eles estão corrigindo bugs, digamos em uma versão de lançamento, como essas correções podem ser mescladas na compilação de teste, se os desenvolvedores não escrevem o bug, elas se corrigem.
Ramhound
Se as correções de bugs forem registradas no controle de origem, elas podem ser facilmente transferidas por outra equipe para outro ramo. Não é grande coisa.
21711 Steve
Você faz uma boa observação, embora eu realmente aprovasse esse cenário apenas no caso em que o aplicativo é um sistema legado que não está mais sendo desenvolvido ativamente, mas precisa ser mantido funcional por algum motivo. Digamos que uma nova geração que seja uma forma de reescrita completa seja a que está em questão.
Newtopian
2
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.
Respostas:
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.
fonte
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 !
fonte
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.
fonte
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.
fonte
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.
fonte
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!
fonte
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?
fonte
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.
fonte
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.
fonte
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.
fonte
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.
fonte
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.
fonte