Investigadores de la Universidad de Zurich (Suiza) han desarrollado una metodología para "adivinar" la calidad del código escrito por un programador. Los investigadores Sebastian C Müller y Thomas Fritz presentaron su trabajo en la 38ª edición de Conferencia Internacional de Ingeniería del Software de Austin (EE.UU.) donde mostraron cómo su sistema, consistente en analizar las pulsaciones, sudoración, etc de un programador mientras escribe, detectaba hasta un 50% de los errores de programación y mostraba la "calidad" del software que se creaba.
Comentarios
Solo falta el pienso y que pongan huevos para considerar a las cárnicas como un sector primario y no de servicios.
#1 No solo a las cárnicas, en unos cuantos años la identificación de patrones por medio de la biometría se podrá aplicar a otros muchos campos.
http://ieeexplore.ieee.org/xpl/login.jsp?reload=true&tp=&arnumber=7435286&tag=1&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D7435286%26tag%3D1
Por un lado está el problema de los datos biométricos es decir de ir contra la privacidad e intimidad del programador y como explica ese monitoreo constante no es bueno para la productividad. Por otra parte tenemos el tema de si en verdad esos datos biométricos pueden demostrar realmente algo. Un programador puede sudar mucho, por ejemplo si estamos en verano y hacer tropecientas líneas de código en un día, pero a lo mejor más de la mitad de esas líneas valen para poco o nada y tienen fallos. Además de que es absurdo mirar el rendimiento de un programador sólo por la cantidad de líneas que puede hacer en un día. Ya que programar mejor o peor depende de muchas cosas:
- El tipo de software a desarrollar y la complejidad de este. No es lo mismo hacer un "Hola Mundo" que el programa de control de una estación meteorológica.
- La correcta planificación de este, diagramas de flujo, pseudocódigo...
- El ambiente en la empresa, muy importante y en realidad en todos los trabajos: Temperatura, iluminación, espacio,...
- Cualquier situación de estrés, reduce el rendimiento. Y a veces pasa por tener un jefe un poco cab... hablando en plata.
- Optimización del código y corrección de errores. Si es difícil programar más lo es optimizar el código. Además el optimizar el código no es sólo hacerlo y ya está. A veces por la complejidad o funcionalidad del programa no se puede optimizar tanto el código. No en vano dependiendo de los recursos de los que dispongamos, plataformas donde se ejecutará este software y requisitos generales, se optimizará más o menos y funcionará peor o mejor. De ahí el tema de los requisitos mínimos y máximos. Y lo bajos o altos que sean estos.
- Una manía (y así se ven los resultados y la calidad del producto desarrollado) es que digan tienes que tener esto listo para tal fecha, es muy probable que por diferentes problemas el software salga mal. Y esto se vé demasiado, cuando se piensa en el dinero que la empresa quiere ganar, respecto al que realmente va a ganar sacando el producto antes de tiempo al mercado. Especialmente en los vídeojuegos se nota demasiado.
Salu2
Antes les metían un palo en el culo y lo olían para determinar la calidad del pringao quicir del programador
#2 qué gente más rara con la que te has encontrado. ¿Oler el palo? Con lo fácil que es dejarlo donde está y comprobar si es capaz de barrer mientras programa
#2 Y lo siguen haciendo. Pero ahora además del palo, te miran el color del ojete y cuantos pliegues tienes para la bbdd biométrica
#2 Con vosotros usaban un palo? que frío no?
Tontería como una casa de grande.
Hombre... siempre se ha calculado la complejidad de un desarrollo sumando los reniegos/hora de los programadores.