¿Es “mientras funcione” la norma? [cerrado]

Vea mi pregunta más reciente: ¿Es la programación como profesión en una carrera hacia abajo?

Mi última tienda no tuvo un proceso. Agile esencialmente significaba que no tenían un plan en absoluto sobre cómo desarrollar o administrar sus proyectos. Significaba "oye, aquí hay un montón de trabajo. Ve a hacerlo en dos semanas. Somos rápidos y ágiles".

Lanzaron cosas que sabían que tenían problemas. No les importaba cómo se escribían las cosas. No hubo revisiones de código, a pesar de haber varios desarrolladores. Lanzaron software que sabían que tenía errores.

En mi trabajo anterior, la gente tenía la actitud siempre que funcione, está bien. Cuando solicité una reescritura de algún código que había escrito mientras estábamos esencialmente explorando la especificación, lo negaron. Quería reescribir el código porque el código se repitió en varios lugares, no había encapsulación y la gente tardó mucho tiempo en realizar cambios.

En esencia, mi impresión es esta: la programación se reduce a lo siguiente:

1. Leer un libro sobre la última herramienta / tecnología
2. Lanzar código en conjunto basado en esto, evitando escribir cualquier código individual porque la compañía no quiere "mantener el código personalizado"
3. Mostrarlo y pasar a lo siguiente, "mientras funcione".

Siempre me dije que en el próximo trabajo conseguiré una tienda mejor. Nunca pasa Si es así, entonces me siento atrapado. Las tecnologías siempre cambian; Si el único desarrollo profesional aquí es leer el último libro de tecnología de MS Press, entonces, ¿qué ha construido en 10 años, sino un conocimiento superficial de varias tecnologías? Estoy preocupado por:

1. La mejor manera de tener estándares profesionales
2. Cómo desarrollar conocimiento y experiencia significativos en esta situación

Usted ha tropezado indirectamente con lo que creo que es el aspecto clave para ser un buen desarrollador : lograr el equilibrio entre " mientras funcione " y un código elegante y bien diseñado.

Al igual que en la política, es mucho más fácil apostar su posición en un extremo del espectro en lugar de tomar una posición matizada en el medio. La mayoría de los desarrolladores con los que me encuentro caen en una de dos categorías: codificación de hacks de vaqueros y astronautas de arquitectura. Trato de lograr un equilibrio entre los dos. No es tan fácil como parece.

Para responder más directamente a su pregunta, sí, creo que "mientras funcione" es a menudo la norma. Pero míralo de otra manera: estás en una excelente posición para educar a tus colegas e intentar introducir algunas mejores prácticas. Pero no vaya al extremo y recuerde por qué todos estamos haciendo esto: para resolver los problemas de nuestros clientes.

>> En mi trabajo anterior, la gente tenía la actitud siempre que funcione, está bien.

Puede ser que sea una minoría aquí, pero tengo la misma actitud y creo firmemente que para reescribir algo debe haber evidencia clara de por qué necesitamos esto. Y no me refiero a algo como "uf, no me gusta cómo se codificó": cada desarrollador tiene sus preferencias sobre el código. Debería haber algunos problemas con la parte que queremos reescribir:

• Problemas de rendimiento
• Se encontraron más errores que en cualquier otra parte del sistema.
• Los desarrolladores pasan más tiempo cuando trabajan en esta parte
• etc.

Agile no es responsable de que ningún humano decida lanzar un software con errores; los humanos son.

Dicho esto, le das mucha importancia a la calidad, y es bueno. Estoy seguro de que eres perfeccionista y te preocupa tu propio valor si no te pones al día con las últimas tecnologías.

El problema es que el perfeccionismo lleva a la dilación y la dilación lleva a la mediocridad .

Es por eso que las empresas priorizarán temas como el tiempo de comercialización y el uso ágil para entregar valor rápidamente y a un ritmo predecible.

Como no describió la estrategia comercial de su empresa, creo que debería comenzar haciendo una pregunta al respecto a sus gerentes.

Al estar alineado con sus objetivos y planes (lo contrataron para ayudarlos a lograrlos), estará en una mejor posición para comprender cómo podría contribuir a ellos en lugar de centrarse en sus propios objetivos personales.

Estoy seguro de que al probar understandsu valor, podrá compartir el suyo, y ese será el comienzo de una colaboración fructífera.

Y si descubre que no saben lo que están haciendo, su única opción será dejar de fumar .

Todo depende de lo que estés construyendo. Si está construyendo un micrositio que solo estará en línea durante un mes, y tiene nueve días para construirlo: entonces sí, siempre que funcione será suficiente.

Si está escribiendo los algoritmos de vuelo por cable para el sistema FA-18, entonces es mejor que esté construido lo más perfectamente posible.

Entonces, como es el caso con la mayoría de las respuestas tecnológicas ... depende.

Depende de la empresa. Sin embargo, muchas compañías tienen una seria competencia y presión de tiempo. Esa es una razón típica. Otra sería una gran carga de trabajo, potencialmente sin suficiente personal. (Existen algunas muy buenas razones para no tener suficiente personal, que no son necesariamente culpa de la empresa). Dicho esto, algunas organizaciones no pudieron salir de una bolsa de papel mojada.

Creo que la regla 80/20 se aplica aquí. Básicamente, debes soportar el horrible 80% y llegar al 20%. Sin embargo, tenga en cuenta que incluso ellos tendrán que hacer compensaciones. En los negocios, generalmente no importa que lo tengas absolutamente correcto. Es importante que lo tengas ahora mismo.

Si el único desarrollo profesional aquí es leer el último libro de tecnología de MS Press, entonces, ¿qué ha construido en 10 años, sino un conocimiento superficial de varias tecnologías?

Eso sería bastante desagradable, pero puede haber habido algunos fracasos espectaculares en esa década. He visto muchos lugares donde puedo recordar cosas bastante específicas que me gustaron de trabajar allí o que no disfruté y, por lo tanto, cuestionaría tener eso nuevamente en mi nuevo lugar de trabajo. A veces puede haber una nueva práctica para probar, como si una empresa intenta implementar Scrum o adoptar un enfoque de desarrollo basado en pruebas, esas pueden ser oportunidades, pero no necesariamente se ven como un desarrollo profesional, ya que no se trata de un aula formal.

Conozco varios lugares donde el "mientras funcione" es común junto con varias estrategias de codificación de vaqueros. En un par de nuevas empresas, he visto este tipo de mentalidad que puede tener sentido si la empresa es tan joven que todavía están tratando de aclarar la idea de lo que realmente están tratando de hacer. En otras compañías en las que he trabajado, ha habido más procesos y una madurez que puede ser bastante buena, aunque no necesariamente fácil de encontrar, me temo. Algunos lugares tenían algunos procesos que tenía que ver e ir, "Me gusta eso. Recordaré eso para situaciones de trabajo posteriores", y otros donde iría, "Realmente no me gusta eso. Notaré para tratar de evitar eso en el futuro ".

Trabajé en una tienda como esta por un tiempo justo en el punto en que los estaba alcanzando. Había aplicaciones de dos o tres años con errores conocidos que literalmente no podían resolver. Piense en un bucle largo de 4.000 líneas con un cálculo continuo para anchos y alturas de diseño. Arreglar una pieza de código para reparar un problema en una instancia daría como resultado veinte problemas en otro lugar porque los desarrolladores anteriores habían asistido a problemas similares al ajustar arbitrariamente los resultados de cálculo con números mágicos. El código no puede describirse como algo más que tóxico.

Finalmente me entregaron un nuevo proyecto que mi jefe me dijo que podía usar este código existente para manejar diseños. De alguna manera lo convencí de que me dejara "alterarlo" para que me diera algo de tiempo extra. En su lugar, usé el tiempo para escribir una biblioteca bien diseñada para ayudar con el diseño. Los errores en este nuevo proyecto literalmente me tomaron 10 segundos para resolverlos. Podía identificar problemas incluso antes de mirar el código para ver qué salió mal.

Pensé que esto resultaría en un punto de inflexión para mi gerente, pero todo lo que obtuve fue una palmada en la espalda y esencialmente me dijo que "Tu camino funciona también, supongo".

Desde entonces he comenzado a trabajar para otra tienda y las cosas están mejor aquí. El punto es que no puedes cambiar de opinión. Solo ve a trabajar a otro lado.

Todavía tengo esperanzas de que en la economía haya una especie de proceso evolutivo que tarde o temprano expulse a esas empresas. Pero tal vez el alto ritmo del progreso tecnológico produce demasiados nichos nuevos, por lo que incluso los competidores débiles aún pueden encontrar suficiente "comida".

Si desea aumentar sus posibilidades de trabajar en un buen lugar, busque una empresa que tenga un producto que venden a muchos clientes en lugar de escribir algo nuevo cada pocas semanas. Debería haber más interés en tener una buena base de código y poder agregar nuevas características sin romper el código existente todo el tiempo.

Me recuerda a mi compañero mayor de la universidad. Estaba tomando una clase de diseño VLSI, y para su primera tarea se le ocurrió un componente del orden de micrómetros de ancho y una milla de largo. Las simulaciones pasaron perfectamente.

Su respuesta a sus críticos fue: "Todo lo que sé es que mi mierda funciona".

Una norma bastante buena es el principio de Pareto

Tengo experiencia en un proyecto con la regla 80-20 y funcionó muy bien. Creo que las respuestas a esta pregunta "¿Dónde trazas la línea para tu perfeccionismo" también pueden ser útiles.

El término "principio de Pareto" también puede referirse a la eficiencia de Pareto. El principio de Pareto (también conocido como la regla 80-20, la ley de los pocos vitales y el principio de la escasez de factores) establece que, para muchos eventos, aproximadamente el 80% de los efectos provienen del 20% de las causas. El pensador de gestión empresarial Joseph M. Juran sugirió el principio y lo nombró en honor al economista italiano Vilfredo Pareto, quien observó en 1906 que el 80% de la tierra en Italia era propiedad del 20% de la población; desarrolló el principio al observar que el 20% de las vainas de guisantes en su jardín contenían el 80% de los guisantes. Es una regla general común en los negocios; por ejemplo, "el 80% de sus ventas provienen del 20% de sus clientes". Matemáticamente, cuando algo se comparte entre un conjunto suficientemente grande de participantes, debe haber un número k entre 50 y 100 de modo que "k% sea tomado por (100 - k)% de los participantes". El número k puede variar de 50 (en el caso de distribución equitativa, es decir, el 100% de la población tiene partes iguales) a casi 100 (cuando un pequeño número de participantes representa casi todo el recurso).No hay nada especial sobre el número 80% matemáticamente, pero muchos sistemas reales tienen k en algún lugar alrededor de esta región de desequilibrio intermedio en la distribución. El principio de Pareto solo se relaciona tangencialmente con la eficiencia de Pareto, que también fue presentada por el mismo economista. Pareto desarrolló ambos conceptos en el contexto de la distribución del ingreso y la riqueza entre la población.

Enlace a la fuente

Cuando solicité una reescritura de algún código que había escrito mientras estábamos esencialmente explorando la especificación, lo negaron. Quería reescribir el código porque el código se repitió en varios lugares, no había encapsulación y la gente tardó mucho tiempo en realizar cambios.

Sin ofender, pero como gerente leí esa declaración en algún lugar a lo largo de las líneas de:

"Cuando pedí que me pagaran dos veces para reescribir algún código que ya había escrito, mi compañía no quería pagar. Quería el dinero extra para limpiar el desastre que hice cuando lo escribí la primera vez, y mi mis colegas estaban enojados conmigo por hacerles la vida difícil ".

Si se está quejando de su propio código, no tiene mucho en qué apoyarse.

ACTUALIZAR

Entiendo que este POV es impopular. Pero tampoco creo que sea incongruente con las responsabilidades y actitudes de un desarrollador profesional.

Si comienza a escribir código limpio (y hay una multitud de razones para hacerlo, independientemente de si cree que su código va a ver el uso de producción o no), entonces tendrá este problema con mucha menos frecuencia.

Si incluye código limpio y tiempo de refactorización en sus estimaciones, también tendrá el cronograma para mantener ordenado el código base. Si, debido a la presión del cronograma, no obtiene el tiempo necesario, sus estimaciones futuras deberían aumentar como resultado de lidiar con la deuda técnica incurrida.

En algún momento, sus estimaciones futuras (o las incertidumbres que rodean sus estimaciones) le darán influencia para abogar por una reescritura (cuando su gerente le ruega que acelere el proceso). De lo contrario, acepte que la empresa aceptó su estimación y preferiría pagar el costo actual en lugar de un reemplazo. Eso es puramente una decisión comercial, no técnica.

Recuerde, el momento de negociar los horarios es antes de que haya escrito el código, no después. Después de que el código está escrito (y "funciona"), los clientes, gerentes y ejecutivos no quieren ver otra factura por "mantenimiento" que se acerque o exceda el costo original. Si te sientes tan firmemente como crees que debería ser el negocio, no dudes en reescribirlo en tu propio tiempo, eso es lo que le estás pidiendo al negocio que haga.

Desde el punto de vista de su gerente, darle un horario para reescribir pone su trasero en juego. Cuando no puede entregar o aumentar la productividad tanto como usted dice, entonces él es el que queda sosteniendo la bolsa. En comparación con el inconveniente relativamente menor de escuchar quejarse, adivine cuál preferirá.

Si ese es el tipo de trabajo que puede obtener, solo concéntrese en escribir un código mejor cada vez, en lugar de volver y reescribir el código antiguo. Todavía hay un rango de calidad en el que puede moverse dentro del ámbito de pegar paquetes de terceros.

Si tiene tiempo y desea mejorar el código de un componente existente que mantiene, ¿no puede hacerlo sin pedir permiso, siempre que lo que haga funcione? Factorice el tiempo en sus estimaciones para el próximo proyecto que use el componente.

Para la programación de nivel inferior, si no puede obtener la satisfacción del aprendizaje de su trabajo, ¿tal vez es hora de mirar un proyecto de código abierto?

q303, encontré su pregunta interesante y sentí que podría encontrar esta pregunta de los Programadores que valía la pena leer, sobre cómo convencer a los gerentes para que permitan a los desarrolladores abordar la deuda técnica.

Creo que, en general, sí, es la norma. Comprenda que el software que funciona pero no es óptimo es mucho mejor que el que no funciona. También existe el argumento de que la definición de "trabajo" podría variar según la percepción y los prejuicios de cada individuo. Cuando implementa un nuevo sistema, siempre hay alguien que dirá que sintió que el sistema anterior era mejor. Y cuando hablas con un desarrollador, es probable que él o ella se muestre reacio a admitir haber trabajado en un software malo.