[14 de 97] Una linea de codigo funcional equivale a 500 de especificaciones.

El axioma de hoy (tomado del libro 97 things Every Software Architech Should Know) dice:

"Una línea de código funcional equivale a 500 de especificaciones."

Allison Randal. 

Allison Randal Es arquitecto en jefe y principal desarrollador del proyecto Parrot.
Con más de 25 años como programadora, ha desarrollado de todo, desde juegos hasta herramientas de análisis linguisticos pasando por websites, compiladores y demás.

[NT. El título original del axioma es: One line of working code is worth 500 of specification]

Aquí parte importante del axioma:

Design is a beautiful thing. A systematic, detailed presentation and review of a problem space and solution reveals errors and opportunities for improvement, sometimes in a startlingly dramatic way. The specifications are important because they provide the pattern for building. Taking the time to think through the architecture is important, both on a macro level with an eye for interactions between components and on a micro level with an eye for behavior within a component. 

Unfortunately it's far too easy to get wrapped up in the process of design, enthralled by architecture in abstract. The fact is that specifications alone have no value. The ultimate goal of a software project is a production system. A software architect must always keep an eye on this goal, and remember that design is merely a means to an end, not an end in itself. An architect for a skyscraper who ignored the laws of physics to make the building more beautiful would soon regret it. Losing sight of the goal of working code spells serious trouble for any project.

Value the team members who work on implementing your vision. Listen to them. When they have problems with the design, there's a good chance they're right and the design is wrong, or at least unclear.  It's your job, in these cases, to modify the design to meet real-world constraints by working with your team members to determine what works and what does not. No design is perfect from the start; all designs need to be modified as they are implemented.

If you're also a developer on the project, value the time you spend writing code, and don't believe anyone who tells you it's a distraction from your work as architect. Your vision of both macro and micro levels will be greatly enhanced by the time you spend in the belly of the beast bringing it to life.

Para este axioma iniciaré con una anécdota,  y compartiré dos refranes que según una encuesta, forman parte de los 150 refranes más utilizados en este país del águila devorando a la serpiente, todo esto con el único fin de contextualizar la reflexión del axioma y evitar lo más que se pueda una mala interpretación.

Va la anécdota:
Hace ya varios años, estábamos a punto de liberar una aplicación sencilla a producción: el objetivo de la aplicación era poner a prueba el uso de una herramienta para la creación de flujos de trabajo, está demás mencionar el nombre de la herramienta. Honestamente, la herramienta era muy buena para construir flujos básicos y escenarios no tan complejos, su único punto débil era la complejidad requerida para meter código personalizado en algún punto del flujo.
Para no hacer el cuento largo, ocurrió lo siguiente: la aplicación funcionó de maravilla en los ambientes de: desarrollo, integración, y QA, pero, al momento de llegar a producción, la ingrata (sí, ingrata) herramienta no lograba procesar adecuadamente un stream de bytes que contenía una imagen. El mensaje de error (como siempre muy descriptivo en este tipo de herramientas) decía algo más o menos así : el stream no es válido.

El encargado de ese fragmento de código se negaba a realizar cambio alguno pues indicaba que el código había pasado sin problemas todos los ambientes y no tenia caso poner en riesgo el entregable completo; además de que, la única manera de encontrar la posible falla era agregando código para "loggear", lo cual  iba en contra de las "mejores prácticas" del uso de la herramienta.
Doy mi palabra que, como ocurre en las películas, durante la discusión para encontrar como solucionar el problema tuve un flashback  y llegó a mi mente, cual albatros estrellándose en mi frente,  la noción de que el EOF en algunos lenguajes se podía substituir por la constante -1.
La solución:  se agregó un -1 al final del stream. Con eso la recuperación del stream funcionaba bien en todos los ambientes.

¿Por qué en el ambiente de producción no funcionaba el código original? nadie logró dar una explicación totalmente convincente, el asunto fue que, con esa "maniobra" todos vivieron felices para siempre (bueno, realmente vivieron felices en lo que les cambiaron la herramienta por otra mas popular)

Van los refranes:

• "Ni muy MUY, ni tan TAN"
• "Ni tanto que queme al santo, ni tanto que no lo alumbre"

Va la reflexión:
¿Entonces? todo lo que hemos reflexionado sobre: diseño, patrones, integración continua, etc,etc... ¿Está demás?
La respuesta es, por supuesto que no está demás,  al contrario la idea de todas estas reflexiones es tratar de  analizar y compartir los axiomas del libro para poder, entre todos, mejorar nuestros procesos de desarrollo de software y, de ser posible, reflejar esas mejoras en nuestra vida diaria. ;)

Creo que Allison lo explica en estas líneas(parafraseando):

Tomarse el tiempo para pensar en la arquitectura (de la aplicación) es importante: tanto a alto nivel, para poder visualizar las interacciones entre los componentes; como a bajo nivel, para poder ver el comportamiento dentro un componente.
Desafortunadamente, es muy fácil envolverse en el proceso de diseño, cautivados por la (definición de la) arquitectura (muy) en abstracto.
{...}
El objetivo final de un proyecto de software es (llevar/poner) el sistema en producción.
Un Arquitecto de software siempre debe mantener claro ese objetivo, y recordar que el diseño es simplemente un medio para tal fin, no el fin en sí mismo.

Entiendo que, esas líneas podrían orillarnos a calurosas reflexiones filosóficas o incluso (pro/anti) maquiavélicas pero, creo que de momento, podemos abstraernos a un nivel no tan alto. XD

Cómo ya hemos dicho, y seguiremos diciendo, el truco será siempre, encontrar el sabio equilibrio.
Discutir y compartir opiniones seguramente nos ayudan a tener un mejor criterio para decidir y alcanzar este equilibrio, así que, como siempre.... agradezco desde ya sus valiosos comentarios.  ;)

Saludos y buena semana a todos!!!



---
RuGI
Isaac Ruiz Guerra.

Imagen tomada de: http://en.wikipedia.org/wiki/File:Lewis_Hine_Power_house_mechanic_working_on_steam_pump.jpg

Posted at 12:05AM sep 06, 2009 by Isaac Ruiz Guerra in 97things  |  Comentarios[3]