1 / 14
jul. 2017

Para mi lo mas imprescindible es que sea fácil de mantener aunque la persona que lo desarrolló ya no esté en la empresa.

Para mi es un software que es útil a sus usuarios. Parece muy evidente, pero si lo piensas bien, no es tan simple. En mi opinión, cualquier otra métrica o consideración de calidad, debería ser secundaria.

Estoy intentando pensar en algún software que sea útil y pueda permitirse ser una basura por dentro. Solo se me ocurre software que no cambie con el tiempo y no sé si existe. ¿Un videojuego? Quizás los antiguos sí pero los actuales con los DLC, updates, series, motores,...

Minecraft xD

Las primeras versiones desarrolladas por el creador (Notch) eran un caos y un despropósito.

La fuerza de trabajo de la compañía a posteriori fue 50% añadir funcionalidad y 50% refactorizar el caos que había.

Pues yo creo que hay millones de ejemplos de SW que es útil y es una basura por dentro, pero lo que pasa es que no lo sabemos. Cuando estaba en Indra la gente utilizaba nuestro SW, pero ya te digo que era una castaña tremenda. En el cliente que estoy ahora, el código es muy mejorable.

Dicho esto, larga vida al Legacy Software útil. Como dice Kent Beck: make it work, make it right. make it fast. Lo que pasa es que hay gente que se queda en el primer paso :smiley:

Bertrand Meyer en el libro 'Construcción de software orientado a objetos', indica dos puntos de vista respecto de la calidad de un un software: calidad interna y calidad externa. Él se refiere a que lo más importante es la calidad externa, la que da el valor al usuario, ya que si esta no es buena, de nada sirve que la calidad interna sea alta (Muy resumido).

La calidad interna la podríamos referir a lo bien hecho que esté el código, que sea legible, fácil de entender, que esté testeado, su nivel de modularidad...etc.

La calidad externa las resumen en varios factores de los cuales destaca principalmente cuatro:

Corrección y robustez: La corrección como propiedad del software de funcionar correctamente y la robustez relacionada con la capacidad de un sistema de software de estar preparado para un funcionamiento correcto ante las excepciones que pudieran producirse. El concepto común es fiabilidad.

Extensibilidad y reutilización: Un sistema de software es extensible si es fácil añadir modificaciones o incluir nuevas características y es reutilizable si con ese mismo sistema o partes de él, se pueden construir otros sistemas distintos.

Pues estas dos características así de primeras me suenan más a calidad interna que externa, pero entiendo la separación de Meyer. Eso sí, siguiendo sus propias definiciones, veo muy difícil "Extensibilidad y reutilización" sin "calidad interna".

Ya te digo, yo mismo he hecho (y todavía mantengo algunas) cosas superútiles que son una porquería por dentro. Vamos, y todos me imagino.

"Mucho del software hoy en día se parece a una pirámide egipcia: con millones de ladrillos apilados uno encima del otro, sin integridad estructural y hecho por pura fuerza bruta y miles de esclavos." Alan Kay

Por eso el otro día planteé el tema de que últimamente tengo dudas sobre la importancia de escribir buen código:

Otra cosa es que los programadores suden a borbotones cada vez que les toque cambiar algo. Pero si el cliente está dispuesto...

Permitidme ser un poco cínico...

Yo creo que el software basura por dentro puede estar bien si le es útil a alguien. Si esa aplicación no va a sufrir cambios, o no se van a añadir funcionalidades, probablemente para quién la usa siga siendo una maravilla sin enterarse de lo que hay por debajo.

El problema es hay pocas aplicaciones así. Al final hay que evolucionarlo, añadir cosas nuevas o corregir bugs. Y claro ahí es cuando la calidad interna se vuelve importante.

Cuando decía que lo principal es que sea útil a sus usuarios, me refería que esa debería ser la medida principal para medir la calidad del software. Un software que por dentro esté escrito como si lo hubiera hecho el mismo Uncle Bob pero que no cumple las expectativas de sus usuarios no es un software de calidad, lo mires por dónde lo mires.

Ahora bien, en general, las expectativas de uso de la gente hoy en día incluyen cosas como que el software no falle, evolucione con el tiempo para ser más útil, sea agradable de usar, comprensible, etc.. todos estos aspectos deberían ser la guía principal para cualquier otra consideración sobre la calidad del software.

A mi, personalmente, me parece realmente extraño hablar de la calidad de un instrumento (el software) y no poner su usabilidad y al usuario en el centro absoluto de este tema. A veces nos olvidamos que el software no es para los desarrolladores.

Al menos, esta es mi opinión.

A todo esto... qué entendemos por útil? Quiero decir, si negocio pide evolucionar el software para adaptarlo a sus necesidades y resulta que cambiarlo cuesta un tiempo enorme... eso es útil? Para quien? Para nosotros los programadores o para negocio? Si no puede adaptarse rápidamente a sus necesidades, útil, útil... lo que se dice útil... pues va a ser que no.
Parafraseando a Uncle Bob, "si no es adaptable, está roto" :wink:

Si negocio pide evolucionarlo es que no es suficientemente útil tal y como está ahora, no? Pues bien, todo el tiempo que los usuarios esperan que el cambio que se necesita esté disponible es un tiempo durante el cual el software no cumple bien las expectativas de uso y, por tanto, es de peor calidad.

Si este tiempo es largo, la falta de calidad es más perniciosa y puede irse incrementando sin fin con el paso del tiempo. Así que, claro, el software ha de poder evolucionar rápido. Pero para que esto sea una medida de calidad, además ha de hacerlo en la dirección correcta. Centrándose en lo importante que es la expectativa de uso de los usuarios finales.

De hecho, en mi opinión, si se piensa profundamente, todas las otras métricas (acoplamiento, complejidad ciclomática, complejidad accidental, cobertura de test unitarios, etc...) son importantes precisamente porque nos pueden ayudar a hacer software con un menor time to market, pero solamente si incluimos al usuario final en la ecuación, podremos aprovechar esto en la dirección correcta.

Dicho de otro modo, si no incluimos feedback real de los usuarios, la calidad interna es una mera anécdota que sirve básicamente para satisfacer el ego de algunos programadores.

A quien le importa si está mejor programado Google o Bing? Google si hacemos caso a su share, es tremendamente más útil, va mejor. Va a ser que alomejor es de más calidad.... ?

Pienso que un software de calidad debe tener dos perspectivas muy presente: ofrecer un producto útil, valioso al negocio. Por útil y valioso al negocio me refiero a que el software debe realizar bien los procesos de negocio que intenta abarcar. La segunda perspectiva a tener en cuenta es la realidad que los requerimientos cambian todo el tiempo por tanto el software debe ser fácil de dar mantenimiento. Con esas dos perspectivas tenemos mucho camino por recorrer.