Corrección de errores en alta mar

Si un posible empleador le dijera que "externalizó la corrección de errores porque los desarrolladores odian corregir los errores", ¿qué pensaría? ¿Cuáles podrían ser sus preocupaciones?

Corregir nuestros propios errores en realidad nos hace un mejor desarrollador . Y es un momento muy agradable para mí. Especialmente cuando están bien informados.

Si no les gusta corregir errores, el problema está en otra parte.

Sospecho que el problema es cómo la administración percibe los errores o, lo que es peor, las malas decisiones de diseño y / o la falta de pruebas (de la unidad), lo que hace que la reparación de errores sea dolorosa.

La corrección de errores de outsourcing probablemente empeorará las cosas.

Los desarrolladores pueden verse tentados a reducir la calidad. ¿A quien le importa? Algunos tipos en alta mar están allí para limpiar su desorden.

Hasta que los chicos de la costa reemplacen a los de la costa.

Vete , huye ... rápido y nunca mires atrás ...

He trabajado para una empresa así, pensaron que eran inteligentes,

• oye, todos tenemos errores, pero nuestros mayores se quejan de que pasan demasiado tiempo arreglando errores.

• abramos una oficina offshore y dejemos que los demás se ocupen de esto.

para un gerente que suena como un plan realmente bueno y los desarrolladores finalmente fueron liberados para abordar la tarea más interesante de crear la siguiente mejor opción.

ho ... pero espera ...

Después de dos años, pasaron de un equipo de 5 desarrolladores en su oficina principal que se encargó de todo a un equipo de 2 que crean cosas nuevas y un equipo de 30 que encuentran y corrigen errores.

sabes qué ... el equipo de corrección de errores está luchando, no pueden seguir el ritmo.

esto hizo que los "adultos mayores" fueran completamente incontables por sus propios errores. Peor aún, porque todo sucedió muy lejos, la administración tampoco se dio cuenta y la calidad del código se completó MUY rápido desde un nivel de calidad ya abismal.

Cuando me fui, ya abrieron dos oficinas más para los correctores de errores y todavía no pueden mantenerse detrás del ahora único desarrollador que los creó. en realidad piensan que es porque los nuevos no son lo suficientemente inteligentes ...

así que sí, de ahora en adelante, si una compañía dice que externalizó su corrección de errores a una oficina en el extranjero, confía en mí ... corro ... rápido.

Esta es la metodología de gestión de la bolsa de papel .

Párate en un ferrocarril, espera a que venga un tren, cuando lo veas, pon una bolsa de papel sobre tu cabeza y ... ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡PASEO !! !! Magia !

Hacer que la compañía le pague a alguien más para que limpie mi desorden parece una buena idea, excepto cuando se espera que tome su código 'limpio' y agregue nuevas funciones. Y si lo tienen tan jodido que no pueden arreglarlo, estará depurando la depuración.

No recibir una compensación adecuada porque tienen que contratar desarrolladores adicionales no es deseable.

Tener que pasar una cantidad desproporcionada de tiempo educando a los otros desarrolladores cuando podría haberlo arreglado usted mismo es contraproducente.

Una parte de mí siente que aquellos que crean problemas deberían ser los que los solucionen o no hay ningún incentivo para evitar crear errores en primer lugar.

¿Los desarrolladores no están interesados ​​en aprender de sus errores? ¿Puede corregir errores sin conocimiento específico del dominio, y el socio de subcontratación tiene este conocimiento? La parte de fijación es la más fácil la mayoría de las veces, es la parte de análisis que lleva el tiempo. Desde mi punto de vista, es una decisión tonta.

Si un posible empleador le dijera que "externalizó la corrección de errores porque los desarrolladores odian corregir los errores", ¿qué pensaría? ¿Cuáles podrían ser sus preocupaciones?

Yo correría lejos, muy, muy lejos. Un desarrollador es siempre, siempre, siempre responsable de corregir sus propios errores. Comer comida para perros es un principio básico de una buena ingeniería.

Además, la corrección de errores es tan importante, tal vez más que el desarrollo. Quiero decir, el desarrollo es escritura de código, pruebas y depuración / reparación.

Lo que obtengo de esta compañía es que están tratando la corrección de errores como una tarea de segunda clase. Eso en sí mismo es bastante inquietante y cuestionaría mucho su calidad de trabajo (y, por lo tanto, su entorno de trabajo). Lo más inquietante es que delegan lo que para ellos es el trabajo de segunda clase a los trabajadores en el extranjero. Eso es más perturbador. Claramente hay una estratificación social consagrada en su proceso de ingeniería.

Un defecto siempre se debe a un cambio, y generalmente el error es responsabilidad de quien introdujo el cambio. ¿Quién mejor que el creador para comprender la naturaleza del error y su resolución?

Si se delega en todo el mundo, ¿cómo asegurarse de que el autor original esté disponible para el ingeniero subcontratado?

¿Estará disponible incluso, dejando al ingeniero subcontratado que no tiene más que una acumulación de errores y plazos, pero no cuenta con el apoyo de Metropole ? ¿Qué tipo de corrección de errores podría esperar realizar una persona? ¿Quién arregla sus errores? ¿Y qué impide que los desarrolladores de Metropole aprendan a través de la corrección de errores post-mortem?

Hay pendejos en todos los campos. Esto es especialmente cierto en software. Como es inevitable, tu única opción es trabajar con imbéciles que saben más que tú o que están haciendo las cosas bien. Esta empresa no parece ajustarse a esa descripción.

En resumen, huir.

¿Realmente esperan que un grupo de desarrolladores junior off-shore puedan arreglar un montón de código de desarrolladores senior? Es como pedirle a una enfermera que verifique el trabajo de todos los neuroligistas y que lo vuelva a hacer donde hizo brumas. ¡MALA IDEA!

Me preocuparía lo bien que sus empleados realmente conocen el código que están desarrollando.
También me pregunto por qué hay suficientes errores para justificar los costos adicionales que esto conlleva. También me preocuparía el futuro a largo plazo de la empresa, hay muchos artículos en la web que afirman que estas empresas usan el mismo código para múltiples proyectos incluso en la misma industria.

Arreglar el código roto es parte del proceso de escribir código, le permite comprender mejor lo que hizo mal hace 6 meses, por lo que no comete el mismo error, si algún otro desarrollador corrige sus errores, ¿cómo puede evitarlo? error de suceder una y otra vez?

Esto suena vagamente como mi empleador anterior, excepto por el bit de "posible empleador". Han estado perdiendo desarrolladores por desgaste y han perdido demasiados para admitir productos existentes al tiempo que agregan nuevas características requeridas por los cambios en las leyes y regulaciones (el 60% de los ingresos de la oficina provienen de un producto basado en VB6, y MS ha declarado que los tiempos de ejecución de VB6 no se distribuirá en ningún sistema operativo futuro, por lo que será como cuando salió Vista: una lucha loca para arreglar las cosas). Los poderes fácticos quieren hacer pública la compañía pronto, por lo que están hambrientos de recursos para hacer que el balance general se vea mejor de lo que es, por lo que contratar en el extranjero es la única forma de acercarse a permanecer en el mercado.

Según mi experiencia, lo que dice la cita es que su posible empleador es barato.

Depende de lo que quieran decir con "corregir errores". Si esto está solucionando errores durante el ciclo de desarrollo / prueba, entonces es muy extraño, este es el trabajo para los desarrolladores originales. Si, por otro lado, significan que han subcontratado el mantenimiento de un producto lanzado, entonces esto no es inusual y no es algo de lo que me preocupe.

Mi experiencia ha sido que incorporar un equipo externo después del hecho consumirá casi tanto tiempo como solo solucionar sus propios errores: deben actualizarse e incorporarse al proceso de desarrollo. Y luego se mantuvo al día continuamente. La coordinación es más difícil que escribir código.

Si voy a trabajar en una base de código, me gustaría asegurarme de que todas las personas con privilegios de compromiso sean razonablemente competentes. Esto incluye a algunas personas en la India, por ejemplo, pero no a las que generalmente son deslocalizadas.

Además, la mayoría de mis errores se encuentran en secciones de código más complicadas, y esos son los que el programador offshore es menos probable que comprenda antes de aplicar una corrección de errores.

Esta política en realidad existe inconscientemente en algunas empresas. Yo trabajo para un subcontratista; mis colegas y yo somos programadores más hábiles que los chicos en el sitio, nos piden que les enseñemos cómo usar herramientas, etc., pero el otro lado de eso es que detectaremos problemas en su código más rápido que ellos.

En general, los programadores del cliente están ubicados físicamente en el mismo edificio que al menos algunos de los usuarios, por lo que es más probable que obtengan un contexto que no se extienda a través de los hemisferios. Encontramos que funciona bien, la parte que falta para mí es que no están revisando nuestro código, por lo que cuando finalice el contrato pueden tener algunas sorpresas o preguntas, no debido a prácticas de mala calidad por nuestra parte necesariamente, sino solo los problemas habituales que tiene cuando hacerse cargo del proyecto de otra persona.

En cualquier caso, me alegro de que en nuestro caso no se trate de una política oficial, por lo que creo que erosionaría a los programadores en el sitio a ser poco más que BA.