¿Los desarrolladores de software que ignoran los estándares de calidad son mejores para la empresa? [cerrado]

¿Los desarrolladores de software que optan por no priorizar la optimización del código, los estándares y las mejores prácticas, crean códigos más útiles que aquellos desarrolladores que desean preocuparse por la optimización, la implementación de estándares y prácticas de codificación antes de completar las tareas a tiempo?

¿Cómo se comparan estas metodologías diferentes cuando se trata de revisiones de desempeño individuales?

¿Cómo se comparan estos estilos en las evaluaciones por pares?

¿Cuál es la mejor manera de influir en su equipo para implementar más prácticas recomendadas durante el SDLC?

No, solo recibirán el respeto del propietario del proyecto en este momento.

Serán destrozados durante años por:

• futuros mantenedores,
• probadores futuros,
• futuros propietarios de proyectos,
• futuros gerentes,
• y prácticamente cualquier persona involucrada con la base de código en el futuro.

Incluso podrían recibir el mismo tratamiento de:

• los probadores actuales,
• Los escritores de documentación técnica actuales.

Falsa dicotomía: las cualidades son ortogonales.

                Alta calidad baja calidad

Rentable INCREÍBLE Sketchy

Iffy no rentable FUEGO PRIMERO

No. Las mejores prácticas son las mejores porque, por definición , ayudan a que los proyectos se realicen más correctamente, en menos tiempo, con una modificación más rápida en el futuro, por lo que ignorarlos garantizará una disminución de las ganancias. Por supuesto, sus gerentes pueden prescribir prácticas que creen que son las mejores, pero en realidad no lo son, o pueden juzgar mal lo que los clientes pagarán y lo que no, entonces todas las apuestas están canceladas.

Los estándares de codificación son más complicados; Es posible prescribir demasiados detalles a sus codificadores, lo que conduce a una disminución de la eficiencia. Pero con la experiencia se vuelve bastante fácil distinguir pautas útiles de la microgestión anal-retentiva, por lo que se aplica lo mismo: las mejores prácticas reales siempre valen la pena, las pseudo-mejores prácticas generalmente no.

Por lo general, no vale la pena optimizar el código a menos que haya medido cuáles son sus cuellos de botella, haya confirmado que es necesario hacer una optimización y haya medido que su truco inteligente realmente cumple con los requisitos de rendimiento. De lo contrario (que es principalmente) no vale la pena hacerlo, y por lo tanto no es óptimo.

¿Estoy de acuerdo con los desarrolladores que no se preocupan por la optimización del código y las prácticas? No.

¿Hacen el trabajo que necesitan hacer? Si.

Un negocio consiste en ganar dinero, y la única forma de ganar dinero es lanzar productos. Esto generalmente significa que los proyectos tienen horarios estrictos, lo que significa que la mejor manera de hacer algo puede no ser la forma más rápida de hacer algo.

Si bien no estoy de acuerdo con este estilo de desarrollo, la compañía puede considerarlo respetable si se lanzan productos.

No, y encontraría la ruta más rápida lejos de dicha compañía que aprecia esos vicios.

Sí y no, lo cual es un poco flojo pero es una mejor práctica y no una práctica perfecta. Idealmente, debe seguirlos constantemente, pero siempre habrá una situación en la que la empresa quiera poner sus necesidades antes que sus productos.

Los mantenedores lo odiarán pero su jefe lo amará.

Las mejores prácticas son algo así como el sentido común, todos están de acuerdo en que todos deberían saberlo hasta que dos personas comiencen a discutirlo en detalle. No hay dos personas completamente de acuerdo con la definición y no existe una fuente lógica de verdad que se aplique a todas las situaciones.

¿Estás escribiendo el sistema de guía para un satélite espacial (probablemente no lo estés)? Entonces el infierno Ningún código de mala calidad / rendimiento nunca es aceptable en este tipo de trabajo.

¿Está escribiendo un sitio web desechable para un impulso de marketing único (probablemente tampoco lo esté haciendo o no hubiera hecho la pregunta, pero es más probable que el satélite)? Entonces, infierno Sí, saca ese pedazo de pelusa por la puerta por cualquier medio necesario para cumplir con la fecha límite, el próximo director de marketing probablemente hará algo más con una compañía diferente de todos modos. LO QUE HACE NO ES ARTE O CIENCIA - PAGUE.

Todo lo demás en el medio: negociable, especialmente siempre que el desarrollador esté en el gancho para el soporte inicial.

Hasta que ocurra la segunda venida de cualquier ser sagrado que prefiera y defina las prácticas de desarrollo de manera milagrosa, habrá un amplio espacio para el debate sobre cualquier proyecto que no sea directamente responsable de las decisiones de vida o muerte que no sean tan insignificante para ser desechable.

Todo lo que está fuera de las mejores prácticas etiquetadas como críticas para la vida suele ser más como la política de la empresa, las especificaciones del cliente o la opinión personal. Muchos de ellos son opiniones personales en las que muchas personas están de acuerdo actualmente, pero eso no lo convierte en una guía inmutable para todas las situaciones.

La cantidad de dinero que ganan para la empresa es discutible. Si hay un nivel de revisión del código en cuestión, los costos de mantenimiento aumentarán y alguien no estará contento. Los altos costos de mantenimiento a largo plazo son más caros que hacerlo correctamente por adelantado.

El respeto que reciben probablemente sea específico de cada caso. En algún momento, sin embargo, alguien lo notará.

No preocuparse por estas cosas puede hacer que la empresa gane más dinero a corto plazo, pero podría costarle más dinero a largo plazo en más correcciones de errores y codificación de mantenimiento.

A veces, puede ser necesario un trabajo rápido y sucio si hay apuro con las empresas competidoras para llevar productos similares al mercado al mismo tiempo, pero los costos futuros de tales acciones deben considerarse cuidadosamente.

Todo depende del cliente.

A un cliente que le gusta rápido y sucio (y generalmente más barato) no le importa que presente problemas en el futuro.

Piense en la construcción del gabinete.

Algunos pagarán y apreciarán los gabinetes hechos a medida de buena calidad. No les importa el gasto adicional de los cajones de madera y el hardware de primera clase. No les importa que tomará una semana extra o incluso un mes construir e instalar las cosas.

Muchos no lo harán. Muchos optarán por las cosas baratas producidas en masa de tableros de partículas que obtienes de una gran tienda de cajas. Los quieren instalados en 2 días. Un pequeño espacio aquí y allá es perfectamente aceptable. No les importa que se derrumben en 10 años.

Entonces, si sus gerentes elogian al desarrollador que lo hace rápido y sucio, entonces sus clientes no quieren una alta calidad o los gerentes les mienten.

Sólo el tiempo dirá. Haga lo que los gerentes quieran o encuentre otro trabajo.

No nunca. OMI optimización de código, las mejores prácticas, reales artesanía son los MÁS cosa importante a tener en una base de código; sin ella, todo se convierte en lodo y se mantiene unido con cinta adhesiva. Es un diseño insostenible. Es como ignorar un tumor porque es pequeño y ahora estás sano; seguro que está sano ahora, pero unos años más tarde se convierte en terminal porque lo ignoró durante tanto tiempo.

No solo no estoy de acuerdo con los desarrolladores que no se preocupan por estas cosas, sino que no tengo ningún respeto por ellos. Una manera infalible de hacerme considerar dejar una organización, no importa cuánto tiempo haya estado allí, es estar rodeado de un equipo en el que soy la única persona (si no la única persona en toda la empresa) que se preocupa sobre conceptos de ingeniería de software adecuados.

Una buena lectura: http://www.joelonsoftware.com/items/2009/09/23.html

Pero en mi humilde opinión, las mejores prácticas de un hombre es la pesadilla de otro hombre. Y cada base de código no trivial será una pesadilla para un extraño.

Lo que sea que pienses, no seas idiota al respecto.

EDITAR: No estoy defendiendo ninguna de las posiciones, dependiendo de la tarea en la que me pueda inclinar hacia cualquier lado.

¿Mejor para la empresa? Depende.

Para una startup con fondos limitados, hágalo y póngalo a la venta, no importa si es desordenado, eso se puede solucionar más tarde cuando haya más recursos.

Para un producto maduro donde hay muchos usuarios que confían en la calidad del software, todo debe hacerse "correctamente".

¿Mejor para el desarrollador individual? En realidad es irrelevante. Simplemente haga lo mismo que hacen sus colegas y deje que la gerencia se ocupe de las consecuencias: ese no es su trabajo. Si está arreglando la basura de otras personas todo el tiempo, SERÁ visto como lento, y usted será el que aún esté allí mientras los demás han sido promovidos por encima de usted. Siga con el programa o salga mientras pueda si es tan malo.

Depende del desarrollador y del proyecto / situación.

Tiempos extraordinarios requieren medidas extraordinarias.

Entonces, si necesito que me entreguen algo ahora, y alguien está sobre-diseñando una aplicación Java de grado empresarial que aprovecha no menos de 14 de los últimos marcos de palabras de moda, mientras que un simple script de Python hará el trabajo es peor que el desarrollador que corta las esquinas y piensa código defectuoso lo hará en tiempos normales.

Parte de ser desarrollador es ser flexible. No deberías ser esclavo de tus herramientas y seguir ciegamente las prácticas; siempre habrá un caso en el que te fallarán. Saber cuándo romper y doblar las reglas es una de las cosas que vienen con mucha experiencia y son valiosas.

En su caso, si ofrece más valor que usted porque la velocidad es crítica, incluso después de tener en cuenta el mayor costo de mantenimiento en el futuro, entonces merece una mejor compensación. Por otro lado, si está atascado con la limpieza de su desorden, tiene un problema de comunicación con la administración.

Es caso por caso. Excepto el estilo de codificación, no hay excusa allí.

Lo siento, pero tendría que estar en desacuerdo con la mayoría de las respuestas a esta pregunta, excepto la principal.

El valor principal del software es que es flexible.

No creo que debas reescribir el código de otras personas sin una causa justa. Si tiene que cambiar un módulo por cualquier motivo para implementar su función, ahora, para bien o para mal, es el propietario de ese módulo. Cámbialo, reescribe algo, reescribe todo.

Nunca produzca baja calidad en términos de flexibilidad. No hay tal cosa como tirar nada en el software. Si el cliente dice que es temporal y que no lo necesitará después de una fecha determinada, y no le importa la calidad, diga "mal" o escriba por escrito que el código no será alterado por usted ni por ningún otro programador una vez se implementa en producción, o tiene derecho a demandarlos.

La suposición más pobre que veo en algunas de estas respuestas es que algún código limpio de alguna manera reduce la velocidad de desarrollo. Para cualquier proyecto de cualquier sustancia (más de 6 horas de trabajo), el código limpio acelera el desarrollo a largo plazo (cualquier cosa mayor a una semana). Lo he visto una y otra vez.

El código de mala calidad es irrespetuoso con la profesión y sus compañeros de trabajo. Perdón pero cierto.

¡Así que no a la mala calidad, en términos de flexibilidad, nunca!