Un viejo dicho reza "somos lo que comemos"...

Si en un futuro lejano, un ser de otro planeta quisiera conocer nuestro mundo, le bastaría asomarse a nuestra basura.

Con ver cualquier depósito sabría todo sobre la humanidad: qué nos motiva, qué apreciamos, lo que amamos y cómo amamos, en qué creemos, cómo vestimos, en qué nos transportamos, qué nos quita la sed y qué comemos...

Así que también "somos lo que desechamos".

Hace un tiempo, describíamos la arquitectura de los sistemas que desarrollamos en Podemos. Nos enfocamos en describir la misma, una arquitectura de capas, con las clásicas Modelo, API e Interfaz. El post además habla de los límites que debe haber en el código que se coloque en cada uno.

De ese artículo podemos extraer también algunos puntos importantes.

Configurar una aplicación es la manera en que los programadores le damos al usuario capacidades para que el programa sea más potente por sí mismo, sin depender de tener que hacer más cambios y programarlos. Es, de entrada, la puerta con la que el usuario se puede empoderar para hacer un mejor uso de la información que el programa le entregará. Y por eso es una parte importante y esencial de un software bien implementado. Cuando se diseña un sistema, se tienen que tomar muchas decisiones, y hacerse muchas preguntas.

En la última entrada, hice alusión a que el debuggeo de un programa puede ser visto como una especie de juego de detectives, hay un crimen por resolver y pistas que deben llevar al origen de la falla, que luego se deberá resolver.

Resulta que en desarrollo de sistemas, las analogías de juegos abundan. Y un escenario donde también disfruto jugando es mientras sigo una metodología de trabajo en particular a la hora de estar programando.

Debuggear* es todo un arte.

De hecho casi todo en el desarrollo de software y sistemas es un arte. Al menos así lo vemos aquí.

El arte detrás de esto está en la parte creativa, en la parte donde creas algo que al usuario le resulta útil. E implica muchísimas habilidades que caen en el rango de 'artes'. Es un arte poder entender una necesidad y luego plasmarla en un software (empezando por la interfaz y terminando por la arquitectura, o al revés). Es un arte diseñarlo. Es un arte realizarlo.

Y también es un arte depurarlo.

"The Art of Unix Programming" es un libro de Eric S. Raymond. A quince años de haber sido escrito considero que ha envejecido bien. Todo el contenido hace que el título cobre sentido: programar en Unix es nada menos que un Arte.

Es éticamente mejor usar software libre (y en nuestro caso desarrollarlo también), porque la cultura de compartir y ayudar a los demás, propia de la esencia en la que surge el software libre, es 100% compatible con nuestros valores: Nuestro legado es lo que hacemos por otros, no lo que hacemos por nosotros ; Somos una tribu; cuidamos, valoramos y desarrollamos a todos nuestros miembros.

Mas sobre el motto de nuestra área

El diseño y desarrollo de software tiene en su caja de herramientas varias joyas que resultan vitales al momento de hacer sistemas de cierto tamaño. Uno de ellos es el principio K.I.S.S. Este post es un ejemplo práctico de su aplicación

Todos tenemos una manera particular en la que trabajan nuestros cerebros para resolver un problema. O para atender nuestra rutina diaria en el trabajo (o cualquier lugar) también.

En el caso de los que programamos sistemas, me gusta la idea de pensar en construir una casa de cartas...