La mayoría de mis amigos saben que soy aficionado al automovilismo, pero principalmente a la Fórmula 1. Realmente no recuerdo cuando empecé a ver las carreras de F1 supongo que fue hace muchos, muchos años por Imevisión. Hoy no voy a hablar estrictamente de las carreras, pero sí de que me intriga la manera en como trabajan los ingenieros de esos autos.
Recuerdo un comentario de Ron Dennis, CEO de McLaren, quien decía que prefería tener un auto rápido y que fallara de vez en cuando, que uno lento y confiable. Mencionaba que para McLaren era más fácil resolver los problemas de confiabilidad de un auto rápido, que resolver los problemas de velocidad de un auto lento. Todo esto encaja perfecto con la filosofía del equipo, quien siempre se ha caracterizado por tener los autos más veloces y competitivos de la categoría. También recuerdo alguna vez a Eddie Jordan, hasta hace poco dueño de Jordan Grand Prix, diciendo que prefería tener un auto que no se rompiera, argumentando que para ganar una carrera primero había que terminarla. Esa filosofía los llevó en 1999 al tercer lugar en el Campeonato de Constructores y a un sorpresivo tercer lugar en el Campeonato de Pilotos con el ahora piloto de DTM Heinz-Harald Frentzen.
Ahora bien, independientemente de que las cosas vayan bien o vayan mal, el ciclo de vida de los autos en la Fórmula 1 es un tanto caprichoso. Es decir, en enero y febrero se presentan los autos nuevos que competirán en el campeonato que iniciará en marzo. Pero muchos equipos, para mayo o junio, ya han sacado la versión A, B, II, 2 ó MK8228-Robobestia-Destruye-Mazzingers-y-Ferraris (dependiendo de la nomenclatura que siga cada constructor), con lo que se pretenden corregir problemas de confiabilidad (quienes tienen autos que se rompen), problemas de velocidad (quienes tienen autos que no avanzan) o problemas de personalidad (quienes tienen autos introvertidos). Todo esto mientras Ferrari sigue ganando tres de cada dos carreras.
Aún así, a final del año, el auto será desechado para construir uno mejor para el año siguiente. Se invierten miles y miles de horas/hombre en el diseño de cada auto, y unos meses después se reemplaza por algo que es, en gran medida, completamente nuevo. Y es que, utilizando términos de ingeniería de software, los autos son altamente cohesivos, pero también tienen mucho acoplamiento. Siendo un tanto simplista, quiere decir que un cambio en un componente, generalmente requiera cambios en muchos otros también.
Y una vez que he llegado a esa analogía, me he estado preguntando si se podría hacer una comparación entre la ingeniería de autos F1 y la ingeniería de software. Es decir, existe la reingeniería de software, y existe el refactoring para arreglar el código, pero una vez que los sistemas están implantados y funcionando, se vuelve relativamente complejo darle mantenimiento y se va deformando poco a poco hasta que la aplicación se transforma en un monstruo a quien todo el equipo de desarrollo teme (Me han contado).
¿Qué tan factible sería que el equipo de desarrollo entregara una versión terminada del software y conforme pasara el tiempo, el equipo de mantenimiento adecuara el sistema a los nuevos requerimientos, mientras el equipo de desarrollo trabajaría en la nueva versión (y no una actualización más) que sustituiría por completo a la versión antigua?
Nos hemos dado cuenta que dar mantenimiento a un software es muy costoso y es algo que no se puede predecir al firmar el contrato y no siempre se puede cobrar como debería. Y lo que obtenemos al final es un sistema lento o poco confiable (si bien nos va, sólo tenemos uno de los dos problemas (no hablemos de los problemas que se tienen cuando el auto(o el software) se comporta de manera inesperada en la pista (o en la computadora) resultando en un desempeño poco competitivo (y terminando con un auto como servidor de bases de datos y una computadora en cuatro ruedas con casco en vez de monitor(que por cierto obtienen mejores resultados)))). Se debería vender el sistema dos veces, la versión uno funcionaría medio o un ciclo completo de transacciones de la empresa (normalmente un año). Entraría a los pits periódicamente para ajustes y reparaciones, pero al cumplir el plazo, el software regresaría a los pits para nunca más salir a la pista. En su lugar se echaría a andar la segunda versión la cual ya habría aprendido a sortear los problemas a los que se enfrentó la versión uno, además de que sería más confiable, rápida y, muy importante, más fácil de reparar cada vez que ingresara a los pits.
En la Fórmula 1 funciona, 2 equipos de desarrollo trabajan sobre autos distintos, uno para explotar el actual a su máximo potencial y otro trabajando en el que sustituirá al primero. El ciclo se repite y terminamos teniendo un auto que corre durante 6 meses, pero se trabaja en él durante un año. Tal vez eso sea lo que necesita el software, puede ser que el cliente termine pagando un poco más, pero también tendrá un producto final tanto confiable como veloz, que es lo mismo que buscan los equipos de F1. Por otro lado, esto no ha impedido que Ferrari gane los últimos seis Campeonatos de Constructores, ni que Schumacher haya ganado los últimos cinco Campeonatos de Pilotos, tal vez exista un error en esta filosofía. Puede ser que ni McLaren esté excento de problemas de calidad. Tal vez yo esté intentando corregir el hilo negro (ya antes lo había inventado(un poco antes de reinventarlo)). Quizá haciendo refactoring se evite que el software termine en la trampa de arena o averiado a mitad de la pista sin posibilidad de reparación. Son demasiadas posibilidades, pero hay 3 verdades absolutas (y simples) en el blog de hoy:
1) Hasta Minardi evoluciona constantemente sus autos.
2) No se ha comprobado que las metodologías ágiles para el desarrollo de software diseñen un mejor auto de F1.
3) Siempre se puede hacer una analogía con la Fórmula 1.
No hay comentarios.:
Publicar un comentario