El Principio de Pareto: la Regla del 80/20

¿Qué es el Principio de Pareto, cuáles son sus implicaciones y cómo puede ayudarnos a mejorar nuestro quehacer como programadores? Te invito a leer con paciencia este post. Estoy seguro que te será muy útil y valioso en tu proceso de aprendizaje y/o en tu trabajo como desarrollador de software.

“El principio de Pareto (también conocido como la regla 80/20...) establece que, para muchos eventos, aproximadamente el 80% de los efectos provienen del 20% de las causas”...

En ingeniería del software se aplica cuando hablamos de los costes de desarrollo donde «el 80% del esfuerzo de desarrollo (en tiempo y recursos) produce el 20% del código, mientras que el 80% restante es producido con tan solo un 20% del esfuerzo». Si hablamos de pruebas de software, el principio nos dice que «el 80% de los fallos de un software es generado por un 20% del código de dicho software, mientras que el otro 80% genera tan solo un 20% de los fallos»...

Wikipedia

Como explicación del texto anterior y para no redundar, listo los puntos 2 al 7 del post Cambie su vida como programador con la regla 80/20, de Diego Pacheco, que son aplicaciones colaterales muy acertadas de esta regla al desarrollo de software:

2. Al elegir funciones La mayoría de sus usuarios solo utilizarán el 20% de las funciones que les proporcione. Como tal, debe poner el 80% de sus esfuerzos en estas funciones y convertirlas en sus funciones principales. 3. Al ordenar una lista de tareas pendientes Como programadores, todos creamos listas de tareas pendientes para terminar nuestras tareas. En la mayoría de los casos, el 20% de su lista de tareas pendientes le tomará el 80% de su tiempo. Por lo tanto, ordenar su lista de tareas puede ayudarlo a terminar más tareas más rápido o terminar la parte más importante primero. Ordenar su lista de tareas pendientes de acuerdo con esta regla lo ayudará a mantenerse motivado por más tiempo y a saber cuánto tiempo llevará completar su lista de tareas. 4. Al iniciar un proyecto El 80% del tiempo dedicado a un proyecto de codificación debe dedicarse al primer 20% de su inicio. La lluvia de ideas sobre la idea, la creación de la estructura de codificación y la planificación ayudarán a que el proyecto avance más rápido y más fácilmente. Entonces, antes de intentar codificar todo, asegúrese de invertir suficiente esfuerzo en el primer 20% de su proyecto. 5. Al aprender algo nuevo Solo necesitas aprender el 20% de algo para comenzar a usarlo. Digamos que quiere aprender Java. Elegir el 20% adecuado para aprender de él lo ayudará a obtenerlo más rápido (es decir, aprender sobre el principio orientado a objetos, la sintaxis, etc.). Una vez que haya terminado con estos principios, puede comenzar a codificar con confianza, ¡aunque aún no conozca el 80% de Java! 6. Al depurar La depuración puede llevar horas de su tiempo de codificación. Muchos desarrolladores dicen que el 80% de sus errores están en el 20% del código. Por lo tanto, es inteligente invertir más tiempo en la depuración de un parche de código cuando descubre un error porque puede haber más errores en el mismo fragmento de código. 7. Al elegir una idea Si es un desarrollador, es posible que obtenga cientos de ideas para una nueva aplicación. Por lo tanto, saber que el 20% de sus ideas valen la pena y que funcionarán podría ayudarlo a elegir qué idea es mejor implementar...

En esa misma línea, Carlos González en su post Principio de Pareto (Ley del 80/20), cuenta que en sus días como autónomo descubrió que el 80% de sus beneficios provenían del 20% de sus clientes. Esta es otra aplicación de la regla. Dice además:

En el tema del software, podemos pensar en centrarnos en el 20% de las características clave de tu software. Invertir el tiempo en ir a las partes más importantes de la aplicación, aquí es donde podemos usar la definición de nuestro amigo Pareto. El 80% del trabajo de las personas que usan tu software se desarrolla con sólo el 20% del código. Centra tu energía en lo que de verdad importa. En muchas ocasiones intentamos hacer un diseño perfecto en todos los ámbitos y nos dejamos mucho tiempo en cosas en las que el usuario no va a fijarse...

Por último, reproduzco parte del contenido del post El principio de Pareto:

Parece una afirmación peregrina, y evidentemente los porcentajes no son exactos, sino que sólo pretenden ser una mera aproximación. Sin embargo, al evaluar cualquier proyecto que conozcas o en el que hayas trabajado, imagina cual sería el coste y el beneficio de hacer sólo las partes más sencillas de la aplicación: obviar los casos complicados, no hacer un sistema de control de errores sofisticado, no validar las entradas de los usuarios y no preocuparse por si una de cada 10 veces la aplicación puede fallar. Así, ciertamente, se puede hacer una aplicación que parece funcionar, digamos un 80% del tiempo, y con un esfuerzo mucho inferior al que costaría desarrollar una aplicación completa. Otras aplicaciones interesantes del Principio de Pareto a la ingeniería del software podrían ser: Testar el 20% del código sirve para eliminar el 80% de los bugs. El 80% del tiempo una aplicación sólo ejecuta un 20% del código y utiliza un 20% del conjunto de datos. Por eso mismo, optimizar el 20% del código o cachear el 20% de los datos puede dar lugar a un 80% de mejora del rendimiento. Este principio también explica por qué las aplicaciones que parecen casi terminadas suelen demorarse al final del proyecto, cuando sólo falta por resolver la infinidad de cabos sueltos que siempre se dejan para el final: lo que más cuesta en una aplicación no es construir el esqueleto, sino pulir los detalles. Pero el principio de Pareto sirve especialmente para minimizar el riesgo que se corre al desarrollar una aplicación y se utiliza sobre todo en las metodologías ágiles de desarrollo de software. Según esta escuela de la ingeniería del software, es muy importante que los desarrolladores tengan cuanto antes feedback de cómo funciona el producto que están desarrollando y si satisface, o no, las necesidades del cliente. Si desarrollamos primero las partes más complicadas de un producto, sin tener nada que enseñar hasta que todas las piezas estén completas, y esperamos hasta el último momento para desplegarlo y enseñárselo al cliente, nos podemos encontrar con la situación, tan común como desagradable, de que el producto cumple los requisitos funcionales que pidió el cliente, pero no es exactamente lo que el cliente necesita. No obstante, esto no lo saben ni el cliente ni los desarrolladores hasta que ven el software funcionando e intentan probarlo. El cliente acaba insatisfecho con el software que ha comprado y el desarrollador se siente frustrado porque ha trabajo duro para cumplir todos los requisitos funcionales pero el cliente no parece apreciar el software que tanto trabajo le ha costado construir. En cambio, si desarrollamos primero las partes más útiles del sistema, con un 20% del esfuerzo ya se puede ver si el diseño está bien hecho y si la aplicación es realmente lo que el cliente necesita. Si hay que hacer cambios en el diseño o en los requisitos, cuanto antes se definan esos cambios más útiles serán y menos costará implementarlos. El principio de Pareto no es una ley matemática exacta y no puede utilizarse como dogma, sino más bien como una regla del sentido común, pero aplicado con moderación puede servir para planificar correctamente un proyecto y evitar el riesgo de malgastar recursos en esfuerzos inútiles. Como escriben Kent Beck y Martin Fowler en (el libro) Planning Extreme Programming: "Los programadores de software están acostumbrados a tratar con la regla del 20-80 -el 80% de los beneficios provienen del 20% del trabajo. La programación XP hace uso de está regla -pon el 20% más valioso de la funcionalidad en producción, haz el 20% más valioso del diseño, confía en la regla del 20-80 para postergar la optimización."

Como ves, las aplicaciones posibles del Principio de Pareto son simples pero muy lógicas y poderosas. Teniéndola en mente, podremos optimizar nuestro trabajo como programador con una base psicológica y matemática demostrada.

Para finalizar, te dejo el vídeo Principio de PARETO (Regla del 80/20) - Explicado para principiantes!, en el que aprenderás que esta regla se aplica a muchos ámbitos de la actividad humana:

Espero que estos recursos te ayuden mucho en tu formación y crecimiento como programador como me ha ayudado a mí. Si sabes de otros temas que valga la pena incluir en este blog, házmelo saber. No olvides dejar tu comentario y compartir el post con quienes consideres que pueda serle útil. Si encuentras algún link roto o vídeo que no aparece, por favor avísame para corregirlo.