Lo importante en la creación de software: la calidad del código o el resultado final del producto.

Tendría cuidado con frases como ‘calidad de código’. Creo que se refiere a la calidad en general, no a la corrección del código. En software es difícil saber cuándo se compromete la calidad. Por lo tanto, la mejor opción es hacer lo mejor que pueda para crear un producto de alta calidad. Cuando hace compromisos para sacar el producto, debe conocer las implicaciones. Por ejemplo, la característica X no es utilizada por muchos clientes, podemos retrasar las mejoras. Nunca escribes código descuidado para sacar el producto.

Para preguntas relacionadas con la calidad del software, eche un vistazo a las publicaciones de mi blog como avance de las pruebas:
La prueba del software no es “¿Funciona?” por Nilanjan Bhattacharya en Contrafactuals
¿Qué es la automatización de pruebas de software? por Nilanjan Bhattacharya en Contrafactuals

Es una falsa dicotomía. No puede lograr el resultado final del producto sin lograr una cierta calidad de código.

Además, realmente no existe un “resultado final” para el software que se utiliza: debe evolucionar con el tiempo a medida que el mundo cambia. Ampliar la funcionalidad del software para cumplir con los nuevos requisitos es parte del “resultado final”.

Al mismo tiempo, no puedes saber cuál será el futuro. Entonces trazas una línea y dices que esto es con lo que vamos a lanzar, y aceptas acumular una cierta cantidad de deuda técnica para poder lanzar a tiempo con el conjunto de características correcto.

Es una gran decisión. Supongamos que está diseñando un nuevo producto radical que el mundo realmente no ha visto antes. No se puede saber, en el primer año, cuáles serán las características que la gente realmente utilizará. La única forma de averiguarlo es lanzar el producto y ver. En cada paso de la forma en que está acumulando deuda técnica, pero no sabe qué deuda tendrá que pagar, con qué deuda podrá vivir indefinidamente y qué deuda está en un componente que usted ‘ solo terminaré tirando de todos modos.

No escribes código de mierda sin pruebas, porque no eres un animal. Es importante que su código haga lo que cree que hace, y que otras personas puedan leerlo. Esa es solo una línea de base sobre cómo no fallar.

Pero todo lo demás más allá de eso es una suposición. Parte del objetivo de lanzar productos temprano es pasar de “adivinar” a “adivinar educado” lo más rápido posible.

resultado final del producto, porque eso le dará dinero siempre que el cliente esté contento, pero será un infierno tratar de mantener este producto o incluso expandirlo, básicamente la calidad del código es ayudarlo a usted y a otros desarrolladores a comprarle tiempo y ahorrándote esfuerzo.

Eso depende de quién posee el producto. Algunos lugares se saltan con una codificación realmente horrible pero con resultados suficientemente satisfactorios: me encuentro con su fuente (o detalles de su modus operandi) con bastante frecuencia y me avergüenzo de cuán mal e ineficientemente fueron escritos … pero ahí están, en uso.

Otros lugares insisten en un código de alta calidad y de fácil mantenimiento, en primer lugar. Estos lugares tienden a tener la intención de estar cerca por mucho tiempo, y su reputación brilla por ello. Este es el gran momento.

El dinero lo gobierna todo.
Le pagan por (1) los resultados entregados o por (2) el soporte de ese resultado entregado.
De cualquier manera, el resultado es lo más importante. Las empresas que entregan y olvidan no se preocupan por la calidad. No solo el código fuente, sino también el producto en sí.
Cuando le pagan por el soporte de su producto, los requisitos cambian. La empresa trabaja en el mismo código fuente durante años. El resultado sigue siendo lo más importante, pero la calidad del código alcanza prioridades similares.

Construir un software es tan parecido como construir un negocio. ¿Es importante lo bueno? Sí lo es. Pero también es importante cómo vender los productos.
Construir un software es tan parecido como dirigir una empresa. El resultado final es importante, al igual que la ganancia, es lo más importante para una empresa. Por otro lado, la gestión de la empresa también es importante. Es la buena gestión lo que respalda la rentabilidad a largo plazo de una empresa.

Desde la perspectiva del negocio, casi siempre es el resultado final. A los clientes no les importa lo elegante que es el código, solo lo útil que es. Y aunque el mantra es que necesitamos escribir código mantenible porque es la parte más larga del ciclo del software, la realidad es que no todo el software se mantiene. O la compañía está dispuesta a lidiar con el código de producción deficiente haciendo que el mantenimiento sea realmente lento.

El tipo de software también hace una diferencia en esta discusión. Mira los videojuegos para un jugador, por ejemplo. Hay poco o ningún mantenimiento en ellos. Ahora mira los MMO. Estos están constantemente en desarrollo y constantemente siendo parcheados. Supongo que los MMO se encuentran en el medio del espectro. Necesitan llegar al mercado, pero también necesitan mantenerse. Pero si un parche tarda un poco más debido a un código malo, nadie muere, por lo que no tiene que ser un código súper impresionante.

Pero, ¿qué tal si está creando un nuevo software a partir de otros códigos (software) deficientes? ¿Eso es considerado? Saber que los dos programas no son lo mismo