Soy un desarrollador de software recién egresado de la escuela de posgrado, he estado trabajando en la industria durante 5 meses y todavía me estoy adaptando al mundo de los negocios. Durante los últimos 5 meses, he aprendido mucho de mis compañeros de trabajo (personas que me brindan un apoyo increíble, por cierto), pero una pregunta para la que no puedo obtener una respuesta directa es:
Dado un informe de error o una solicitud de mejora, ¿debería invertir tiempo en comprender el problema y solucionar el problema raíz en el código base, o simplemente abordar el problema indicado con una ronda de trabajo de alto nivel y pasar a la siguiente solicitud? ?
Todo el mundo en mi equipo parece estar de acuerdo en que abordar sistemáticamente la causa raíz es mejor (por una multitud de razones, incluido el comportamiento consistente en todo el producto, la facilidad de mantenimiento en el futuro, etc.), pero dado el flujo de entrada casi constante de alta problemas prioritarios, parece que producimos una cantidad sorprendente de rondas de trabajo ("apagamos el fuego por ahora, lo arreglaremos para el próximo lanzamiento importante...").
Por lo que puedo decir, esta actitud proviene de mi gerente, quien está jugando un juego de equilibrio entre dar a los desarrolladores tiempo y espacio para hacer las cosas bien, mientras que también enfrenta presiones de tiempo y presupuesto desde arriba.
Claramente, la única respuesta correcta puede provenir de mi gerente, y tal vez del vicepresidente de desarrollo, pero tengo curiosidad por saber cómo otras personas lidian con estos dos intereses en conflicto en el desarrollo de productos.
(Mi pregunta está abierta a todas las áreas de I + D, no solo al software).
Haces lo mejor que puedes con los recursos disponibles. Si no hay cola de problemas, vuelva y limpie. Si hay una cola de problemas, apague los incendios. La lógica aquí es que no deje abiertos los problemas urgentes cuando se haya implementado una solución de curita. La señal de un lugar de trabajo técnico deficiente es cuando su estructura es todo curitas y no se puede volver a limpiar.
Su pregunta plantea uno de los debates más antiguos entre software y empresa. Los buenos desarrolladores quieren hacerlo bien y desde la raíz. Tal es la naturaleza de los buenos desarrolladores apasionados por su oficio.
La realidad es que en los negocios eso rara vez sucede; incluso en empresas donde el software es el negocio. Hay demasiados intereses en competencia (administración, plazos, marketing, etc.) como para adoptar un enfoque puritano/académico para escribir código y corregir errores todo el tiempo. El enfoque de solución rápida de alto nivel es bastante común tanto por el bien de las empresas que desean obtener resultados inmediatos como por las razones que señaló Keshlam.
Al final, lo rápido casi siempre tendrá prioridad sobre hacerlo bien (según los verdaderos estándares de los desarrolladores) porque las empresas entienden lo rápido mucho más de lo que pueden entender bien (hasta que tienen una caída del producto que erosiona las ganancias). Entonces querrán hacerlo bien, pero solo por un tiempo hasta que terminen en la misma rutina operativa de complacencia que los llevó allí.
Ahí es donde es su trabajo escribir código de calidad de la manera correcta si puede hacerlo rápidamente y mostrarle a la empresa que la manera correcta puede ser realmente más rápida y alineada con los intereses comerciales.
No hay una sola respuesta correcta. Depende de sus clientes, su modelo de entrega y su personal. Recuerde, esto es ingeniería de software en lugar de informática; se esperan compensaciones.
Las correcciones al código de producción a menudo se mantienen lo más mínimas posible para reducir el riesgo de introducir nuevos errores, incluso si eso significa dejar las exposiciones conocidas para tratarlas más adelante. No es elegante, pero es lo que necesita el negocio.
Además, un gran cliente puede estar perdiendo un megadólar por minuto mientras el sistema está inactivo. La solución rápida es esencial, con una solución más limpia diferida hasta que el tiempo lo permita.
Citando a Steve Bois: "Haz que funcione. Hazlo bien. Hazlo genial". En ese orden. Si puede saltar directamente a excelente con un tiempo mínimo y un riesgo mínimo, mucho mejor, pero generalmente no tenemos ese lujo a menos que estemos desarrollando de novo y sin presión de cronograma / recursos.
Eso depende. Esta es una de las preguntas que realmente dependen de los atributos individuales de cada boleto:
Tiene razón en que solo la gerencia puede dar la respuesta correcta, porque ellos son los que ven el panorama general y pueden priorizar las diferentes necesidades e implicaciones de las diferentes opciones con respecto a todos los boletos. Pero los desarrolladores son los que están familiarizados con el código y la estructura reales del proyecto, por lo que es su trabajo darle al gerente estimaciones sobre las diferentes soluciones.
Esta es la compensación que hacemos en el mundo de los negocios. Siempre es un acto de equilibrio entre las prioridades: recursos frente a plazos. Calidad frente a ingresos. Escalabilidad frente a conjunto de características.
El gerente y el VP son quienes mejor conocen las variables en cada momento, y deben tener claras las prioridades. Nadie puede decirte cuál es el saldo aparte de ellos. Google puede asignar a 10 personas a mejorar su página de inicio de sesión porque se usa (¿alguna idea, muchachos?) veces al día. Su portal de capacitación para empleados en una empresa de 250 personas, quizás cinco veces al día. O(n^2) a O(2n) puede valer miles por mes para Google. Su retorno de eso probablemente sería de alrededor de $ 0.15 por día.
Por eso, dicho sea de paso, los buenos arquitectos valen su peso en oro. Entrar con un diseño sólido inicialmente le ahorrará años de dolor a largo plazo.
DJClayworth
mosquito
mosquito
gnasher729