Buscar
Social
Ofertas laborales ES
« Ultimos videos del Spring I/O 2012 | Main | JavaFX 2.2 traerá empaquetamiento nativo de aplicaciones »
martes
jun192012

La ley de Yannis: la productividad de los programadores se duplica cada seis años

Yannis SmaragdakisYannis es un profesor de la Universidad de Massachusetts y de la de Atenas que ha propuesto una ley inspirada en la ley de Moore sobre el número de los transistores que pueden emplearse en la construcción de un microchip, pero relacionada sobre la productividad de los programadores. Su ley afirma que la productividad de un programador se duplica cada seis años. El motivo de esta duplicación en la productividad es que cada vez tenemos mejores herramientas de desarrollo.

Como evidencia empírica para su ley se apoya en una afirmación de David Parnas recogida en su artículo de 1972 "On the Criteria to Be Used in Decomposing Systems into Modules", donde se afirma:

The KWIC index system accepts an ordered set of lines, each line is an ordered set of words, and each word is an ordered set of characters. Any line may be "circularly shifted" by repeatedly removing the first word and appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts of all lines in alphabetical order. This is a small system. Except under extreme circumstances (huge data base, no supporting software), such a system could be produced by a good programmer within a week or two.

 

Obviamente, a día de hoy no hace falta una o dos semanas para programar esa funcionalidad. Según Yannis hacen falta una o dos horas, lo que supone un incremento de productividad de 40 veces desde 1972, lo que se traduce en duplicar la productividad cada seis años.

No se como de cierta será su afirmación en los detalles (si la productividad se duplica exactamente cada seis años), pero mi impresión también es que nuestra productividad no para de crecer continuamente. A principio de este siglo hacer una aplicación web que implementase un CRUD sobre un modelo sencillo podría requerir tranquilamente unos pocos días, o hasta un par de semanas. A día de hoy, con motores de persistencia como JPA, y más todavía si empleamos frameworks basados en la aproximación "Model driven development" esto puede hacerse literalmente en unas pocas horas.

¿Estáis de acuerdo vosotros con la idea general detrás de la  ley de Yannis? ¿Y con su cuantificación, es decir, con el hecho concreto de que el incremento en la productividad es exactamente una duplicación cada seis años?


PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (9)

Antes tenía un teorema que le llamaba "El Teorema del Garito" que decía más o menos:
"En cada garito al que entras hay al menos un chica que quiere algo contigo"

Y por supuesto es falso, como la Ley de Yannis Smaragdakis, la diferencia es que yo lo compartía con los amigos y no lo hacía público.

Yo pienso que las herramientas de desarrollo y framework nos permiten hacer las cosas más rápido y que seguro que en el futuro siga mejorando, pero de ahí a afirmar que cada 6 años se duplica, es tirarse a la piscina.

junio 19, 2012 | Registered Commenterrobertiano

Si no se tiene en cuenta el tiempo necesario para dominar el uso de los frameworks, las referencias a la productividad basadas únicamente en "el tiempo necesario para la implementación de una solución", son erróneas.

junio 19, 2012 | Registered Commenterchoces

Este tipo de afirmaciones sólo crea falsas espectativas tanto en los project leaders, clients, y managers.

Si, cada vez tenemos mas productividad gracias a las herramientas, pero hay limites.

Si no existen estandares aceptados para medir el tamaño de un sistema (que es algo basico), menos podremos decir que hacemos mas.

En fin... debí haberle echo caso a mi santa madre, debí estudiar medicina.

junio 19, 2012 | Unregistered CommenterEdgar

Ahora vas, y se lo cuentas a Merkel.

junio 20, 2012 | Unregistered CommenterAlberto

Vaya, parece que por lo general la gente está en desacuerdo con Yannis. Yo no tengo claro si su cuantificación es correcta, pero su idea general sí. Ayer mismo he leído que los driver de las GPUs modernas *tienen la misma complejidad que Windows 95*. Es decir, en algo menos de 20 años sólo un driver del sistema operativo es igual de complejo a lo que lo era todo sistema operativo. Las herramientas que tenemos para desarrollar software, los frameworks, y los lenguajes de programación (por ejemplo, C++ vs Java vs Groovy) nos permiten cada vez desarrollar mucho más rápido.

Sin embargo, esto trae una inevitable consecuencia: las expectativas de los clientes crecen. Hoy podemos hacer una página web probablemente 10 veces más rápido que a finales de los 90. Pero a finales de los 90 todo el mundo asumía que hacer un clic en un enlace suponía recargar toda la página al completo. Hoy para muchas acciones eso no es admisible. La apariencia gráfica de la aplicación web ha mejorado brutalmente. Y ya no nos llega con crear sólo una página web; además necesitamos un cliente móvil. Tenemos mucho mejores herramientas y podemos desarrollar más rápido, pero nos piden más. Y esto es el resumen de toda la historia de la informática.

junio 20, 2012 | Registered CommenterAbraham

Si medimos la productividad por hacer una aplicación CRUD... en fin, que en informática hay más cosas en la vida que aplicaciones WEB de Gestión, y no estoy de acuerdo en ese ratio de productividad, es tremendamente exagerado

junio 20, 2012 | Unregistered Commentermiguel

Lo de la aplicación CRUD es sólo un ejemplo. En general yo creo que se aplica a la mayor parte tareas que resolvemos los desarrolladores.

junio 20, 2012 | Registered CommenterAbraham

Puedo estar superficialmente de acuerdo con la teoría pero como siempre el infierno está en los detalles. Y en lo que estoy rotundamente en desacuerdo es en la linealidad, más bien los aumentos de la productividad van más a trompicones.

El que el driver de GPU sea muy complejo es porque se ha ido añadiendo complejidad no porque sea mucho más rápido el desarrollo.

En lo de la mejora de la productividad está el eterno dilema de la abstracción:

funcionQueHaceUnaCosaFantasticamenteComplejayChula();

Si esa función hace exactamente lo que necesitas, simplemente debes llamarla.

A donde quiero llegar es que parte del aumento de la productividad se debe curiosamente a hacer comulgar al cliente con ruedas de molino, si lo consigues tu productividad será brutal. El problema es cuando el cliente se sale de tu solución super-chachi-pre-fabricada, adios productividad, y la herramienta avanzada se convierte en un problema, es decir echamos en falta una callback como parámetro de nuestra potentísima función que nos permite modificar el comportamiento de la misma de acuerdo a las necesidades del cliente.

A veces el aumento de la productividad no es lineal, por ejemplo ahora en web hay que sudar para obtener una experiencia de usuario que ya existía hace DECADAS en el escritorio y con menor dificultad, cualquiera fácilmente puede ver que desde el punto de vista de la productividad el web ha sido un enorme lastre, tecnología que en la parte cliente no ha evolucionado prácticamente NADA hasta hace unos poquitos años.

Java mismo en el escritorio en sus inicios era una tecnología pobre, con muchos fallos y mediocre, dudo mucho que las primeras aplicaciones de desktop (AWT) fueran más productivas que las hechas en C++, el precio de la portabilidad (que tampoco es que fuera muy fina en AWT).

Las bases de datos orientadas a objetos tuvieron su esplendor en los 90, en ellas mapear un objeto C++ por ejemplo a un objeto en BD era directo y TRIVIAL. Después de 15-20 años aparte de los mappings en cualquier ORM "transparente" si llamas a un método tipo getListaHijos() te traes toda la tabla de hijos aunque sólo quieras mostrar los 10 primeros (ya ya se que hay que utilizar una query etc), si a esto le añades la tendencia moderna hacia las bases de datos sin esquema pues el mapeo a objetos hay que hacerlo de nuevo a mano, luego podremos ganar en escalabilidad pero a costa de productividad.

Por no hablar de las tendencias retro como en el caso de Node.js en donde se propone como lo más de lo más la gestión manual de hilos y el spaghetti western por no hablar de renunciar a todo un enorme ecosistema si es que vienes de Java. Es decir más pérdida de productividad.

Por no hablar de la tendencia a la programación intensiva en cliente en JavaScript: a partir de la línea 1000 y trabajando en equipo... adios productividad.

Como se puede ver lo de la productividad lineal no me lo creo aunque sí que es real que a largo plazo tras avances y retrocesos...indudablemente se avanza.

junio 20, 2012 | Registered Commenterjmarranz

Este chico me parece que le tiene envidia a Moore.

Que se avanza evidente, del mismo modo que los ordenadores cada vez son mas potentes. Que somos mas productivos, evidente. Solo la ayuda que nos dan los IDES, las mejoras en herramientas para trabajo en equipo, y las mejoras en APIS o so incluso lo que tarda en compilar un ordenador moderno, hacen mucho.
Pero de esto a dar formula matemática, al progreso, no lineal, sino cuadrática, es buscar el titular. Vamos igual que la ley de Moore que siempre me ha parecido una chorrada magnifica, y que si se cumple será que este tío tiene poderes.

junio 22, 2012 | Unregistered Commenterjanatic

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>