archivo

Archivo de la etiqueta: Frederick Brooks

Comenta Frederick Brooks en su libro “The Mythical Man Month” que: “La mayoría de la documentación falla en que se da muy poca visión global. Se describen los árboles, se comentan la corteza y las hojas pero no hay un mapa del bosque”.

Estoy bastante de acuerdo con esa afirmación ya que resulta complejo obtener una visión global del sistema simplemente con la lectura de la documentación del proyecto porque como dice Brooks la información está segmentada y se describe con más o menos detalle cada uno de esos segmentos pero no el funcionamiento en conjunto de todos ellos.

Y todo esto en el caso de que haya alguien que revise la documentación de manera más o menos concienzuda, porque esa es otra, se pueden invertir innumerables horas de trabajo en tratar de hacerla con la mayor calidad posible, pero al final hay personas que tienen que leerla y entenderla y no suele haber gente con mucho tiempo y/o paciencia para iniciar sobre ella un proceso iterativo de revisión y mejora.

Esto es un problema importante cuando se desarrolla basado prácticamente en exclusividad en la documentación y no se suple esa carencia a través de la comunicación con personas que puedan ofrecer la información necesarias para cubrir los huecos en la misma lo que provoca generalmente problemas de coherencia en el sistema y aspectos funcionales a los que el desarrollador da una solución sin entender realmente qué lugar ocupa esa funcionalidad dentro del sistema.

La solución, como comento en el párrafo anterior, es la comunicación y además (y en lo posible) en explicar lo que tiene que hacer el sistema y las expectativas del usuario a quien no haya tenido la oportunidad de conocerlo, algo que generalmente (y desgraciadamente) no se suele hacer.

Todas las medidas que supongan un obstáculo a la comunicación entre los componentes de un equipo de trabajo o entre equipos de trabajo diferentes suponen una resistencia importante al proyecto de desarrollo de software.

Se pueden establecer ciertas reglas orientadas a conseguir un mayor orden y una comunicación más eficiente pero es necesario evitar todas aquellas que creen entre personas y equipos que den lugar a que la comunicación sea mayoritariamente asíncrona (cuando no prácticamente inexistente) provocando un distanciamiento entre los equipos (no se trata de un hecho físico ya que pueden estar distanciados equipos que incluso trabajan en la misma sala), la aparición de antipatrones como: “Arrojar al otro lado del muro y que las funcionalidades se desarrollen o las decisiones se tomen sin contar con toda la información disponible lo que dará lugar a unos mayores costes debido al más que probable incremento del número de iteraciones necesarias para tener el producto.

A veces la comunicación se deteriora por conflictos entre personas o entre equipos que provocan que como medida de autodefensa se pongan como un escudo que dificulta o impide la comunicación. Por el bien del proyecto y de las personas que participan en él este tipo de situaciones hay que atajarlas cuanto antes y no dejarlas ir porque cuando se entra en enfrentamientos personales los mismos no terminan por arte de magia cuando acaba el proyecto.

También los gestores cuando no tienen una visión global tienen mucha que ver con el aislamiento de los equipos de trabajo.

Frederick Brooks en su libro “The Mythical Man Month” comenta lo siguiente: “Entonces, ¿cómo se comunicarán los equipos unos con otros? De tantas formas como sea posible”.

Para Fred Brooks: “Incluso la mejor planificación no es tan omnisciente como para hacer las cosas bien a la primera”.

Eso es importante tenerlo en cuenta si pretendes contratar un software llave en mano o si te quieres encerrar en las limitaciones de un análisis de requisitos.

Lo puedes tratar de hacer de la mejor forma posible, con un espíritu de colaboración fantástico con el área usuaria, con estudios de mercado y/o de otros productos similares, con grandes técnicos, pero al final, la realidad y el camino lo marca el software que estás desarrollando y hasta que este no se empieza a utilizar en un contexto real por parte de los usuarios no se obtendrá el feedback necesario para acercar el producto a las expectativas reales que se tienen de él.

Llegado un momento se toma la decisión de hacer una nueva versión de un sistema de información porque se entiende que está obsoleto tecnológicamente (resulta complicado encontrar desarrolladores para ese lenguaje de programación, el sistema de gestión de base de datos o el servidor de aplicaciones ha quedado sin soporte, etc…) o porque el coste de mantenimiento es muy alto y es necesario hacer modificaciones sobre funcionalidades ya existentes o el desarrollo de otras nuevas, etc…

Ese producto de partida conseguía su propósito y era utilizado de manera productiva por los usuarios y por la organización (lo cual no quiere decir que todo su camino para llegar a esa situación fuera sencillo o que nunca hubiera problemas).

Este antipatrón surge cuando se quiere aprovechar el nuevo sistema para incluir todas (muchas) las “cartas a los Reyes Magos” que usuarios, gestores y desarrolladores habían estado guardando todos estos años (más otras que se le ocurran sobre la marcha).

Una mala selección de las mismas dará lugar a un nuevo sistema que habrá sobrepasado con creces el presupuesto de partida, sin que exista un incremento de valor proporcional, mucho más grande que el que realmente se necesita, igual o más complejo de mantener que el anterior, en el que que tendrá problemas a la hora de implantarse porque será mucho más difícil de utilizar y administrar y con una más que probable importante tasa de errores y deficiencias funcionales de partida.

Arreglar esta situación es muy complicado, en algunos casos casi que lo más recomendable es empezar de nuevo.

A todo esto hay que añadir que el sistema anterior pesará como una losa sobre los desarrolladores porque los usuarios (los del día a día, más que aquellos que han intervenido en la definición de la nueva versión) siempre lo tendrán como referencia y lo estarán comparando continuamente y además, y sobre todo, los gestores verán como procesos que antes se desarrollaban de manera eficiente ahora cuesta más trabajo hacerlos, con el consiguiente coste económico que eso tiene, y pedirán cuentas por no tener un retorno de la inversión a la altura del desembolso realizado. Todo esto creará una situación de presión y unas prisas que poco bien harán para la mejora paulatina del sistema.

El término “Efecto segundo sistema” fue utilizado por primera vez por Frederick Brooks en su libro “The Mythical Man-Month”.

La creatividad de los desarrolladores de software es una de sus grandes virtudes (tal vez la que más) y mal empleada, uno de los mayores defectos.

Hay veces donde hay que crear, otras donde el trabajo a realizar está restringido al ámbito de un proyecto y donde resultas más conveniente ser práctico que complicar un desarrollo por intentar saltarse sus propios límites o el propio contexto en el que se encuentra el proyecto.

Teniendo en cuenta que la creatividad produce resultados y puede marcar diferencias si se aplica en aquellos proyectos y ámbitos donde es necesaria, resulta de interés crear el contexto adecuado o caldo de cultivo donde la misma pueda ser expresada, sin olvidar de lo necesario que resulta educar a los desarrolladores sobre los momentos en que resulta más adecuado ceñirse al guión establecido.

Me gusta esta reflexión de Frederick Brooks porque ofrece una visión romántica de lo que es un programador (traducción libre): “El programador, como el poeta, solo funciona si se encuentra un poco retirado de lo estrictamente racional. Construye sus castillos en el aire, desde el aire, creando a través del esfuerzo de la imaginación. Pocos medios de creación, son tan flexibles, tan sencillos de pulir y reconstruir y tan fácilmente capaces de concebir grandes estructuras conceptuales”.

Hay una cita de Fred Brooks que expresa varias problemáticas en los proyectos de desarrollo de software y en la gestión de las carreras profesionales en las empresas que se dedican a este negocio: “La conclusión es simple: si un proyecto de 200 personas tiene 25 gestores que son los programadores más competentes y experimentados, despide a los 175 programadores y pon de nuevo a los gestores a programar”.

– Es mejor la calidad que la cantidad.
– En cada rol en un proyecto debe estar el personal más adecuado para el mismo.
– Muy pocas personas son excelentes en todos los perfiles del desarrollo de software.
– La gestión vertical de las carreras profesionales es una autolimitación nada razonable que se ponen a sí mismas las empresas.

Llegado un punto el sistema de información empieza a deteriorarse. Existen funcionalidades que dejan de usarse o su utilización residual y que no se eliminan, hay errores que persisten versión tras versión y que afectan a la calidad del dato y a la adecuada realización del proceso a través del sistema, en lugar de mantenerlo lo más simple y funcional posible se añaden funcionalidades cada vez más complejas y que no proporcionan el valor esperado y/o dificultan el mantenimiento, etc…

El sistema crece y llegado un punto resulta complicado de controlar, sobre todo en proyectos grandes. Es complicado en estos casos tener una visión global de todo y no caer en errores que contribuyan a ese deterioro.

Por otro lado tenemos también tanto la corrección de incidencias y la adición de funcionalidades que conllevan en muchos casos la introducción de nuevos errores en el sistema ya sea en el propio código que se corrige o en el módulo que se añade o provocado por efectos colaterales en otras secciones del código y funcionalidades de la aplicación.

Frederick Brooks que dirigió el desarrollo del sistema operativo OS/360 sabe muy bien a que se refiere cuando habla de los inconvenientes del mantenimiento, sobre todo en proyectos complejos, de tamaño moderado y con grandes equipos de trabajo y su posible repercusión en el deterioro de la aplicación y lo podemos apreciar en su siguiente reflexión: “El problema fundamental del mantenimiento de un programa es que la corrección de un defecto tiene una probabilidad importante de introducir otro”.