Gestionar mentes

El factor humano es diferencial en gran cantidad de actividades. 

Lo es para bien... y en ocasiones para mal. Nos permite alcanzar los mayores logros, pero también experimentar las mayores dificultades.

En su libro 'The mythical man-month', Frederick P. Brooks, Jr. hace esta afirmación

managing large programming projects is qualitatively different from managing small ones, just because de number of minds involved.

En la cita original, esta frase no tiene una gran importancia. Le sirve al autor para introducir los problemas de la complejidad de gestión de grandes proyectos software y revisar su propuesta de conformación de equipos.

Pero a mi me ha dejado pensando la expresión 'number of minds'. 

Y me llama la atención porque el autor no ha elegido la palabra 'people' (personas), o 'programmers' (programadores), o 'resources' (recursos) o 'team members' (miembros del equipo)...

Haber elegido cualquiera de las palabras anteriores referiría fundamentalmente a un problema únicamente de número, de escala y, quizá, de interrelación. Sería un asunto básicamente cuantitativo.

Pero no.

No sé si intencionadamente, el autor ha elegido la palabra 'minds' (mentes).

Y una mente nos habla de una persona, una inteligencia y una personalidad. Nos habla de sentimientos, nos habla de motivaciones, nos habla de creatividad, nos habla de voluntad...

Y eso es, realmente, mucho más difícil de gestionar que simplemente un número, por grande que éste sea.

Gestionar mentes supone una mucho mayor exigencia de conocimientos, de habilidades, de liderazgo,..

Para gestionar mentes, no bastan solamente técnicas u organización. 

Para gestionar mentes se necesitan otras mentes, otras personas.

Factor humano para sacar lo mejor del factor humano...

El software y la segunda ley de la termodinámica

A estas alturas tengo bastante olvidados los fundamentos de la termodinámica, pero vagamente recuerdo  dos cosas acerca de la entropía.

Una, que la entropía, de alguna forma, representa el desorden de un sistema... o del universo.

La segunda es que, según la segunda ley de la termodinámica, la entropía tiende siempre a aumentar, no disminuir.

Busco, en efecto la formulación del Segunda Ley de la Termodinámica en wikipedia y me encuentro:

La cantidad de entropía del universo tiende a incrementarse en el tiempo.

Y ahora vuelvo mis ojos al mundo del software y a lo que de él nos dice Frederick P. Brooks Jr. en su libro 'The mythical man-month'. Y, ya hacia el final del libro, cuando el autor está recapitulando las enseñanzas que ha intentado transmitir, y hablando del mantenimiento del software, afirma lo siguiente:

All repairs tend to destroy structure, to increase the entropy and disorder of a system.

¿Podía ser de otra manera?

El software es un sistema y, como hemos visto, un sistema caracterizado por su complejidad. Es casi científicamente poético pensar que el software aplique principios de la termodinámica. Pero lo cierto es que a medida que evoluciona la funcionalidad, a medida que se corrigen errores y aplican parches, el software tiende a deteriorarse. 

Quizá es que se pierde esa integridad conceptual de que ya hablamos en su momento, quizá es que se pierde conocimiento e incluso cuidado a medida que el código original pasa por varias manos... o quizá es que, simplemente, no se puede ir en contra de las leyes de la física.

Lo cierto es que el software se deteriora con el mantenimiento... y acaba convirtiéndose en obsoleto, inservible y, paradójicamente, inmantenible.

Triste para el arquitecto o desarrollador iniciales...pero buenas noticias para los desarrolladores en general, para el sector en general. Si el software se deteriora, hay que hacer nuevo software que lo sustituya... y la rueda, y el negocio, siguen girando.

Así, y ahora sí que poéticamente vamos a contradecir a la física y a su conservación de la energía, el software sólo se crea y se destruye...pero no se transforma (bueno, no mucho).

#macrotweet: sobre el papel del gestor de equipos

The manager's function is not to make people work, it is to make it possible for people to work.

Frederick P. Brooks Jr.

'The mythical man-month'

Software y complejidad

El software es algo casi mágico: moldeable, flexible, potente... 

...y sin embargo es también una fuente casi inagotable de quebraderos de cabeza: proyectos que se retrasan casi sistemáticamente, 'bugs' que resisten cualquier depuración, comportamientos inesperados, 'cuelgues'... y degradación con el uso.

¿Qué pasa con el software?

Quizá simplemente le hemos perdido injustamente el respeto, quizá lo hemos menospreciado y lo hemos considerado algo familiar y del día a día, al alcance de todos cuando, en realidad, el software es enormemente sofisticado.

En su libro 'The mythical man-month', Frederick P. Brooks Jr. nos lo dice de forma muy clara: se trata de que el software es, por naturaleza, complejo.

The complexity of software is an essential property, not an accidental one.

Y no es extraño. Una gran parte de la magia del software es su capacidad de adaptarse a situaciones y datos diferentes. Ese comportamiento flexible y aparentemente inteligente indica una lógica compleja y una gran cantidad de combinaciones y caminos posibles. Por eso mismo, no sólo se trata de que sea inherentemente complejo sino que, además, dicha complejidad crece mucho con el tamaño, cuando los caminos se multiplican:

Many of the classical problems of developing software products derive from this essential complexity and its nonlinear increases with size.

Y si esto ya lo hace difícil de producir y mantener, Brooks nos apunta una última dificultad de cara al diseño:

software is difficult to visualize

Es decir, trabajamos con una materia intangible, muy compleja, con muchas variantes y caminos y queremos aprehenderlo en nuestras mentes...pero no se deja visualizar ni reducir fácilmente a esquemas.

¿A alguien le puede extrañar que sea de tan difícil gestión? ¿Nos sorprende que no se deje domesticar?

Desde un punto de vista de gestión y dirección de proyectos no podemos dejar de lamentarlo pero, seamos sinceros y reconozcamos, aunque sólo sea por un momento que, para nuestra alma de desarrolladores, para nuestra vena de innovación, esa complejidad, ese reto, esa dificultad...forman parte también de la magia...

Hardware versus software: ¿Quién corre más?

Es indudable el ritmo acelerado de innovación al que están sometidas las tecnologías de la información tanto en lo relativo a hardware y materiales, como a software y aplicaciones.

Ambas facetas avanzan a gran velocidad pero ¿hay alguna que corra más que otra?

No tengo datos que lo avalen pero sí tengo la sensación de que la tecnología software, no las aplicaciones, sino la tecnología e ingeniería de software propiamente dichas, están algo estancadas. Tengo la sensación de que dado el rapidísimo avance del hardware, dado que las capacidades de todo tipo de dispositivos crecen rápidamente, el software simplemente 'se aprovecha' y gana en prestaciones y posibilidades no tanto por méritos propios como por lo que el hardware ofrece.

Algo se avanza probablemente en lo que a productividad se refiere, pero no tanto en tecnología pura.

Por el contrario es sorprendente la velocidad a que avanza el hardware. Cómo se gana en capacidad de procesamiento y en velocidad, cómo se avanza en miniaturización, en optimización del uso de la energía o en nuevos materiales y tecnologías como la táctil.

Insisto en que son meras impresiones, y discutibles,..pero que no puedo evitar.

Hace ya muchos años, en su libro 'The mythical man-month', Frederick P. Brooks Jr. parecía contemplar un parecido fenómeno. Sin embargo, me gusta su enfoque que más bien concedía el mérito al hardware, más que hablar de un demérito del software.

Esto es lo decía:

the anomaly is not that software progress is so slow but that computer hardware progress is so fast.

Ésto lo afirmó hace muchos años, pero creo que sigue siendo válido, que aún tiene razón. El hardware parece avanzar más rápido que el software... pero probablemente lo admirable sea realmente la velocidad del progreso del hardware y no tanto el ritmo, probablemente menor, de avance del software.

Lo que tu jefe necesita saber de tu proyecto

Por supuesto, existen muchas naturalezas de proyectos, muchos jefes y muchos estilos de gestión, pero como regla general, si quieres saber qué debes contar a tu jefe o a la alta dirección sobre tu proyecto, puedes seguir la sencilla receta que nos proporciona Frederick P. Brooks Jr. en su libro 'The mythical man-month':

every boss need two kinds of information, exceptions to plan that require action and a status picture for education.

Así de sencillo. Sólo dos cosas:

• estado del proyecto


• excepciones que requieren actuación

Desde luego, es una receta simplificada, pero eficaz. Añadiría que si, además, las excepciones no son demasiado frecuentes y si el plan se cumple, tu jefe vivirá muy tranquilo... y tú también...

Usar y tirar: un duro pero quizá inevitable peaje de la innovación

Cuando innovamos, cuando creamos algo nuevo, es fácil y hasta deseable, enamorarnos de nuestra idea, de nuestro producto, de nuestro intento.

Pero a pesar de nuestra pasión, ese primer intento suele estar condenado al fracaso.

Aparte de la imprevisibilidad de clientes y mercados, la propia naturaleza humana parece poco preparada para la proyección y la planificación minuciosa. Parece que funcionamos mejor de forma empírica, ensayando, fallando y aprendiendo.

Y eso se refleja, por ejemplo, cuando construimos un nuevo sistema software, cuando creamos un nuevo concepto o utilizamos una nueva tecnología. A pesar de nuestro empeño e ilusión, el resultado no suele ser satisfactorio... y debemos tirarlo.

Por ello, al innovar conviene estar preparado, e incluso planificar, para hacer un primer prototipo, e incluso una primera versión de producto para usar y tirar.

En esta línea se manifiesta Frederick P. Brooks Jr, en su libro 'The mythical man-month' cuando nos dice:

Where a new system concept or new technology is uded, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.

Hacer esa primera versión nos ayuda a depurar el proceso y la propia idea. Y su lanzamiento nos brinda la oportunidad de recibir feedback de mercados y clientes.

Decíamos que ese primer intento suele estar condenado al fracaso... pero eso no significa en absoluto el fracaso del proyecto, ni de la idea, ni de la innovación. Aunque no sea lo más eficiente, sí parece ser lo más efectivo comenzar por un primer producto o versión de usar y tirar y, con el aprendizaje obtenido, desarrollar una nueva versión que, si la suerte y el acierto nos acompañan, ya tiene posibilidades de ser un éxito.

'Dura lex sed lex' (ley dura pero ley) que nos decía el derecho romano...