El principio de Pareto

Hace un par de semanas, un profesor que se dedica a enseñar el Proceso de Software Personal en la universidad, comentaba que según sus estimaciones un 10% de los programadores en un proyecto desarrollan el 90% del código del proyecto. No era la primera vez me encontraba con esta idea, similar al principio de Pareto, que parece ser bastante común en el mundo de la programación, y con la que estoy completamente de acuerdo.

Para verlo mejor, supongamos que tenemos 10 programadores, en un pequeño proyecto de 1.000 líneas de código; según esta estimación uno de los programadores se encargaría de 900 líneas del código, y las otras 100 se repartirían entre los otros 9. Quizás el porcentaje de líneas de código sea un tanto exagerado, pero podemos dar por válido que siempre suele haber un pequeño porcentaje de hackers que crean muchas mas líneas de código útiles que los demás.

Ahora bien, la cuestión es ¿cuales son los factores que lo provocan? Está claro que en primer lugar, el rendimiento de un programador depende del proyecto en sí; lo que a nosotros nos puede resultar complicado a otra persona le puede resultar muy sencillo; pero esto no nos sirve como excusa, porque el programador con mayor rendimiento suele ser siempre el mismo. Dejando a un lado las luchas gremiales que no vienen al caso, la cuestión se reduce a si es una habilidad innata, o si trabajando duro se puede llegar a estar en ese 10% de programadores de élite, y en tal caso, cómo.

Para mí es obvio que según la capacidad de cada uno costará más o menos llegar a ser bueno en lo que se hace, pero al final todo es una cuestión de trabajo. Según este profesor, PSP sirve para acercarnos a ese 10%, y puede que sea verdad, pero creo que el simple hecho de preocuparnos por saber qué es PSP y como nos puede ayudar a mejorar nuestro rendimiento nos hace mejores programadores.

Y ahora… “One, two. Do the kung foo“.

Comentarios
  1. Casualidades, llevo dos días leyendo sobre el principio del Pareto, con temas diferentes, igual te interesa este enlace: Ley del pareto en posicionamiento. Es un 20 a 80 en este caso.

    Responder

  2. es que la ley de pareto original, que trataba sobre la riqueza en italia (creo), es un 80-20

    pero el 90-10 en programación ya se lo había escuchado a más de uno antes y ya se lo había leído a más de uno también. no se porque se habrá puesto de acuerdo todo el mundo con el 90-10 en programación. será algún tipo de conspiración del gobierno.

    por cierto, muy interesante el artículo. y de acuerdo con las 3 afirmaciones

    Responder

  3. Bueno, hay ciertas personas que tienen una habilidad innata. Es flipante lo que pueden llegar a hacer. Pero sin trabajo no se consigue nada. Yo creo que si de verdad te gusta y te esfuerzas, puede que no estés dentro de ese 10%, pero sí en su proximidad. Pero esto pasa en todos los trabajos.

    Por cierto… ¿Qué es PSP? ¿Pascal Server Pages? ¿Python Servlets Pages? ¿Tiene que ver con la POO? ¿O es la consola de Sony? 😛

    Responder

  4. PSP: Proceso de software personal. un invento de un tipo de la carnegie mellon para mejorar el rendimiento a la hora de programar y para aprender a planificarse mejor

    Responder

  5. Ahhhhh… Hoy ya he aprendido esa cosa que tenemos que aprender todos los días, je, je 😀

    Responder

  6. Si ese 10% fueran iguales de mediocres que el resto, escribirían todos las mismas líneas de código, y tal vez el proyecto o saliera a flote mucho más tarde, o ni siquiera saliera.
    Si hay gente alta, es porque la mayoría es más baja que ella, y si hay gurús de la programación, es porque el resto son programadores mediocres. Se puede lograr con una enseñanza adecuada que los mediocres suban de nivel, pero desde luego ,siempre habrá unos que destaquen sobre los otros, y no sólo en informática, sino en música, cocina, mercadotecnia…

    Responder

  7. Opino como tu, programar es una habilidad que puede ser desarrollada y potenciada.
    Pero eso cuesta tiempo, y esfuerzo, y muchos no están dispuestos a hacerlo.

    Responder

  8. esa es la raíz de todos los males, guti. si se impusieran unos estándares de calidad…

    como decían en algún libro de ingeniería del software que he leido, deberíamos cambiar la forma de referirnos a los errores en los programas a algo asi como “bombas de efecto retardado” en lugar de bugs.

    lo primero suena mas serio, y si le dices a un cliente que el código tiene un par de bugs no se preocupa, todos lo vemos como algo normal, incluso que windows venga con unos cuantos bugs que hacen que nada mas instalar el sistema, si no tomas precauciones extras acabes infectado. si te dijeran que un producto tiene 10 de bombas de efecto retardado te lo pensarías mas de 2 veces antes de comprarlo.

    el que los clientes se preocuparan mas de la calidad del software y no tanto de los costes y de la rapidez haría que las empresas que producen software también lo hicieran. se le acabaría el chollo a mas de un picador de código que se dedica a tirar líneas por tirar líneas

    Responder

  9. Anónimo

    Estoy buscando sobre PSP en español, pero no encuentro casi nada.
    Algún enlace interesante?

    Responder

  10. hay bastantes páginas que explican muy por encima los objetivos y en que se basa psp. pero si te interesa nada como acudir a la fuente original: Introducción al proceso software personal, de watts s. humphrey, un gurú de la ingeniería del software

    Responder

  11. Eso solo pasa en las empresas grandes. Cuando tienes mas proyectos que programadores para realizarlos los programadores suelen hacer el 100% del código 🙂
    Aqui es facil elegir, solo puedes tener a programadores vocacionales por que los que no lo son no sacan el trabajo adelante y hay que sustituirlos por otros que si lo hagan.

    En cuanto a tu obsesion particular por la calidad zootropo, solo te repetire la frase lapidaria de uno de mis socios: Lo perfecto es enemigo de lo bueno.
    Si yo no pudiese sacar mi producto hasta que fuese perfecto, nunca lo acabaría, o si lo acabase, al sacarlo al mercado estaría absolutamente obsolescente.

    El que haya programadores que rindan poco no es culpa de los clientes, sino de los mandos intermedios que por desidia o despreocupación permiten esas cosas sin hacer saltar las alarmas.

    Responder

  12. ¿lo perfecto enemigo de lo bueno? 😮 bueno, una cosa es ser sobre-perfeccionista. entonces no le daría nunca el producto al cliente, porque nunca terminaría de pensar si un tal botón debería estar 1 pixel mas a la izquierda o la derecha… pero de ahí a no exigir unos mínimos criterios de calidad…

    no digo que un producto tenga que ser perfecto, mas que nada porque logicamente no se puede conseguir; somos humanos. pero al menos hay que tener un mínimo de calidad, porque se supone que un programa es el producto de una ingenería. y la excusa de que es una disciplina muy joven vale para explicar por qué somos malos ahora, pero no vale para explicar por qué no se intenta mejorar

    lo que no es normal es que un producto por el que la gente paga 100€ como Windows XP tenga vulnerabilidades que permitan que nada mas arrancarlo ya estés infectado. estamos muy mal acostumbrados a ser permisivos con esta clase de errores, y una cosa es que la fachada del edificio tenga una humedad y una muy distinta que se caiga el edificio entero. pedir a una constructora que no se me caiga el edificio encima no lo veo pedir demasiado. es lo mínimo que se puede esperar

    tampoco te digo que halla que alargar el tiempo dedicado al proyecto 10 veces la media actual; pero como primer paso valdría con tener una planificación realista que no haga que un programador tenga que pasarse las dos ultimas semanas trabajando 20 horas al día. entonces es cuando se suelen cometer la mayoría de los fallos que tiran la casa abajo.

    jornadas laborales + mejores programadores = 10% de la cantidad de errores que hay hoy & 200% de productividad

    tampoco te digo que vayamos a crear un mundo idílico en que no halla mas errores críticos en Windows; un sistema operativo es muy complejo. pero al menos se debería ver con la verdadera magnitud que tiene el problema y no acostumbrarse a verlo como algo normal. un bug, no es algo normal. la bsod no es algo normal. tener que reiniciar la maquina a ver si quiere funciona, no es algo normal.

    y para no aburrir mas escribiendo demasiado, copio algunos chistes sobre informática y a ver si veis el punto en común entre todos ellos

    – ¿Oíste hablar de ese experimento que hicieron para ver si trabajar con ordenadores es malo para la salud ? Metieron a tres ratas dentro de una
    jaula al lado de un ordenador, y lo dejaron encendido durante dos meses.
    – ¿Y las ratas se pusieron enfermas ?
    – No, pero escribieron tres nuevas versiones mejoradas del UNIX.

    Un medico, un ingeniero y un informático están charlando sobre cual de sus profesiones es la mas antigua. Empieza el medico :
    – Pues mira, la Biblia dice que Dios creo a Eva de una costilla de Adán, esto obviamente requiere cirugía, y por lo tanto la medicina es la
    profesión mas antigua.
    El ingeniero replica :
    – Si, bueno, pero antes de eso, la Biblia dice que Dios separó el orden del caos, esta fue obviamente una obra de ingeniería.
    El informático se echa para atrás en la silla y dice sonriendo tranquilamente porque sabe que ha ganado esa mano :
    – Sí, ¿pero cómo te crees que Dios creo el caos ?

    Un físico, un químico y un programador van en un coche por la carretera. De repente, el coche comienza a hacer un ruido extraño. Paran el
    coche, y dejando el motor en marcha elucubran sobre lo que sucede mirando el motor.
    El físico dice:
    – Evidentemente, hay un problema de rozamiento entre los pistones,de ahí el ruido.
    El químico replica:
    – De eso nada, el ruido es debido a que la gasolina esta mal mezclada.
    El programador va y dice:
    – Por que no lo apagamos, lo encendemos, lo apagamos, lo encendemos, …

    Un técnico en electrónica, un analista de sistemas y un programador de ordenadores van en un coche, descendiendo una montaña, cuando les fallan
    los frenos; el coche empieza a embalarse, los ocupantes empiezan a gritar, victimas del pánico, pero afortunadamente consiguen detener el coche justo
    a unos centímetros de un precipicio de 500 metros de altura. Salen del coche, respiran, y el técnico en electrónica dice, con la mano temblando todavía:
    – Creo que puedo arreglar el coche.
    El analista de sistemas contesta :
    – Creo que lo mejor seria llamar a una grúa y remolcarlo hasta el pueblo, y que lo viese un experto.
    El programador sugiere :
    – De acuerdo, pero ¿por qué no retrocedemos antes, volvemos a bajar la montaña, y vemos si los frenos se vuelven a estropear ?

    HARDWARE : Lo que puedes partir con un hacha.
    SOFTWARE : Aquello que solo puedes maldecir.

    costará admitirlo, pero no somos tan perfectos ¿verdad? algo estaremos haciendo mal

    Responder

  13. poderoso D

    es muy interesante el foro y me he dado cuenta de que hay gente muy habil con este tema ….tal ves me podrian ayudar a encontrar las diferencias acerca del principio de Pareto versus el optimo de Pareto… Tengo 22 años y a mi corta edad he llegado a comprender de que los seres humanos somos 10 por 100 conocimientos y 90 por 100 corazón .. lo que mas importa es el amor,decision,perseverancia que sientas para realizar cualquier acción. Puedes tener aquel 10 por 100 en su maxima capacidad lo cual te podria servir para distintas actividades sin embargo esta no tendra buenos resultados como un buen aporte a la siciedad; si no tienes nada en el corazon. no es necesario que sea perfecto sino que sea hecho con amor …este sentimiento sera transmitido atra vez de tu trabajo y por concecuencia sera aceptado por los demas como un buen producto o servicio ….DANIEL

    Responder

  14. Sin embargo, con lo que a veces he visto, de ese 90% muchas cosas son fáciles y las puede hacer todo el mundo, sin embargo ese 10% lleva más tiempo porque igual son los errores que nadie ve, o nadie sabe como hacer algo. Por ello creo que no hay que menospreciar ni a una ni a otra. A veces no por mucho programar y picar más líneas se es más eficiente.

    Responder

Deja un comentario