Ir al contenido principal

Reflexiones con Pareto

Nada como temprano en la mañana con 10 estudiantes para aprovechar de hacer algunas reflexiones. Hoy quiero compartir una que andaba rondando mi cabeza hace algunos años ya... y al final con los estudiantes salio algo en concreto. Para todo efecto, programador principiante y estudiante se utilizan para indicar lo mismo en este texto.

Contexto

Los estudiantes presentaron un práctico de programación relativamente complejo implementando el algoritmo de Dijkstra para encontrar el camino entre dos nodos de un grafo. El ambiente era, por supuesto, de caras largas, desvelados y con algo de frustración en lo poco de impulso que les quedaba. Todo esto a pesar de haber tenido varios días feriados y suficiente tiempo para preparar esto.

Entiendo que es algo que un estudiante hace e hizo desde siempre... en toda latitud, pero con ligeros cambios (ya lo veremos)

Pareto

Luego de la revisión comenzamos leyendo lo que indica este principio en wikipedia:

Así por ejemplo cuando hablamos de los costes de desarrollo podríamos decir que "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 sólo un 20% del esfuerzo"

Acompañado por el siguiente diagrama en la pizarra:

con los comentarios

  1. Si en 10 días se hace algo, en los primeros 2 tenemos 80% del código.
  2. Qué se hace en los otros 8?
  3. Ah... en los primeros 8 leemos y entendemos y en los últimos dos se codea todo.

Vamos por partes. La primera oración es un buen punto de partida. Cuando ya se han hecho algunos sistemas, no le queda a uno otra que sentar la cabeza y aceptar lo indiscutible. Se sabe y está recontra probado que el 80% del esfuerzo sirve para dejar al sistema sin errores y listo para ser llevado al cliente... lo cual responde a nuestra segunda pregunta.

La tercera es más interesante en el sentido que refleja la percepcion de sistema desde el punto de vista de un desarrollador principiante conformista.

El conformista

En un ambiente poco tecnológico como es el ambiente académico en Bolivia, existen pocas chances que los programadores principiantes se empapen de buenas prácticas a nivel internacional, de ahí el contagio de una percepción errónea de un sistema. Luego de varios años de docencia, aquí planteo la visión del conformista recabada de la percepción de programadores de 19, 20 y 21 años (alrededor de 100 personas) durante los últimos 5 años:

Así, para el conformista, el 100% del sistema significa el terminarlo hasta cuando funciona para el caso más trivial donde todo va bien. Esto se traduce a una típica ausencia de: manejo de errores, testeo, control de calidad, funcionalidad avanzada, y otros. Además, siendo esa la percepción, nuestro individuo además dice: "Mmmhh... con 90% que haga ya la rompí". Lastimosamente, como se ve en la figura, ese 90% en realidad se transforma en un 72% muy mediocre (regla de tres simple) que es el que percibe el cliente. /p>

Para liquidar a la tercera premisa, algunos estudiantes me preguntaron: qué es de esos 8 días donde se lee y entiende el problema para hacerlo? La respuesta es trivial, esos días están simplemente fuera del gráfico y se encuentran ANTES de realizar el esfuerzo :-)

Al principio hice una alusión a estudiantes en todas las latitudes. La diferencia está en cómo percibe el estudiante ese 100%. Es por ello que puse la palabra conformista. El conformismo NO es cierto en todas las latitudes y, por supuesto, en aquellos lugares de mayor renombre la percepción del 100% está mucho más cerca de la realidad.

... y la solución?

Hasta aquí el ejercicio sirve para reflexionar, pero cómo encontramos soluciones para esto? No es un problema sencillo, implica inculcar en las personas la percepción del cliente (mínimamente) y es más, en lo posible pensar en un 120% total donde el 20% extra es lo que ofrecemos al cliente como valor agregado.

Un ejercicio muy pequeño, pero que me ha dado algunos resultados es stackoverflow. Si, desde el momento que los estudiantes comienzan a crear su reputación; pueden ver cómo sus respuestas son editadas, comentadas y van aprendiendo la manera en que el resto de las personas espera una respuesta. De a poco, sus respuestas son más completas y mejor estructuradas. Como todo lo bueno sin embargo, tarda. Y no estoy loco para pensar que los estudiantes aplican esto de la noche a la mañana... son procesos, pero estoy apostando a un pequeño cambio que puede ser monitoreado para medir su impacto; lo cual nos (me) deja en un lugar sustancialmente mejor que hace algunos años cuando comencé (me la inculcaron) estas reflexiones.

Comentarios

Entradas más populares de este blog

Protocolos, qué son?

 En el pasado (y en el presente también) siempre he querido incluir en el contenido de la materia de estructura de datos la posibilidad de hacer un práctico que tenga que ver con redes. Este breve artículo trata de cómo se pueden conectar dos computadoras en red y de las bases por las cuales tenemos protocolos. Veremos: Significado de las direcciones IP y conceptos muy básicos de redes Cómo usar sockets para abrir canales de comnicación entre dos computadoras Concepto de un protocolo y de cómo podemos usar uno para hacer un chat básico Conceptos básicos de redes Si eres de sistemas o te interesan las computadoras pues probablemnte el concepto de conectar dos computadoras en la red parece algo tan sencillo como respirar. Sin embargo, hasta mediados de los 90 era algo que: 1) era complejo; 2) tenía atisbos de magia negra. Por suerte con el tiempo esto se ha ido masificando y ahora es algo muy sencillo. Para poder conectarnos con otra computadora debemos conocer la dirección y el puerto d

Nuget muy grande en tu carpeta personal

Problema : Veo que mi disco duro C ha crecido bastante y necesito espacio. Cuando veo que una carpeta .nuget dentro de mi cuenta de usuario tiene 15 GB. Solución : Esa carpeta existe como cache para que VS no busque el paquete cada vez desde la web. Entonces, la solución consiste en los siguientes pasos. Listar cuales son los folders o contenedores de estos paquetes nuget dotnet nuget locals all --list http-cache: <USER>\AppData\Local\NuGet\v3-cache global-packages: <USER>\.nuget\packages\ temp: <USER>\AppData\Local\Temp\NuGetScratch plugins-cache: <USER>\AppData\Local\NuGet\plugins-cache Limpiar las direcciones que tienen estos paquetes nuget con el utilitario de nuget dotnet nuget locals http-cache --clear Clearing NuGet HTTP cache: C:\Users\Vladimir\AppData\Local\NuGet\v3-cache Local resources cleared. y así para cada uno de los locals que se ve en la lista anterior. Luego se debe cambiar las variables de entorno para que esto no nos vuelva a pasar. Como se

Hangfire, si no lo estás usando, estás haciendo algo mal (.NET world)

Hangfire es una librería espectacular que permite encolar tareas en un servidor de tareas que funciona dentro de tu aplicación web. Existen varios tutoriales que muestran de manera bastante sencilla cómo puedes ir integrando esto a tu aplicación. En esta publicación vamos a repetir, pero en español, y sobretodo vamos a tratar de ir lo más al punto posible. Qué es? Es una librería que la cargas a través de NUGET como cualquier otra librería. En realidad tenemos que cargar 3 librerías pero eso lo veremos más adelante. Una vez que hayas cargado todo lo necesario en tu aplicación web tendrás lo siguiente: Un servidor de colas : es decir, un lugar al cual le puedes mandar hacer cosas y no se olvida de esas cosas y las va ejecutando a medida que puede o tiene tiempo. Esto es muy útil para que tu aplicación no pierda tiempo haciendo algo que no necesita realmente hacer en ese instante y devolver más rápido al usuario final. Un tablero de control de colas : una serie de