Programación por Coincidencia

Los proyectos de software usualmente implican para los equipos usar nuevas herramientas, nuevas librerias, nuevas lenguajes o nuevos dominios.
Esta novedad es un ambito perfecto para caer en lo que Andy Hunt y Dave Thomas llamaron programación por coincidencia.

Es un error tan usual porque una vez tras otra se renuevan las posibilidades de cometerlo.
Cada vez que uno comienza a utilizar una nueva librería, por ejemplo, y no entiende bien porque nuestro código funciona, es muy tentador recostarse en la sensación de progreso y pasar al siguiente problema. Es un error.

Si no has leído o escuchado la expresión programación por coicidencia, la explicación detallada está siguiendo el link:

Programming by coincidence

Sentido de urgencia

Puesto que las personas confunden el estar corriendo con un verdadero sentido de urgencia, a veces tratan de crearlo. El frustrado jefe pide a gritos que “ejecuten”. Sus colaboradores se ponen frenéticos: corren, se reúnen, conforman grupos de trabajo, mandan correos electrónicos, todo lo cual crea un viento aullador. Pero eso es todo que es, un viento aullador,o, pero aún, un tornado que destruye mucho y no construye nada.

Sense of urgency de John P. Kotter

Esa descripción se parece mucho a mi experiencia reciente. Kotter lo llama falso sentido de urgencia. 

Evitar el feedback triangulado

Son incontables las veces que he leído un artículo donde se plantea un ejemplo de lo que no se debe hacer y veo que este refleja exactamente mi conducta en algún momento.

En este caso me sucedió con un artículo que habla sobre el rol que debe jugar un manager cuando una persona de su equipo critica algún aspecto del trabajo o el comportamiento de un compañero.

Esther Derby lista recomendaciones muy interesantes para esos casos en No More Middleman: Avoid triangulated feedback.

En resumen:

- Dar y recibir feedback es parte del trabajo de todos, no sólo de los managers
- Feedback de segunda mano daña las relaciones laborales
- El feedback entre pares puede mejorar las relaciones laborales

¿Por qué siempre nos enfocamos en lo que hacemos mal?

Hace unos días comencé a leer "Ahora, descubra sus fortalezas" de Marcus Buckingham, principalmente porque me gustó mucho su libro "Primero, rompa todas las reglas".

La idea principal del libro es bastante simple y lógica. La mejor manera que tiene un manager de mejorar como profesional, y ayudar a mejorar a sus dirigidos, es identificando sus fortalezas y haciendo lo necesario para sacarle el máximo provecho.

Si bien esto no parece una gran revelación, comienza a observarse el valor cuando se describe lo que generalmente se hace: identificar las areas más debiles de uno y tratar de mejorarlas.

He estado pensando bastante en esa idea este ultimo tiempo, y sin embargo no he podido dejar caer en el error marcado por el autor.

En la empresa donde trabajo, los managers somos evaluados por las personas que dirigimos mediante una encuesta anónima. Esta encuesta pregunta sobre varios aspectos del trabajo y asigna puntajes a cada área según las respuestas.

Lo primero que hice al consultar el resultado de mi evaluación fue buscar los items donde tuve peor puntaje. Luego me puse a pensar cómo podía hacer para mejorar esos aspectos en los cuales me habían calificado peor. Justamente lo opuesto a lo que debería hacer segun Buckingham.

Evidentemente es dificil cambiar algunas costumbres. Pero igual voy a hacer el intento. Ya mismo me voy a fijar en qué areas me calificaron mejor y para que cosas soy realmente bueno.

Lazos gerente-empleado

Leyendo el libro Primero, rompa todas las reglas de Marcus Buckingham y Curt Coffman, encontré una frase que define claramente lo que podía intuir hace tiempo pero no lograba articular:

Las compañias sanas necesitan que hayan lazos fuertes entre cada gerente y cada empleado. Si el gerente no ha tenido voz en la selección de su gente y no participa en su éxito actual y su desarrollo futuro, esos lazos se marchitan...

La esencia modular del papel de un gerente se basa en esas cuatro actividades: seleccionar a la persona, establecer las expectativas, motivarla y desarrollarla. No es posible centralizar las actividades que solamente se pueden hacer bien a un nivel individual, entre el gerente y el empleado.

La pregunta que queda en el aire luego de analizar este concepto es, ¿qué se debe hacer cuando la estructura de la empresa en la que uno trabaja restringe estos lazos? ¿Cómo construirlos?

No hay nada que hacerle, asi es el conocimiento. Sólo genera más preguntas.

¿Quién define los procesos de software?

No es fácil encontrar procesos de desarrollo de software que parezcan ser diseñados por personas que desarrollen software, al menos en mi experiencia personal. Sin embargo, me he cruzado con el caso prácticamente inverso: procesos diseñados por personas que no les atraía en lo más mínimo desarrollar software o aprender algo sobre el tema.

En estos casos, la línea de pensamiento parece ser la siguiente: "Aquellas personas a las que nos les atrae desarrollar software (diseñar una solución, escribir código, testearlo) pueden dedicarse a otra área, como la definición de procesos". De esa manera, se puede evitar la necesidad de conocer y dominar aspectos que hacen posible la construcción de software, porque se puede cubrir el vacío con conceptos abstractos o genéricos como variación, estabilidad de proceso, causas especiales y causas comunes de variación, entradas, herramientas o salidas.

Para hablar sobre estos temas no hace falta conocer de software. De hecho podríamos hablar de manufactura de tornillos y aplicar estos mismos conceptos. Por esta razón, considero que la aplicación directa de estos conocimientos generales carecen de gran valor si no tienen detrás un análisis que busque mejorar una realidad en un ámbito definido. Muchas veces este análisis no es realizado, o las personas que lo hacen no tienen los conocimientos necesarios para hacerlo adecuadamente. Esa situación indefectiblemente conlleva inconvenientes.

Philip Armour analiza este y otros problemas relacionados a los procesos de desarrollo de software en The Laws of Software Process: A New Model for the Production and Management of Software. Tiene varias ideas interesantes para tener en cuenta:

En muchos casos, los procesos [de desarrollo de software] son ideados por ingenieros de proceso, pero frecuentemente ellos no son las personas que están creando el sistema. Estos ingenieros incluso son separados para definir estrictamente el proceso. Los desarrolladores están demasiado ocupados haciendo el trabajo y, a veces, evitando aplicar el proceso. Cuando un proceso es desarrollado por personas que de hecho no lo utilizan, pasan varias cosas:

• Los ingenieros de proceso pierden de vista la aplicación detallada que hacen un proceso valioso.
  
• Sin tener acceso al detalle, ellos están forzados a trabajar mas a un nivel meta, que es fácil para ellos porque no tienen que desarrollar real conocimiento del dominio dentro del proceso.
  
• Como ellos usualmente no aplican el proceso que están ideando, pueden perder la habilidad de validar si el proceso es realmente útil.
• Casi inevitablemente, crece la mentalidad de que si el proceso es bueno, entonces mas proceso debe ser mejor.
• El proceso toma importancia para estas personas, no por el valor que trae, sino porque es la razón por la cual tienen trabajo.
• La definición del proceso es dejada a un nivel descriptivo, en forma de libro, no de manera ejecutable... Esto deja el trabajo real de hacerlo funcionar a los desarrolladores usando el proceso. Este es un lugar muy seguro para estar - para los ingenieros de proceso. Si el proceso funciona, el grupo de proceso puede reclamar el crédito; si no funciona, la culpa puede ponerse sobre los desarrolladores por no aplicarlo apropiadamente.

El arquitecto tambien implementa

Varias veces escuche la intención de algunos desarrolladores de focalizarse o crecer en su carrera profesional hacia una posición de Arquitecto, porque escribir código no era de su interes o no les parecia una tarea muy desafiante.
Ese pensamiento me resulta extraño, porque no creo que un arquitecto puede cumplir bien su rol si no escribe código.

Jim Coplien y Neil Harrison escriben en su libro Organizational Patterns of Agile Software Development el patrón que llaman "El arquitecto tambien implementa":

Demasiados arquitectos de software limitan su pensamiento y dirección a abstrascciones, y una abstracción es una forma disciplinada de ignorancia. Demasiados proyectos fallan por “detalles” de performance, sutilezas de APIs,e interconexión de componentes – o, a lo sumo, descubren este tipo de problemas tarde.
...Mas alla de aconsejar y comunicarse con los desarrolladores, los arquitectos deben participar tambien en la implementación.
El Arquitecto debe estar unido organizacionalmente con los desarrolladores y debe escribir codigo él mismo.

Concuerdo cien por ciento. La mejor forma de orientarse hacia una posición de liderazgo técnico es dominar los aspectos de implementación y no sólo focalizarse en grandes abstracciones.