El nivel de stress es un predictor de la calidad de código


(David Lay) #1

Lo interesante es que es un estudio que no se basa en métricas de calidad, sinó en peer-review y percepciónes de dificultad, entre otras cosas, que ha sido uno de los conflictos frecuentes en estudios de este tipo.


(Guillermo Schwarz) #2

Aunque es como obvio que si te llaman por teléfono cada 5 minutos, te envían 5 mails en la mañana y 5 mails en la tarde y te gritan por teléfono ¿porqué no has terminado?.. el resultado de ese código no puede ser bueno.

Pero aún así, no sé cómo medir el nivel de estress de una persona… ¿pupilas dilatadas?.. ¿pega un grito histérico cuando se le pide algo simple?.. ¿se queda dormido al medio de una conversación?

La calidad del código es mucho más fácil de medir, como dice Uncle Bob: código simple, cada método de no más de 10 líneas, todo con pruebas unitarias y nada de código repetido.

Es demasiado simple y salta a la vista. Si el código es muy malo, generalmente cuando se le pregunta al programador, se nota que está estresado.

¿Qué debemos hacer en ese caso?

Pedírselo a otro. El programador original se relaja porque la parte difícil es ahora responsabilidad de otro. Eso implica que tienes un programador más para programar lo que viene. El programador que debe involucrarse en esta tarea que para el es nueva, siente que está haciendo algo para demostrar sus habilidades y diferenciarse de otros programadores.

Todos ganan.

Cuando el código está terminado, el programador original puede leer el código y ver que no era tan complicado. Eso es aprendizaje.


(David Lay) #3

Cito desde el paper:

4.1 Participants & Sensors
We were able to recruit ten professional software developers from a medium-sized software development companyin Canada for our study. The ten participants (nine male,one female) ranged in age from 23 to 45 years and had anaverage professional software engineering experience of 10.2years (6:2), ranging from 3 to 22 years. All study partici-pants worked on the same project, but were split over threedi erent teams that were in charge of di erent componentsof the project. All teams followed a similar agile software de-velopment process and worked on tasks with similar sizes2.Each participant had access to her biometric data and wasallowed to quit any time without providing a reason.We used two biometric sensors for this study: an EmpaticaE4 wristband [24] to capture skin- and heart-related mea-surements, and a SenseCore chest strap3to capture skin-(except for EDA), heart-, and breathing-related measure-ments. Participants were asked to wear the chest strap andoptionally also the wristband. We ended up with all tenparticipants wearing the SenseCore sensor for the two-weekstudy period, and six of them (P01, P04, P05, P06, P07 andP08) also wearing the Empatica wristband in addition.

Es una decepción que la muestra sea tan insignificante. Esto es equivalente a los estudios “clínicos” de shapoos y cremas. Por eso hay que ir a ver el paper, en esta ocasión caí con el artículo de boingboing. La ciencia no es así, me da rabia.


(Guillermo Schwarz) #4

Bueno, no sé qué tiene de importante el estudio, si de todas maneras a nadie lo van a conectar a una máquina si está estresado, si una empresa quisiera saber si el programador está estresado, entonces debe preguntarle y bajarle la carga en caso de que diga que sí.

Obviamente todos dirían que sí. Eso no funcionaría mucho.

Lo que dijiste de que el método estaba malo, te encuentro toda la razón. Tiene que haber un grupo de control al que no se le pone la maquinita. Debe haber un grupo sin estress que use la máquina, y un grupo con estress sin la máquina. Y así, debe haber una serie de grupos, para poder comparar sus resultados. Sin estrés, poco estrés, estrés medio, estres alto, estres super alto, etc.

Después como le arreglas los nervios a los programadores que recibieron mucho estrés…ese es un problema para los psicólogos. Si llega un día un tipo con una escopeta y se los pitea a todos, como hacen en USA, significa que los psicólogos valen champiñon. Yo por lo menos no escucharía psicólogos gringos, porque por sus resultados los conoceréis.

Para mejorar la productividad, es mucho mejor tener una lista de tareas infinitas y que el programador se enferme sólo por tratar de demostrar que es mejor que los demás. Eso requiere que todo el mundo vea lo que cada programador hace, y que la competencia no implique que si un programador sabotea a otro, tenga premio por eso, porque se genera un ambiente hostil.

Lo de mejorar la productividad porque todos pueden ver lo que hace el resto, pasa, y pasa siempre, de hecho de lo único que tienes que preocuparte es de que el código basura no entre al repositorio, porque se van a estresar lo quieras o no, debes tener un control para que la velocidad del proyecto no baje: pruebas unitarias + code review. Con eso basta.

El problema de estress… bueno tendrá que ir al psicólogo… no sé, ¿hay alguien respirándole en la nuca? ¿quién lo apura?

¿Porqué tanta preocupación?

Si el tipo cumple su horario y hace una cantidad de trabajo razonable, ¿porqué tendría que estresarse?

Ahora si el tipo no cumple su horario y no hace nada durante todo el día, y este comportamiento se repite durante meses… no creo en los ultimátums, ni en las reprimendas, al tipo claramanete no le gusta su trabajo, en vez de empujar la carreta, está deteniéndola, claramente mientras no miras, no trabaja… y el tipo es capaz de deshacer en la tarde lo que programó en la mañana.

En mi experiencia la gente que cumple horas extra obligatorias y no pagadas durante mucho tiempo, se le seca el cerebro y se vuelve rebelde, quiere desquitarse de alguna manera, si le das la oportunidad de flojear, lo va a hacer.

Eso explica porque en Chile nunca se inventa nada: todos descienden de esclavos explotados y de explotadores descerebrados. Si no fuera así, con el esfuerzo adicional habrían sientos de ejemplos de cosas brillantes que podríamos exportar, pero terminando exportando materia prima porque el ADN viene fallado.


(David Lay) #5

La hipótesis es interesante porque vincula la calidad del ambiente laboral (stress del individuo) con la calidad del código producido, permitiendo hacer la subsecuente hipótesis de que si “mantengo las mismas condiciones y personas, pero les mejoro el ambiente para que reduzca su estress, voy a tener mejor calidad de código”. El estudio habría demostrando una correlación (si se hubiera hecho bien), para luego poder pasar a estudiar si la causalidad existe.

Hasta ahora, es simplemente sentido común que en un mejor ambiente vas a rendir mejor y pondrás más atención a la calidad y etc, haber tenido un estudio que lo respaldara habría sido un potente argumento a favor de esto.

Es cierto que esto no debiera derivar en que (de validarse la hipótesis) todos usemos de ahora en adelante bandas biométricas ni mucho menos, como ratones de laboratorio. Pero si podría justificar medidas como por ejemplo tener apoyo psicológico y revisar las políticas de trabajo dentro de la empresa para asegurar que actitudes como las que indicas (respirar en la nuca, reprimendas, gritos, deadlines estúpidos aka marchas de la muerte) sean castigables administrativamente dentro de la empresa.

Obviamente esto es buena idea hoy, por sentido común. ¿Pero hay alguien haciéndolo? No, porque? Porque no se ve el beneficio directo de “stress => mala calidad” sino que se ve generalmente como “calma => baja productividad” y su directo opuesto “stress => alta productividad”.

La vinculación con la productividad no está hecha y no me queda claro. Depende de la definición de productividad.


(Guillermo Schwarz) #6

Definición de productividad = plata que entra / plata que sale

Es la misma definición de rentabilidad.

Esto es así porque si tengo un programador estrella que programa 10 veces más rápido y con cero bugs, pero me cuesta 10 veces más que un programador normal pero que escribe 1 bug or cada 10 líneas de código (según CMMI), entonces me da lo mismo tener 10 programadores promedio que uno estrella, gasto mismo y producen lo mismo, y tengo la ventaja que si se enferma… no se me van a enfermar los 10 programadores al mismo tiempo.

Obviamente ningún programador gana 10 veces más, pero fíjate en lo que hacen los JP, le piden más al programador que rinde más, para sacarle provecho y “educar” a los programadores que rinden menos.

De esa manera tienes programadores promedio que se acercan asintóticamente al programador estrella.

Ahora bien, respecto a tener ambientes sin estrés, eso es lo que hago y lo que hacen todos los métodos ágiles. No hay presión, no hay sobretiempo, el tiempo lo pones tú y si no cumples, pasa la tarea al siguiente sprint. Que se joda el JP, el gerente e incluso el cliente. No se alcanzó, punto.

La logica para hacer esto es que hay una velocidad natural de las personas y de los equipos de trabajo. Las estimaciones son sólo estimaciones, te puedes encontrar con problemas no especificados inicialmente, requerimientos incompletos, incompatibilidad con la plataforma, incompatibilidad con lo que ya está escrito, etc. O puedes estar pasando por esos días en los que nada te resulta y mejor no te hubieras levantado. Pasa, poco pero pasa.

Si no fuera así, no seríamos personas. Los proyectos de software tendrían la dificultad de trabajar en un macdonald. Dile a tu jefe: " a ver resuelvelo tú", y ve como el estúpido se acobarda, porque hay que ser imbécil para pensar que cualqueir persona de la calle es capaz de hacer lo que estás haciendo tú, sin embargo la mayor parte de los jefes acá en Chile no tienen idea de la dificultad de lo que están pidiendo porque no programan.

Y es más, en Microsoft, mi jefe programaba, el jefe de mi jefe programaba, y era comentado que hasta Bill Gates bajaba del olimpo de vez en cuando y te hacía los code reviews directamente.

Comparativamente acá estamos rodeados de idiotas que piensan que programar es lo mismo que dar vuelta hamburguesas. He visto proyectos atrasados 5 años. Si eso no es ser idiota, no sé que es.

Y el problema es que como son jefes, todo el mundo los copia, como si losidiotas supieran más.

Cuando conversé esto con los XPers el año 2000, me dijeron una frase que nunca se me va a olvidar “the immates are running the asylum”. Puede que ahora que están más viejos y el éxito de XP parece que se evaporó, tengan un discurso más políticamente correcto y por ende más mentiroso, sólo para que no los despidan de sus puestos irrelevantes, ya que tienen que mantener a sus familias y no encuentrasn trabajos adecuados a sus conocimientos, porque para qué estamos con cosas, generalmente la gente que toma decisiones en las empresas sólo se maneja con planillas excel, de modo que los tipos que toman decisones son “bean counters”… otra frase de los XPers.

Si quieres bajar la presión:

  1. Nada de horario de entrada y de salida. Cada cual llega a la hora que le acomoda. El horario de salida es a las 5 pm.
  2. Cada uno tiene una lista de tareas que hacer, pero tus tareas son tuyas cuando dice que estás trabajando en ellas, y sólo puedes trabajar en una a la vez.
  3. Si se te acaban las tareas, puedes tomar tareas de otros en las cuales no estén trabajando.
  4. nada de premios y castigos por terminar tareas a tiempo o tarde.
  5. Todas las tareas deben estar subdivividas en tareas de no más de 2 días.

¿Qué implica todo esto?

Nada de reuniones de estatus. No pierdas el tiempo. El estatus está en el issue tracker. No hay reuniones de feedback, el issue tracker debe calcular cuanto te vas a demorar según tu propia historia, si siempre te demoras el doble, el issue tracker sabe cuánto te vas a demorar en terminar todo => tus tareas desaparecen del backlog.

¿Cómo te puedes estresar con tareas pequeñas?

Eso significa que el stress es puntual por una tarea que no te sale, pero entonces: vuelves a subdividir, creas prototipos que demuestran que tu diseño está bueno, etc.

Obviamente eso requiere un comportamiento medio Nazi respecto de las tareas, en el sentido de que nadie puede asignarse a sí mismo tareas que van a tomar 2 semanas, o tareas que están mal subdivididas, eso implica que la gente realmente hace prototipos, y los gerentes no se pueden meter a dar órdenes de prohibir los prototipos (me ha pasado), o que no se hagan pruebas unitarias (también me ha pasado).

El problema son siempre los gerentes y los clientes, porque por difinición no entienden lo que hay que hacer para cumplir con lo que están pidiendo, piden idioteces, les dices que se equivocan, te dicen que no importa, y luego cuando queda la mansa embarrada, por no decir el vocablo correcto, se hacen 100% los desentididos, de neuvo, por no decir el vocablo incorrecto.

Los gerentes nuca asumen su responsabilidad porque existe la idea de que “deben ser creíbles”, justamente para que la gente les haga caso. Eso nos lleva por difición a marchas de la muerte. Porque si su estrategia no funcuona, la única manera de arreglarlo es hacerte trabajar hasta las 11 pm, y luego pedirte que vengas el fin de semana, y si eso no funciona, que te quedes toda la noche.

Mira cuando empiezan con la tonterita, miras el código, y las primeras 5 líneas de código están malas, no importa donde mires. Porque se asume que el gerente es inteligente y el programador es un autómata. Eso obviamente no es cierto, y no sólo no es cierto, es al revés. El gerente es el que juega con planillas Excel, tú, el programador es el que tiene que acordarse que los requerimientos cambian , que el código debe ser flexible, que las dependencias deben ser manejadas cuidadosamente.

Hay estudios que dicen que el peak de productividad son 2 horas al día. Los XPers decían que no se puede medir la productividad por hora, sino por día, porque los ojos abiertos no significan que tu cerebro esté despierto.

Imagina eso: 2 horas al día. Esas son 2 horas al día programando. Supoongamos que necesitas 1 hora al dí para leer y escribir documentación. Luego 2 horas para tener todas las reuniones informales que necesites. Son 5 horas en total. Si trabajáramos 5 horas, entras a las 9 y sales a las 2 pm.

O entras a las 9 almuerzas de 12 a 14 (en Francia es así) y luego sales del trabajo a las 4 pm.

Se siente como estar de vacaciones, totalmente despejado.

De hecho trabajar más horas significa que escribes basura, lo quieras o no, porque el cerebro no es capaz de concentrarse tantas horas, simplemente se agota.

Pregúntale a cualqueir sicólogo cuántas horas te puedes concentrar al día haciendo un trabajo intellectual: te va a decir que no más de 2 o 3 horas al día.

Por eso los proyectos fracasan, te guste o no.

A eso súmale que la ley chilena permite que no te den vacaciones, te las pagan, o se te acumulan. En Francia te dan 2 meses de vacaciones al año y te las tomas sí o sí. A mí se me hace tanto tiempo, que no sabría que hacer con todo ese tiempo, por lo menos acá en Chile que claramente los sueldos no te alcanzarían para tomar tantas vacaciones, porque los precios de las vacaciones implican que tienes que ganar unos 8 millones para poder estar tan sólo un mes de vacaciones como corresponde, si una pieza de hotel son 40 lucas, una para tí y tu esposa y otra para tus hijos, serían 80 lucas diarias, por 30 días, son 2,4 millones sólo en las piezas, falta la comida y salir a alguna parte, es impagable.

¿Se entiende?

Te explotan, y el sistema está hecho para que no te alcance el tiempo para darte cuenta que lo que te pagan es un chiste. Esclavo moderno.

Como se ha visto en las noticias,todos los empresarios y todos los políticos son ladrones. Eso debería darte una idea de porqué te hacen trabajar como un animal de carga.

Es cierto lo que dices, si no hay mayor productividad, ¿porqué te hacen trabajar tanto y porqué no te dejan ver la luz del día? La respuesta es simple: eres un esclavo, y mientras menos tiempo tengas para pensar y darte cuenta, mejor para todo el sistema de robo que se ha implantado desde la llegada de los españoles.

Por eso las empresas extranjeras se llevan los minerales sin pagar impuestos, y el royalty que se supone que es para la innovación, se lo llevan a través de Corfo, los hijos de las familias más pudientes (= ladrones) para realizar innovaciones que no le sirven a nadie, pero no importa porque siempre puedes postular a Corfo de nuevo y seguir robando. Esto está ampliamente documentado,es sólo un paliativo para que lse les olvide que están viviendo en un país de mierda.

Como dice Morpheus a Neo en The Matrix: To see how deep the rabit hole goes. En este caso, the rabit hole es un sistema de robo que va más allá de lo que te puedes imaginar.

Los gringos cuando vienen a Chile se preguntan porqué mantenemos el IVA si perjudica a los pobres. Porqué las cosas valen lo mismo que en USA si los sueldos son claramente el 10% de lo que se gana allá. Y se preguntan cómo hacen los chilenos para sobrevivir. Y les tengo que decir que todo el mundo roba, o comete actos que van contra la moral y las malas costumbres. Esa es la realidad.

Los empresarios roban, porque pudiendo pagar sueldos de verdad, pagan sueldos miserables, y se preocupan de quitarte todo tu tiempo para que no te te des cuenta que realmente no te están pagando, hacen como que te pagan.

La logoca de los empresarios es que si pones más tiempo de tu parte, aunque estés cansado, entonces el proyecto va a salir igual. La verdad es al revés, pero no me quejo porque son ellos los que pierden su dinero.

Lo únco malo es que tu CV queda lleno de fracasos. ¿No seŕa por eso que en Chile no hay open source? Quién mostraría la porquería de código que escribe.

De hecho esto es tan prevalente cuando llego a una empresa y me pasan algún proyecto que ya empezó, siempre me advierten que estaban apurados y que no es el mejor código que podrían escribir, como para que uno no haga escándalo. Eso a mí me dice todo respecto al proyecto, al código, a la empresa y al tipos de personas que dirigen la empresa. Obviamente estoy perdiendo mi tiempo ahí, se que voy a tener problemas con todos porque consideran que programar es ser idiota.

Creo que tienen razón: hay que ser idiota para programar para gente idiota. Ningún nivel de sueldo te va a salvar de sentirte miserable porque estás trabajando con idiotas para idiotas, con código escrito por idiotas. El resultado, no importa lo que hagas, será detestable y detestado por todos, incluso antes de que escribas una línea, porque su punto de vista es que ser basurero tiene más prestigio que escribir código.

Si entras a una empresa y te encuentras con código basura, dí que el código no sirve y reescríbelo. Manda todo al carajo y reescribe el código.

Para cuando se den cuenta, será muy tarde.

Te van a tratar pésimo, pero no importa. Ningún médico operaría a un paciente con un serrucho… a menos que esté en el hospital de Talca y Bachelet sea la presidenta.