Climens Codelog

No suelo escribir sobre actualidad pero la ocasión lo merece, porque el anuncio me ha gustado y encuentro que es una gran iniciativa por parte de Google: Google Doctype.

La idea del gigante, llevada a cabo por Mark Pilgrim, autor de un par de libros (Dive into Python y Greasemonkey Hacks) es sencillamente un wiki sobre desarrollo web (HTML, CSS, Javascript, ...) bajo una licencia Creative Commons Attribution y permitiendo a todo el mundo con una cuenta de Google modificar, mejorar y ampliar los contenidos. Incluso se pueden descargar todos los contenidos a través de Subversion.

Desde luego es una iniciativa poderosa, en la que además se presentan código interno de Google en la documentación liberado open source y pretenden convertirse en un referente para todos los desarrolladores web. Viendo el video de Mark (un poco largo y con mucho ruido de fondo), el propósito es permitir a la gente crear webs universales, aptas para cualquier dispositivo, navegador y sistema operativo, algo que cada día es más demandado. ¿Sabías que el iPhone no tiene reproductor Flash? Pues eso deja fuera de juego a todas las webs que usan Flash. El futuro depara una cantidad ingente de clientes web heterogéneos y Google apuesta por el HTML, las CSS y el Javascript como una respuesta a esta situación.

En resumen, que hay un nuevo referente en cuanto a documentación para el desarrollo web, que viene a completar los que hay ahora, como el sitio oficial del W3C o una de mis favoritas: Quirksmode.

Via | Google Doctype: Documenting the Open Web (ajaxian.com)

NIH: Del inglés Not Invented Here. Según la Wikipedia, es un término usado para describir una cultura sociológica, corporativa o institucional que evita el uso de productos, conocimientos o estudios existentes debido a sus orígenes diferentes. Normalmente se usa de forma peyorativa.

Últimamente he estado involucrado en la programación de un sistema de gestión de tickets de posventa para la empresa dónde trabajo y quizás es uno de los ejemplos más claros del tiempo que puede llegar a perderse si uno es un fiel seguidor de la cultura NIH.

Este proyecto, que empezó como una paginita sencilla se ha convertido en uno de los pilares del servicio de posventa de la empresa por lo que, al ganar usuarios también ha ganado problemas. Pero el tema fundamental es: con la gran cantidad de software de este tipo, tanto comercial como libre que hay, ¿de qué sirve hacer un desarrollo interno para eso?

La respuesta, claramente, está en la cultura del NIH. Entre todos habremos dedicado quizás 150 horas o más a este desarrollo, que aun dista bastante se ser óptimo, pero por lo menos es usable. Pero si pienso por ejemplo en 150 horas, por 50€ la hora, tirando por lo bajo haciendo la media del precio por hora de desarrollo que se suele facturar de media (algunas horas valen más que otras ;-)), dan un total de 7,500€ que se podían haber dedicado a otros menesteres.

Algunos me pueden decir que he sido simplista. Bien, quitemos por ejemplo el coste de un software comercial, digamos 1,500€ siendo de los más caros, aun quedan 5,000€. Claro, habría costado de configurar, ajustar, personalizar... pongamos unas 50h o incluso 100h y sería el mismo coste.

Al final, habríamos tenido una herramienta impresionante (por ese precio hay gestores de posventa comerciales que hacen maravillas) configurada a nuestro gusto. Y es que está muy bien vivir del software a medida pero: ¡es carísimo! Así que la próxima vez que alguien plantee un desarrollo interno, hacedle ver que el ROI quizás no es demasiado positivo (eso a los jefazos les gusta, que hablemos en términos económicos).

Curiosamente, navegando he visto que no es un asunto exclusivo del software, la prestigiosa revista Nature (me hacía ilusión, en la prensa siempre lo ponen) tiene publicado un artículo sobre el NIH en investigación médica. Incluso hay un bonito libro sobre NIH en la industria aeroespacial. Si al final no somos tan distintos, reinventar la rueda para que sea propia es muy humano, aunque no es lo mismo competir por ser el más innovador que reinventarla por gusto.

Actualización 26/03/08: He encontrado un excelente artículo sobre el tema: Why we use Ant (or :NIH). via El síndrome NIH.

Hace unos días apareció una pequeño listado de consejos para escribir código más comprensible que me pareció bastante interesante. Los puntos descritos son los siguientes, y en realidad no hacen más que afirmar lo que cualquier programador con experiencia hace en su día a día (y si no, es que la experiencia no le ha servido de mucho):

• Comenta como una persona inteligente
• Usa #define mucho (o lo que equivalga en tu lenguaje favorito)
• No uses nombres de variables ridículos
• Haz comprobación de errores.
• "La optimización prematura es la raíz de todos los males" - Donald Knuth
• No te pases de listo

En fin, que es una lectura bastante recomendable pero lo que realmente me ha llegado ha sido lo que he leido en uno de mis blogs favoritos, "The best code is no code at all".

El objetivo del artículo es hacer comprender que el problema del código es que hay demasiado código, y eso solo trae desventajas. Por supuesto que uno programa con las mejores intenciones pero a veces para solucionar un problema el camino es tan largo y tedioso que es un problema en sí mismo.

Todo se resume a seis parámetros básicos que conforman un hexágono:

• Brevedad
• Cantidad de funcionalidad
• Velocidad de ejecución
• Tiempo de desarrollo
• Robustez
• Flexibilidad

Lo que ocurre es, como tantas otras veces en la ingeniería que aumentar cualquiera de estos parámetros va en detrimento de los otros, así que nada es perfecto a no ser que no sea.

Y no podría estar más de acuerdo con la conclusión y es que la principal dimensión que hay que optimizar es la brevedad. Y tenerla siempre en mente.

Un código breve en general es sencillo de mantener, es comprensible y fácilmente ampliable y corregible por lo que los otros aspectos como la flexibilidad o la robustez pueden ser dejados para más adelante, sin perder de vista la simplicidad y la brevedad.

He visto ya en demasiadas ocasiones que el código crece y crece sin que nadie pare a observarlo y darse cuenta que cada vez se está más lejos de la solución yendo por caminos secundarios y perdiendo de vista el objetivo en una especie de orgía teclística que no va a ningún lugar. A veces hay que parar, leer lo que se está haciendo y pensar si no habrá una forma más simple de llegar a buen fin. Si es demasiado complicado, probablemente esté mal.

Ademas, Jeff hace una referencia a otro atrículo llamado "Code is our enemy", dónde se centran básicamente en lo mismo: se escribe demasiado código y ese es el problema de los programadores, no tenemos medida.

Así que, la próxima vez que os pongáis delante de un editor a programar, pensad en que vuestro código ha de ser breve y sencillo y veréis como a la larga se agradece.