¿Un desarrollador de software que produce un código defectuoso y difícil de seguir rápidamente para cumplir con los plazos es un buen desarrollador?

No, pero aún pueden ser recompensados.

Enviar código con errores rápidamente es una forma de cumplir con los plazos que funciona si el jefe no se da cuenta de que el código de una persona en particular se debe corregir con frecuencia después de enviarlo. La mayoría de los gerentes no hacen este análisis, y solo lo resuelven porque algún otro ingeniero señala el problema y da un montón de ejemplos. Algunos desarrolladores han aprendido a trabajar de esta manera sin pensar realmente en lo que están haciendo. También conocí a algunos desarrolladores que hacen esto como una manipulación cínica.

A veces, la presencia de una función es más importante para los vendedores y clientes que si la función se implementa por completo o se bloquea ocasionalmente. Esta es otra situación que premia las malas prácticas de desarrollo.

No es ni bueno ni malo.

Código rápido y sucio:

1. Funciona perfectamente basado en los casos de prueba dados
2. Cumple el plazo
3. No cumple con las pautas de revisión de código
4. Puede haber otros escenarios que valga la pena considerar, pero no hay tiempo para eso, y de todos modos, el cliente no lo menciona explícitamente.
5. Lo más probable es que la próxima versión deba construirse sobre este código, por lo que este código deberá ser flexible, pero eso es complejo y no tenemos tiempo para eso.
6. Los errores pueden aparecer en realidad durante UAT o durante la etapa de producción, pero esperemos que no y solo asegurémonos de pasar los casos de prueba dados.

Código perfecto y que consume tiempo:

1. Revisiones de código aprobadas.
2. Pasó casos de prueba dados, incluidos posibles escenarios no mencionados explícitamente pero probados de todos modos, pruebas de regresión, pruebas de rendimiento, etc.
3. Lo suficientemente flexible y relativamente simplificado para que sea dinámico y / o flexible para futuras mejoras o reutilizaciones.
4. Menos posibilidades de errores cuando se implementan en Producción, lo que significa menos modificaciones y menos demoras.
5. Se perderá el plazo de entrega de la unidad y deberá explicarse a los superiores.

Un buen desarrollador debe ser capaz de cumplir cualquiera de estos objetivos, y será la decisión del Gerente del Proyecto qué camino tomar. Entonces recordará y se dará cuenta de que en la mayoría de los casos en los que usted, como desarrollador, se vio obligado a entregar un código rápido y sucio contra la ética de su desarrollador, estaba bajo un Gerente de Proyecto que odia tener que explicar las cosas a los superiores y simplemente preferiría decir Sí a cualquier cosa que tengan que decir.

Son un gran desarrollador … para la empresa … si la velocidad y la calidad exterior es lo que fueron contratados para producir. Tienes que saber tu situación. Algunas empresas son pequeñas y las nuevas oportunidades de negocios son sumamente importantes. Los retrasos en la implementación de una solución lo suficientemente buena pueden deshacer la posibilidad de una nueva asociación. Los errores pueden ser inevitables en un proceso acelerado.

Dada la elección entre ejecución temprana y con errores versus ejecución tardía e impecable, a menudo he visto que los gerentes prefieren la velocidad. Las organizaciones más grandes tienden a tener los criterios opuestos. A menudo miran con desaprobación a quienes ponen la conveniencia antes del proceso.

Realmente, depende de las expectativas y objetivos establecidos por el liderazgo. Hojear la nariz a toda velocidad y lo que cuesta desde el punto de vista técnico de la deuda no llega muy lejos cuando esa es la expectativa. Lo mismo cuando es la situación opuesta. La pureza que se ve en los foros web a menudo no es realidad.

Si la expectativa es que construyan un producto de producción que impulse aspectos clave del negocio, entonces absolutamente no. Los desarrolladores que escriben códigos de calidad inferior para cumplir con una fecha límite no son desarrolladores que deberían estar en esa posición, al menos no sin una estrecha supervisión por parte de un desarrollador o gerente técnico más experimentado.

Pregúntese por qué todo esto es importante.

Al final del día, escribe un código deficiente para cumplir con una fecha límite, puede racionalizar que ha ganado su salario por esos días. Lo que significa que ha cumplido con su obligación de fiduciaria con su empresa en función del tiempo que le han pagado (se presentó y activó el código durante dos semanas, por ejemplo). Ahora que ha producido este código, es parte del negocio y se espera que lo maneje.

Le costó a la compañía dos semanas de su salario. ¿Cuánto les costará cuando se descomponga su código a medias? ¿Cuántos clientes perderán la confianza en el negocio e irán a un competidor? ¿Cuánto generará su código a medias aumentar las tarifas de alojamiento porque no consideró la frecuencia de un evento o el costo de manejarlo? ¿Cuánto durará la interrupción? Y si requiere personal de ingeniería adicional para ayudarlo a resolverlo, ¿qué tan probable es que puedan limpiar su desorden de manera oportuna si el componente no está bien estructurado, documentado y diseñado para ser mantenible? ?

A veces esto no importa, al menos no al principio. En los casos en que esté desarrollando un prototipo para ver qué tan bien les gusta a los usuarios, es posible que no vea ninguna razón para invertir su valioso tiempo para diseñar para el uso de producción. Pero, ¿con qué rapidez pueden los usuarios acostumbrarse a él y cuánto tiempo tendrán para producirlo cuando sea necesario?

Al final del día, ¿realmente vale la pena desperdiciar recursos (tiempo, esfuerzo, estrés, clientes) en un código deficiente? Quizás en casos de prototipos. Pero incluso entonces, considere el uso de producción real, incluso si no espera que lo necesite. Por lo que sabe, otro desarrollador puede necesitar usar su componente para un aspecto comercial crítico del producto. Tu componente se volverá importante muy rápido sin que te des cuenta.

Entonces, si un desarrollador se apresura a cumplir una fecha límite y escribe un código deficiente en el proceso, ¿son malos? Depende. ¿Se les estaban dando plazos poco razonables o dependiendo de los resultados deficientes de otros equipos? Es tan subjetivo que es difícil de decir.

Una cosa es segura. Siempre se puede comprometer y entregar en exceso. No necesita una solución perfectamente optimizada en la mayoría de los casos, pero al menos debe diseñar para el mundo real. Y eso incluye escribir código que use un buen estilo, sea legible, depurable, etc.

Es el desarrollador al que la compañía seleccionó, capacitó, impuso plazos, se queja y, finalmente, se lo merece.

Estoy preocupado por quién manejó los requisitos y cómo, quién hizo las estimaciones y cómo, quién administra el proyecto y qué profesionalmente. Cuando esas actividades son realizadas por un profesional, el desempeño individual nunca es una sorpresa.

Para tener buenos programadores, debes ser una buena compañía. Si el código y la corrección son toda la metodología que tiene, ese es el resultado obvio, inevitable.

Cuando escribo un código que solo se usará unas pocas veces, o que solo yo y / o mi socio comercial lo usaremos, no puedo justificar el esfuerzo involucrado en hacerlo a prueba de balas, así que no lo hago.

Consideremos un ejemplo: Casos perimetrales: demandas perfectamente razonables sobre el código que muy raramente sucederán. Si espero que millones de personas usen el código, entonces, por supuesto, debería pasar semanas explorando los confines exteriores. Si soy el único usuario, tal vez no.

¡Buena pregunta!

Es extremadamente difícil de responder. ¿La razón? Hay una miríada de factores circunstanciales que llevan a un desarrollador a ponerse en esa posición y muy pocos de ellos están bajo el control de un desarrollador o de su creación.

Me llevaría la longitud de una pequeña novela para leerlas todas.

Suponiendo que no hay alternativa …

Un buen desarrollador lo haría después de tener claro con el grupo más amplio que lo está haciendo y que todos entiendan las implicaciones (principalmente la deuda técnica). Si la fecha límite es tan crítica, ¡entonces debe hacerlo!

(Helmuth von Moltke el Viejo)

Un desarrollador pobre lo hace unilateralmente sin colaboración para parecer cumplir con la fecha límite.

Sin embargo, esta es una suposición muy débil. El costo futuro de la mala calidad es tan alto que hay una gran cantidad de preguntas que haría primero … algunas podrían ser:

• ¿Qué está impulsando la fecha límite? ¿Es real o artificial? Existen muchos plazos que pueden ser cuestionados razonablemente.
• ¿Podemos entregar menos funciones en lugar de sacrificar la forma? es decir, ¿prefiere diferir las características en lugar de la calidad?
• ¿Podemos gastar dinero en preferencia a reducir la calidad?
• ¿Podemos simplificar alguna parte del sistema y expandirnos en una fecha posterior? es decir, reducir la complejidad en lugar de la calidad?
• ¿Tenemos un plan para corregirlo después?
• y así sucesivamente … idealmente, la calidad debería ser la última ‘palanca’ para tirar.

Yo diría que no. Lo he visto, les he hecho depurar su propio código meses después y lo observé mientras me llevó más de seis horas entender el flujo del código porque sucedió el pecado capital de la mala denominación de variables.

Si bien sucede a veces, para cumplir con una fecha límite. El próximo sprint / iteración debería ser arreglar ese código.

Idealmente, el plan del proyecto debe tener relleno para permitir suficiente tiempo para escribir el código correctamente. Si eso no está en el plan, ese plan debe ajustarse para garantizar que se escriba un código bueno y comprobable.

Depende. Desafortunadamente.

Si se trata de una demostración que se muestra de forma controlada para asegurar la inversión para su puesta en marcha, es un empleado muy valioso (y efectivo). Esto no lo convierte en un buen ingeniero, pero si el CEO le da crédito por ayudar a asegurar esa ronda A, se lo merece.

Si estamos en el juego a largo plazo, escribir código que va a ser un negocio central durante los próximos años (multiplique eso por 2 veces si es conservador), entonces debe mejorar o irse. Su gerente y quien lo tolera o lo promueve ahorcado en la primera publicación telegráfica. Cada línea de código que escriba hoy le costará a usted y a la flexibilidad comercial en el futuro. Te costará mantenerte a flote y perder oportunidades. Esa es la consecuencia inevitable de un código mal mantenible. Está hipotecando con una tasa de interés muy mala el futuro del negocio para cumplir con los objetivos trimestrales.

Tal vez tal vez no.

¿Los plazos eran plausibles con un código bien diseñado o el calendario era tan corto que exigía halagos, humo y espejos espeluznantes? ¿Le advirtió el desarrollador que la única forma de enviar en el plazo exigido era acumular una deuda técnica significativa? (¿o en realidad son especialistas en “hacerlo de la manera que pueda, pero asegúrese de que se haga, y rápido!”, ¿y lo contratan para eso?)

Esas son todas las razones “buenas” para hacer lo que sea necesario.

También existen malas razones. Como si fueran flojos y quieran cumplir con la fecha límite, pero también atrapan un montón de fines de semana de 3 días (u obtengan algunas puntuaciones altas netas). O quieren asegurarse de que nadie más pueda ocuparse de la base del código, por lo que debe mantenerlos en el proyecto …

Sin saber cuán razonable fue una solución de baja deuda técnica en el marco de tiempo, es difícil saber si tiene a alguien bueno o no. (excepto la advertencia … si no te avisaron, probablemente no sean tan buenos)

Uhh … Probablemente no. En serio, acabas de decir todas las cosas malas que nunca son buenas para un desarrollador. Quise decir que es bastante obvio, acabas de responder tu propia pregunta.

Es como decir: “¿Es una hamburguesa que está hecha de carne sucia, vieja y de baja calidad pero que se hace realmente rápidamente una buena hamburguesa?”

Seriamente…

Espero haber ayudado. Aunque dije lo obvio.

No.

Un buen desarrollador de software escribe código probado para que las partes que se sub-estándar puedan ser reparadas de manera segura.

Un buen desarrollador de software escribe código modular donde los módulos hacen exactamente una cosa.

Un buen desarrollador de software escribe código con la idea de que la siguiente persona que lo toca es homocida y tiene su domicilio.

Un buen desarrollador de software no se junta para cumplir una cita porque un BUEN desarrollador de software sabe que también hay una próxima entrega.