¿Cómo puedo saber si mi desarrollador es malo?

Hay demasiadas variables desconocidas para proporcionarle una respuesta inmediata. Dicho esto, debe sentarse con su desarrollador para revisar la lista de errores. Ordene los errores con prioridad, en relación con las necesidades del usuario / mercado. Luego, pídale a su desarrollador que proporcione una estimación de cuánto tiempo llevará resolver los tres primeros, más o menos, cada uno de los cuales debería llevar algunas horas (en lugar de días o semanas).

Luego, asegúrese de que esos errores se resuelvan dentro del tiempo asignado (es decir, un día o dos más tarde). Si el desarrollador no puede cumplir con la fecha límite acordada, algo podría estar mal. Repita el proceso, dándole el beneficio de una duda, y si el cronograma vuelve a caer, es probable que tenga problemas. Si los errores se resuelven, pero regresan en una fecha posterior, es probable que también tenga un problema.

La clave es dividir el esfuerzo en incrementos lo suficientemente pequeños como para que quede claro si se está progresando y si el desarrollador está pirateando soluciones (es decir, errores recurrentes). Esto impone disciplina tanto al desarrollador como a usted. El alcance de su alcance podría ser la fuente del problema, pero este enfoque detallado le permitirá saber en cuestión de días si su desarrollador no funciona.

La mejor manera de determinar qué tan bueno o malo es un desarrollador es ver cómo puede escribir código libre de errores bajo estrés.

Los buenos desarrolladores tienden a escribir código modular limpio con un manejo de excepciones adecuado y disposiciones para casos extremos. Incluso si eso está bajo restricciones de tiempo.

En cuanto a una aplicación grande, si se escribe desde cero, pueden existir muchos errores dada la enorme base de código. El desarrollo impulsado por pruebas suele ser el camino a seguir en tales casos (si no siempre).