Desde el punto de vista gerencial hay 3 factores clave a medir en los proyectos de desarrollo de software:
- Que sea confiable, es decir que haga lo que tiene que hacer en el momento que tiene que hacerlo, esto incluye que el software funcione correctamente según las especificaciones y otros atributos de calidad como el desempeño, la escalabilidad y la disponibilidad.
- Que sea costo eficiente a nivel de infraestructura, es decir que use la mínima cantidad de hardware para ejecutar la mayor cantidad de operaciones.
- Que los desarrolladores mantengan su nivel de eficiencia en el tiempo, es decir que a futuro no cueste más desarrollar ciertas funcionalidades a causa de problemas de diseño.
Para empezar definamos eficiencia. Según wikipedia la eficiencia es la relación entre los logros conseguidos con un proyecto y los recursos utilizados en el mismo. Se entiende que la eficiencia se da cuando se utilizan menos recursos para lograr un mismo objetivo. O al contrario, cuando se logran más objetivos con los mismos o menos recursos.
Cuando hablamos de eficiencia en el contexto del desarrollo de software nos enfocamos en la capacidad de construir una mayor cantidad de funcionalidades con menos esfuerzo o mínimamente mantener el nivel productividad en el tiempo, es decir que los desarrolladores no pierdan velocidad conforme el software va creciendo y se va haciendo más complejo.
Para nadie es un secreto que la complejidad del software aumenta de manera exponencial en el tiempo conforme éste crece en funcionalidades y por ende en líneas de código, y cuando se tienen mayor complejidad se requiere mayor esfuerzo para leer y entender el código previo a la realización de un cambio, se incrementa el riesgo de dañar funcionalidades existentes y por ende toma más tiempo realizar pruebas de regresión que garanticen que el cambio no afecte otras partes del sistema.
La complejidad del software aumenta de manera exponencial en el tiempo reduciendo la eficiencia al desarrollar. Un buen diseño permite atenuar la pérdida de eficiencia.
Por esta razón se hace necesario e indispensable gestionar la complejidad del software a través de diseños que permita mantener la eficiencia para desarrollar en el tiempo. Como se ve en la imagen ,1 hacer diseño tiene un impacto negativo al inicio en la velocidad a la que se construyen nuevas funcionalidades (Línea azul) pues hacer una funcionalidad con un buen diseño requiere más esfuerzo, pero en el tiempo se pierde velocidad pues los factores ya mencionados hacen que los cambios al código construido tomen más tiempo. Por otro lado cuando hacemos un buen diseño podemos atenuar la pérdida de eficiencia (Línea roja) logrando que los desarrolladores degraden menos su velocidad en el tiempo a causa de la complejidad del software. Hablo de atenuar la pérdida de eficiencia porque aún con buenos diseños la complejidad crecerá, esto es innegable.
Hacer código con un buen diseño toma más tiempo pero permite mantener un ritmo de trabajo sostenible al desarrollar software.
¿Qué es entonces el potencial de eficiencia del código?
Cuando hablamos de potencial de eficiencia en el software debemos contemplar el presente y el futuro.
Para ser eficientes en el presente los desarrolladores deben escribir el mínimo código necesario para implementar una funcionalidad. Esto incluye el uso adecuado del lenguaje de programación, la reutilización de código, y la adopción de buenas prácticas de desarrollo.
Para ser eficientes a futuro (Y el futuro puede ser una semana después de construir el código) es necesario escribir código claro, fácil de entender por otras personas, bien estructurado de manera que no sea necesario tener mucha información en la mente para entender un bloque de código (Reduciendo la sobre carga cognitiva) y bien diseñado de modo que se reduzcan los daños colaterales al cambiar una funcionalidad existente o crear una nueva.
Juntos los factores que afectan la eficiencia en el presente y el futuro constituyen el potencial de eficiencia. Tener este indicador en un buen nivel permite reducir el costo de los cambios en el software al tener desarrolladores productivos en el presente, que no pierden velocidad a futuro a causa de la complejidad en el software.
¿Cómo calcular la métrica de potencial de eficiencia?
Existen múltiples métricas en el mundo del desarrollo de software que pueden ser utilizadas para medir los factores que afectan la eficiencia: Complejidad ciclomática, código duplicado, análisis estático de código, verificación de buenas prácticas de desarrollo, code smells, deuda técnica, cobertura de código, acoplamiento, cohesión, índice de mantenibilidad, etc. Todas ellas pueden ser medidas de manera automática con herramientas como FindBug, PMD o SonarQube. Cada una de estas herramientas generan métricas técnicas que deben ser analizadas de manera independiente para tomar decisiones.
Existen otras alternativas como Quind que interpretan las métricas técnicas generadas por las herramientas mencionadas y muestra el potencial de eficiencia como indicador gerencial que permite conocer si los equipos están construyendo el software de manera correcta sin conocer los detalles técnicos.
Seamos estratégicos a la hora de gestionar la eficiencia
No todas las aplicaciones requieren tener un potencial de eficiencia alto, pues muchas de ellas cambian poco en el tiempo, o desde el momento de sus construcción es claro que no van a crecer. Recuerden que los buenos diseños toman tiempo y para este tipo de sistemas posiblemente no se logre el retorno de la inversión al hacerlo dado que al no existir cambios en el tiempo no es posible capitalizar los beneficios de un buen diseño.
No todas las aplicaciones requieren un potencial de eficiencia alto, es importante pensar en el retorno de inversión a la hora de diseñar el software.
Lo mismo pasa con los sistemas legados. Normalmente cuando estos son analizados con herramientas como SonarQube y Quind, las métricas se encuentran en un grado de deterioro alto. Pero para las partes del sistema que cambian poco esto no debería ser un problema, pues si bien el código está deteriorado, no se genera impacto negativo en la eficiencia de los desarrolladores dado que no se cambia en el tiempo.
Conclusión
El diseño de software no es un asunto técnico, es un asunto de negocio pues impacta directamente sobre factores como el costo del desarrollo y el time to market, factores decisivos para el éxito de una organización en un mundo tan competitivo donde se requiere adaptación rápida a los cambio del mercado. Tener un potencial de eficiencia alto permite a las organizaciones ser más competitivas, reaccionar más rápidamente el cambio, reducir los tiempos de desarrollo y por ende incrementar la frecuencia de entrega de valor a sus usuarios y clientes.
El diseño de software no es un asunto técnico, es un asunto de negocio pues impacta directamente sobre factores como el costo del desarrollo y el time to market.