Sobre desarrollo de software

La administración de la energía creativa sería la clave para un proyecto exitoso

Desarrollar software es un proceso que se viene descubriendo.

Hay quienes han intentado amoldarlo a un esquema como el que se sigue en la ingeniería o la arquitectura. Parece funcionar en algunos casos, pero no ha resultado satisfactorio siempre.

Aún hoy, décadas después de creada la ingeniería de software o las ciencias de la computación, a veces no es claro por qué un proyecto de desarrollo que parece bueno fracasa. O por qué uno que parece absurdo temina triunfando sobre todas las demás opciones.

Algo que hay que tener en cuenta es que el software no solamente debe correr en la computadora, sino en el sistema determinado por las personas que lo usen.

La ingeniería de software y las ciencias de la computación suelen concentrarse en cómo crear algoritmos que corran eficientemente en una computadora. La UX, o experiencia de usuario, se concentra en cómo sintonizar con las necesidades reales de las personas que usarán la solución que se desarrolla.

Desarrollar software no es como realizar una tarea, donde cada paso es sobre terreno conocido. Es más como resolver un problema. Es decir, es como avanzar por una curva cuyo curso no es evidente. Hay que recurrir a la experiencia pero también a la intuición. Como cuando se hace arte.

Me parece que la mejor manera de desarrollar software es iterádamente, iniciando con una base muy simple y luego ir evolucionando para alcanzar lo que se requiere.

Esto requiere un proceso de desarrollo que sea sostenible y escalable. Sostenible significa que se pueda repetir una y otra vez el ciclo de mejora. Escalable significa que puede soportar el siguiente estado de evolución del producto.

Muchos desarrolladores se preocupan mucho por si el producto es escalable. De si podrá soportar diez veces más usuarios, o cien veces más datos. Creo que más importante que la escalabilidad del producto es la escalabilidad del proceso para desarrollar el producto.

Creo que la razón principal por la que los proyectos de desarrollo de software a menudo fracasan es porque no logran formar un proceso de desarrollo escalable. Suelen usar un esquema de producción en línea, como en una fábrica donde cada pieza es conocida, en lugar de espiral, como en un laboratorio donde cada pieza se está ensayando sobre un diseño que se va descubriendo. Conforme la complejidad aumenta, distintas partes del proyecto van cayendo bajo su propio peso, hasta que todo colapsa. O sigue adelante con montones de parches y apuntalamientos de emergencia que hacen que no sea posible continuar con su evolución de manera clara.

Quizás esto se pueda ver mejor considerando que existe una energía creativa. Es la energía con la que se cuenta para convertir una idea en un producto de software.

Mientras no se llega a  un un producto concreto, la energía creativa va disminuyendo. Es como cuando un móvil se va empujando. Para que gane altura o gane velocidad, hay que gastar energía empujándolo contra la gravedad o la fricción. Cuanto más largo es el salto, más fuerza, velocidad y energía se requieren.

Pero cada vez que se llega a un producto concreto, ganamos un nuevo punto de apoyo para dar el siguiente paso desde allí. Esta energía permite ir por una siguiente versión. Es más fácil, y más sostenible, llegar al quinto escalón desde el cuarto que desde el primero.

Podemos ilustrar esto imaginando que el proyecto es como llevar una bola de nieve cuesta arriba. Al inicio, reunimos nieve de aquí y de acá y empezamos a rodar esa bola inicial fácilmente. Conforme la bola crece, va requiriendo más energía. Entonces llegamos a una pequeña meseta. Eso nos permite recuperar energía, apreciar lo que hemos recorrido y ver mejor cómo continuar. Luego seguimos subiendo, gastando energía hasta que lleguemos a la siguiente meseta, donde nos recuperamos. En el viaje, vamos decidiendo si necesitamos ayuda de más personas para seguir empujando la bola, despejando el camino, apuntalando, etc. Cada vez requerirá más energía poder avanzar y llegar a una meseta segura. Puede ser que esa meseta sea la cima, y el proyecto llegue así a buen término. Puede ser que no sea la cima pero una meseta cercana y aceptable. O puede ser que no se encontró una meseta a tiempo y, sin un apoyo adecuado ni energía para continuar, la bola se tuvo que soltar, yéndose cuesta abajo.

Versionado frecuente. Una buena estrategia es tener mesetas frecuentes. Es decir, sacar versiones completamente funcionales frecuentemente. No importa si es un paso corto si podemos continuar andando. Los pasos acrobáticos son un lujo que puede no ser sostenible. Los periodos de desarrollo largos que no concretan van consumiendo la energía riesgosamente.

Ir ligero (LEAN). Otra buena estrategia es mantener la bola en un tamaño manejable. Es decir, ir dejando atrás aquello que ya no es necesario para que siempre podamos avanzar con los recursos que tenemos.

Dividir y vencer. Otra buena estrategia es dividir el trabajo en varias bolas que lleguen a la cima. Es decir, poder separar el proyecto en partes independientes y fáciles de manejar que puedan ser conectadas luego.

Testing (TDD). Otra buena estrategia es apuntalar el avance de la bola. Es decir, contar con pruebas de código o de flujo que validen el estado del proyecto. Se pueden poner luego de que la bola ya alcanzó cierta posición pero suele ser mejor estrategia ponerlas primero y luego mover la bola hacia allí.

Sinergia. Otra buena estrategia es rodar armoniosamente la bola. Es decir, que cada persona del equipo sintonice con el propósito del proyecto, y tenga la autonomía que le permita usar sus habilidades con maestría para colaborar en su realización.

La trampa del perfeccionismo. Una estrategia no muy buena es querer empezar con un montón de nieve demasiado grande. Es decir, requerimientos iniciales demasiado complejos, por número o por dificultad. Son más firmes las bolas de nieve que van creciendo y haciéndose redondas por su propio rodar. A menudo, querer empezar con algo que parezca perfecto para impresionar a los demás suele conducir a parálisis por análisis: el proyecto empieza a procrastinar, la energía creativa se diluye, y finalmente no despega.

La trampa de la temeridad. Otra estrategia no muy buena es ignorar la ayuda de apuntalamientos y confiar únicamente en el propio esfuerzo para mantener la bola en curso. Es decir, no tener pruebas que permitan verificar que se está donde se debe estar. Implementar pruebas requiere algo de energía creativa, pero luego permite ahorrar mucha más.

La trampa de la insensibilidad. Otra estrategia no muy buena es ignorar que quienes ruedan la bola son personas. Es decir, se cae en tentación de creer que bastan las herramientas, las técnicas o la infraestructura, o la capacidad de hacer algo, para que ese algo se pueda realizar, ignorando que hay un aspecto social, con una voz que debe ser escuchada y honrada. Hay redes de confianza que deben ser tejidas y mantenidas, para que las personas puedan realizarlo.

Hay proyectos con pendientes de dificultad muy llevaderos, donde parece que se puede ir con facilidad hacia cualquier dirección y se llega a la cima de un modo predecible.

Hay otros proyectos donde el terreno no es parejo, la nieve es irregular y sopla la ventisca.

Llevar exitosamente la bola de nieve a la cima no depende solamente de cuánta gente la empuja ni cuánta fuerza tenga. Depende de ser capaz de llegar oportunamente a las mesetas adecuadas. Es entender el terreno, el clima, la nieve, la gente, su fuerza, sus habilidades, y poder manejar todo eso.

El problema de la sobrecarga innecesaria

Problemas reales

Pienso que resolver problemas es una cuestión de prueba y error.

Que no es como te lo enseñan en la escuela, donde aprendes a copiar soluciones de los libros de texto.

Resolver un problema es como andar a tientas por una habitación a oscuras, tratando de llegar a la puerta.

Lo que te dan los libros de texto son como escenarios prefabricados de juegos con finales conocidos. Llenos de cosas que los maestros han puesto y con rutas de solución que ellos ya conocen.

En los problemas reales, puede haber más de una ruta de solución. O ninguna.

También encontraras montones de cosas que te sirven mezcladas con cosas innecesarias. Y necesitarás aprender a notar cuál es cuál.

Enfrentarte a problemas reales despierta cierto sentido. Aprendes a escuchar al problema. Aprendes a buscar dentro de ti. Aprendes a construir caminos.

Patrones

Conforme vas resolviendo problemas, te das cuenta que se repiten ciertos patrones para solucionarlos.

Identificar estos patrones ayuda a catalogar las soluciones y facilitar su reutilización.

Por ejemplo:

• Qué tal si divido el problema en partes. Si varias de esas partes me son familiares, podría avanzar por allí.
• Qué tal si solo considero algunos detalles (eso se llama abstracción). A lo mejor veo más claro en esa versión simplicada.

Ayuda dividir el trabajo web en partes separadas.

También ayuda quitar de en medio una problemática innecesaria.

MVC

Modelo-Vista-Controlador es un patrón de desarrollo web que divide el trabajo en tres areas:

• Vista: la interfaz de usuario, HTML, CSS, Javascript
• Modelo: los datos que la Vista mostrará
• Controlador: el que orquesta las actuaciones de la Vista y el Modelo

Se trata del patrón Qué tal si divido el problema en partes. La idea es concentrarse en cierto aspecto del desarrollo para simplificar el trabajo.

Componentes

El desarrollo de un site o una aplicación web, no es una tarea definida. Es un problema cuyas tareas hay que ir descubriendo en el camino, durante sucesivas iteraciones. No es ir de la A a la Z y ya. Es ir por las letras de un mensaje desconocido, fallando y acertando mientras se va haciendo más claro.

Para iterar con agilidad, necesitamos poder hacer cambios con facilidad.

¿Ayuda MVC en esto?

MVC ayuda a enfocarse en cierto aspecto del problema y a organizar todas las cosas en esas tres grandes areas. Pero esa virtud también tiene su inconveniente. La navegación por el mar de las posibilidades se vuelve muy, muy pesada. Cierto que sabemos donde queda cada cosa y eso es muy bueno. Pero, por otro lado, la implementación de cada idea se vuelve engorrosa.

Imaginamos las cosas naturalmente como componentes, pero en MVC cada solución o variante que imaginemos tiene que ser dividida en tres partes antes de poder implementarlas. Es un ejercicio constante de traducción entre lo que imaginas y lo que haces para producirlo.

Está bien, pero quizás podría ser mejor.

Entran los componentes.

¿Qué tal si dividimos las cosas no por areas M, V, C, sino por funcionalidades, por componentes?

Es parecido a decir, que tal si en lugar de tener carpetas css, js, images, tenemos varias carpetas home, contact, menu, header, product, etc, cada una representando una funcionalidad o conteniendo otras carpetas de funcionalidades.

Confusiones papistas

Más papista que el Papa, dice un refrán. En algunos proyectos hay personas que adoptan esta actitud de defender algo como cierto porque sí, porque así es.

Gente que toma MVC como una biblia o estresa al equipo que obvia una ceremonia del scrum.

Lo importante es honrar el por qué de las cosas. MVC busca claridad. Scrum busca bienestar del equipo.

¿Los componenentes podrían hacerlo mejor? ¿Podríamos sentirnos menos estresados? Probemos.

El problema en el Frontend

Este es más o menos el flujo de trabajo que se sigue al desarrollar web:

1. Se propone un diseño gráfico base
   Algunos insisten en querer tener todo resuelto en este punto, pero es crear falsas expectativas y sufrimiento innecesario.
   Es importante que el cliente entienda que el desarrollo es iterativo (hablando de eso, también es importante que el equipo de desarrollo lo entienda ^^).
2. El diseño gráfico se maqueta con HTML, CSS y Javascript
   Los datos son hardcodeados.
   Algunos insisten en querer maquetar directamente sobre un framework, pero es crear lastre mental innecesario, además de amarrar la maqueta a ese ambiente.
3. La maqueta es vuelta template, según el framework que se va a usar
   Los datos son mockupeados. Es decir provisto por endpoints que devuelven data hardcodeada.
   Algunos insisten en hacer endpoints reales de una vez, pero también es crear lastre mental innecesario tratar de enfrentar más de un problema a la vez.
4. La aplicación es provista de datos reales
   Ya que las anteriores etapas han resuelto una cosa a la vez, se reduce bastante el número de posibilidades de error en este punto.
5. El cliente quiere un cambio
   Procedemos a iterar.

Aquí es donde se presenta el problema. En la atención de los cambios.

Como las revisiones ya se están haciendo con datos reales, las circunstancias presionan para no ir al paso 1, sino iterar sobre el paso 4.

No se actualiza la propuesta gráfica, ni la maqueta en puro HTML. Se percibe como demasiado engorroso. Se hacen los cambios directamente sobre el template con toda la infraestructura corriendo.

Paradójicamente, eso no es más rápido, ni más seguro.

Para hacer cualquier cambio en el template, con la infraestructura corriendo, tienes todo un ecosistema de base de datos, modelos y controladores funcionando... innecesariamente.

Resolver un cambio en un template es un problema más complicado porque tienes que cargarte mentalmente de todas las convenciones y protocolos del framework, y de todas las circunstancias y problemas que otras areas estén atravesando (que la configuración del entorno ha variado, que por ahora no uses este endpoint sino este otro, que hay un servicio que se ha caído y debemos esperar, etc, etc).

En cambio, hacer los cambios sobre la maqueta es un problema aislado, más sencillo y rápido de resolver.

Creo que es mejor resolver los problemas en la maqueta y luego recién llevar esa solución al template.

Si el paso de convertir una maqueta a template no fuera manual sino automático (o si no existiera), creo que sería más sencillo y rápido hacer cambios de UI.

juno-cheerio y unophp han sido algunas iniciativas personales para automatizar el paso 3. La idea de unophp se puede adaptar incluso para WordPress.

Pero por ahora, tenemos este problema en Frontend: cómo atender con más facilidad los cambios que se requieren durante las iteraciones del proyecto.

Antipatrón

Yo diría que es un antipatrón que el frontend requiera que todo el motor del proyecto, con su base de datos, endpoints, etc, deba estar corriendo para hacer sus cambios.

Es complejidad innecesaria para esa tarea.

Entiendo que en Integración Contínua se prueban las cosas sobre infraestructuras reales corriendo. Es porque necesitan hacer pruebas en ese nivel. Pero hacer el desarrollo en ese mismo nivel no me parece lo más optimo.

Sería mejor poder aislar esa parte a voluntad, poder crear un entorno donde no exista otra complejidad más allá de lo que quieres resolver, hacer el cambio, y luego, mágicamente, incorporarlo al proyecto completo.

UX para todo(s)

Nota: Por favor, lee esto con la mente abierta. Si eres frontend, creo lo entenderás. Si eres backend, por favor, no me malinterpretes; también he hecho algo de backend y muchos de mis amigos son backend. No tengo nada en contra de los backend. Excepto quizás la optimización prematura, el overkill (pero eso es algo que se ve en todas partes), y esto.

Encuentro que hay una discusión entre frontend y backend. Entre los chicos que hacen las interfaces para el usuario y los que preparan la data que se mostrará.

Es más o menos así: los backend pretenden que los frontend tienen que usar sus apis cómo a ellos les de la gana de hacerlas.

Por supuesto pueden esgrimir un montón de argumentos; que el mejor modelamiento de las tablas, que la auto documentación, que la optimización, etc.

Lo que yo digo es solamente esto: imagínate que los frontend pretendiéramos que los usuarios tienen que arreglárselas para usar las interfaces que nos diera la gana de hacer.

¿Que así es como haces tus interfaces de usuario? Detente, stop, para un momento.

Por supuesto que durante muchos años se ha hecho así; con la dictadura de los diseñadores sometiendo al usuario y obligándoles a aprender que la opción que buscaban estaba nada más a cuatro clicks de distancia, debajo de un menú desplegable que actuaba cuanto pulsabas la tecla alt después de escape (bueno quizás no tanto, pero seguramente captas la idea).

Pero la abundante oferta de aplicaciones y la despiadada elección de los consumidores ha hecho que recapacitemos y escuchemos al usuario y qué tipo de experiencia realmente le ayuda a conseguir lo que necesita. Porque lo que la UX busca no es que las interfaces sean más bonitas (es un malentendido de marketing); lo que busca es que las interfaces puedan dar lo que se necesita sin obligar a hacer un esfuerzo innecesario.

Además, mira el nombre, "interfaz de usuario", no dice "interfaz del programador frontend". No se supone que debas sentirte cómodo programándola; quizás tengas suerte y sea entretenido, estimulante, o quizás no y sea un dolor de cabeza y un verdadero desafío cómo resolver una interacción; lo importante es que el usuario pueda sentirse cómodo usándola, sin esfuerzos innecesarios.

Pues bien, del mismo modo, la API que se entrega a los frontend es la interfaz con la que nos comunicamos con la fuente de datos. Una buena API no es aquella que sea cómoda o fácil de programar para los backend; puede que lo sea, si se organizan bien, pero es un rollo interno, que no debe atravesar la interfaz. Porque recordemos que se trata de una interfaz: la comodidad y facilidad deben estar del lado de quién la va a usar.

Un backend debería hacer con el frontend el mismo ejercicio que el frontend hace con el usuario. Observarlo, ver cómo va a usar la API, conversar con él acerca de sus necesidades reales, empatizar.

No creo que necesitemos una especie de Frontend eXperience (no más siglas, por favor), sino que comprendamos que los mismos principios que venimos a reconocer como válidos al aplicar UX son aplicables también a la hora de desarrollar interfaces para otros desarrolladores. Puede ser un API REST, o puede ser una librería, o un framework, o cualquier herramienta en general.

En una interfaz, la comodidad y facilidad deben estar del lado de quién la va a usar. Creo que es el principio que guia a la UX y está ayudando a crear más software realmente valioso para los usuarios. Y creo que es hora que apliquemos lo mismo a la relación frontend-backend (y en todas aquellas donde veamos una interfaz), y ayude a crear herramientas realmente valiosas para desarrollar mejor mejores aplicaciones.

La importancia de solucionar algo

Amazing Grace

A Grace Hopper se le dio el encargo de elaborar el manual de instrucciones de una de las primeras computadoras creadas en los Estados Unidos.

A la Marina, le interesaba averiguar de qué modo podría aprovechar el potencial de la nueva máquina Mark I.

No era común que una mujer perteneciera a la armada, y tampoco tenía los estándares de peso y talla, pero sus habilidades matemáticas le ayudaron a ser admitida y abrirse camino.

Ella propuso organizar bajo nombres más asequibles las rutinas que había coleccionado con su equipo, y un esquema para reutilizarlas con más facilidad y automatizar la generación de las secuencias binarias que eran la forma normal de programar las computadoras en aquella época.

Normalmente, para programar la solución de un problema, había que enfrentarse con el hardware y los interruptores necesarios para implementar el programa. Era como tener que atravesar continuamente una bruma mental para distinguir lo que se quería conseguir.

En cambio, usar un compilador de código tenía la ventaja de permitr pensar con más claridad en el problema que se quería resolver.

Sin embargo, su propuesta fue desechada porque el código binario generado de ese modo era más largo y menos eficiente.

Grace persisitió en ello como un proyecto personal. Desarrollando lo que vendría a ser conocido como lenguaje ensamblador, o Assembler.

Uno de sus amigos, que había estado meses con un equipo tratando de programar la solución de un problema especialmente difícil, logró hacerlo en unas horas usando Assembler.

Poco a poco, el uso del Assembler se fue extendiendo.

Años después, creó COBOL, el primer lenguaje de programación, que permitía expresar un programa en algo parecido a sentencias en inglés.

Menos eficiente pero más eficaz

Hoy en día, prácticamente toda la programación se hace con ayuda de compiladores y los lenguajes de alto nivel que aparecieron luego del COBOL. De ese modo, los problemas no solo se resuelven con más rapidez, sino también con menos errores. Y si los hubiera, son mucho más fáciles de localizar.

La propuesta de Grace de usar lenguajes de más alto nivel para solucionar problemas encontró resistencia en otros programadores que desdeñaban el código binario repetitivo, largo e ineficiente que se producía de ese modo. Ellos podían hacerlo más simple, más elegante, del "modo correcto".

Los programadores que podían programar directamente en binario no eran muchos y quizás se sentían un poco como sumos sacerdotes. Los intermediarios exclusivos entre la gente y las máquinas todopoderosas.

Los lenguajes de alto nivel tuvieron la virtud de hacer la programación de computadoras accesible a más personas.

Sigue siendo cierta la observación de que el código binario producido por los compiladores es más repetitivo, largo y menos eficiente que el que se podría producir directamente. Sin embargo, con la mejora de la velocidad de procesamiento, la programación directa en binario ya es muy poco práctica.

Es más importante llegar primero a la solución de un problema. La eficiencia del resultado se podría ir mejorando luego de eso (finalmente reemplazando código por assembler y luego por binario si el rendimiento fuera algo vital).

Algo hecho es mejor que lo perfecto

¿Qué es mejor, una solución perfecta que tarda tanto que nunca llega, o una solución que funcione?

"Done is better than perfect" es una famosa frase acuñada por la gente de Facebook.

La comunidad hacker tiene además "Primero que funcione, luego optimizas".

Y Donald Knuth, la famosa "La optimización prematura es la raíz de todo lo malo".

No son opiniones. Expresan un hecho, comprobado una y otra vez en la experiencia de los programadores y los equipos de programadores y los proyectos de programación.

Aún así, de cuando en cuando encontrarás a otros programadores o desarrolladores de software insistiendo en buscar la perfección o hacer optimizaciones durante la solución.

Es la optimización mal entendida.

Optimizar algo está bien, pero su momento es después que haya una solución.

Solo puedes mejorar algo que tienes, si no, la optimización es una falacia (y las falacias son peligrosas porque suelen tener ese aire de verdad que hace que uno las acepte si no se anda con cuidado)

Código limpio

A la computadora le da igual si el código está limpio o no.

El código limpio es una optimización orientada a los programadores para facilitar el mantenimiento del programa.

Pero, igual que toda optimización, su momento es después que tengas una solución, no antes.

Hay que disfrutar garabateando con código, esbozando algoritmos, en el proceso de concretar una solución.

Pretender escribir código limpio durante el proceso de solución es tan contraproducente como pretender pintar la versión final de un retrato directamente sobre un lienzo en blanco.

Cómo odio a los haters :-)

Hay programadores que automáticamente tienen actitudes hostiles o de desdén hacia ciertos lenguajes de programación, ciertos frameworks o ciertas librerías.

"PHP es el peor lenguaje de programación jamás inventado"

"Javascript es un lenguaje de juguete que no se puede tomar en serio"

"Todos esos frameworks son basura que complica las cosas"

Pero minimizar lo que nos disgusta no hace que nuestras soluciones sean mejores. De hecho, impide ver las soluciones de otros.

PHP es un lenguaje que ha ayudado mucho a democratizar la programación en Internet. La valla es más baja y mucha más gente puede entrar y cometer errores que hacen sonreir con desdén a ciertos académicos y profesionales. Pero ha permitido que muchas ideas geniales vean la luz. Más de la mitad de los blogs en Internet están hechos en WordPress, que es un administrador de contenidos escrito en PHP. Wikipedia está escrita en PHP. La base de Facebook también estuvo escrita en PHP.

Javascript ha evolucionado. No es solo para hacer efectos especiales en una página web. Permite crear interfaces complejas. Y en el lado del servidor, facilita el desarrollo de soluciones ligeras, asíncronas y sin bloqueos. Paypal usa Javascript en el backend. Hay quienes consideran que actualmente Javascript tiene uno de los más completos ecosistemas de desarrollo web.

Los frameworks son herramientas para resolver problemas. Como un martillo, o una sierra. Puede tomar su tiempo conseguir maestría en su uso. Muchos dedos golpeados, cortes accidentales. Y puede que no sean para todo tipo de problemas. Quizás haya herramientas más sofisticadas, o más ligeras, pero posiblemente te enfrentarás a más problemas si intentas hacer carpintería con una piedra, un cuchillo, o una navaja suiza.

Creo que siempre es más constructivo tratar de ver las buenas partes, usar esas buenas partes y evitar las otras.

También aquí es cuestión de ver el vaso medio lleno.

Referencias

• https://en.wikipedia.org/wiki/Grace_Hopper
• https://en.wikipedia.org/wiki/Program_optimization

Saber usar lo que hay

Una idea común:

• No es necesario usar ningún framework complicado. Puedo implementarlo yo mismo.

Ok, siempre y cuando:

• Estará bien documentado este nuevo framework (así es, vas a crear un framework que sólo tú conoces), y preparado para evolucionar (así es, eventualmente le encontrarán cosas que mejorar)
• Puedes costear ese desarrollo extra.
  Ese montón de esfuerzo y tiempo puede ser interesante para el desarrollador, por amor al arte, pero podría también ser enfocado mejor a la idea principal del producto en lugar de a la herramienta.
• No estará documentado pero no importa porque solamente tú vas a mantener el proyecto
• No estará documentado pero no importa porque el producto tendrá una vida corta

Es decir, no es buena idea cuando:

• No hay tiempo ni recursos para documentar o preparar el framework para evolucionar
• No hay documentación, no estarás disponible eternamente, y eventualmente alguien más va a mantener el proyecto
• No hay documentación y el producto tendrá una vida mediana o larga
  Ya que aún cuando sólo tú seas quien le seguirá haciendo manteniemiento, luego de unas semanas sentirás como si lo hubiera escrito otra persona

Reinventar la rueda cuando estudias algo es instructivo. Se puede aprender muchas cosas.

Pero cuando es otro el problema principal, reinventar la rueda, estando disponible algún estandar, puede ser muy improductivo. Es apostar que se puede hacer algo tan genial que superará la gran cantidad de horas de experiencia y experimentación acumuladas en el estandar, además de la comunidad de productos derivados, guías y expertos disponibles.

Si el caballo ha ganado algunas carreras antes, puede ser. Pero si es nuevo, o se trata de puro azar, no parece muy recomendable.

Así que es importante reconocer que siempre se usará un framework. La cuestión es si usarás uno más estándar, aceptando sus pros y contras, o si usarás el tuyo propio, el que irá surgiendo sobre la marcha.

Es bonito cuando algo nuevo surge. Algo diferente y mejor que cualquier cosa que hay. Es excelente cuando uno tiene la confianza de hacer algo así. El intentarlo te puede dar un gran poder sobre el destino del proyecto. Y con un gran poder viene una gran responsabilidad. Es mejor si tienes la experiencia para distinguir si puedes asumirla, y si es oportuno.

Es importante recordar que para resolver un problema o desarrollar un proyecto, las herramientas no son lo determinante. Tampoco simplemente usar bien cierta herramienta. Puedes tener un martillo de muy buena calidad y ser excelente con el martillo, pero será complicado usarlo ara ajustar un tornillo.

Más importante es hacer buen uso de aquellas que tengas disponible y te ayuden a resolver el problema.

El Principio de la Máquina Mínima

El desarrollo de un sistema es una serie problemas que se van resolviendo.

Puede haber varias maneras de resolver un problema. Podemos hacer uso de herramientas. El equivalente en software de martillos o cinceles.

El conjunto de todas las herramientas que usamos es parte de nuestro sistema de construcción. Aún sin proponérnoslo, el uso de herramientas determina siempre un framework de desarrollo.

Como en todo framework, a cambio de la ayuda que nos da, habrá limitaciones y convenciones que tenemos que seguir. Habrá cosas que un martillo nos permitirá hacer y otras que no.

Podemos visualizar al framework como una gran máquina, compuesta por todas las herramientas y las convenciones que determinan.

Una máquina puede ser muy útil. Pero tiene un costo adquirirla o construirla. Un costo dominar su uso. Y también un costo de operación.

Una máquina complicada tiene un gran costo de operación.

A veces usar una herramienta puede constituir un problema por sí mismo. Como cuando se maneja una gran herramienta en una obra.

Una máquina mínima sería el framework menos complicado que hace lo que necesitamos que se haga en un contexto determinado.

Puede ser que una grúa también se pueda usar para clavar un clavo. O una piedra. Pero un martillo es el menos complicado de los tres. Cuesta más que una piedra, pero es más confiable y requiere menos esfuerzo. Puede que una grúa también pueda clavar un clavo, además de levantar los materiales de construcción de la casa que construimos, pero es mucho más costosa, espaciosa, requiere ser encendida y una gran pericia para lograrlo.

El contexto es importante.

Puede ser que para clavar un clavo un martillo esté bien. Pero si necesitamos algo más masivo, tal vez notemos que podríamos usar un martillo neumático. En ese otro contexto, usar el martillo neumático puede ser menos complicado.

El principio de la máquina mínima es simplemente evitar el desperdicio de usar ambientes de desarrollo con características que excedan lo que realmente se necesita.

Así, usar un ambiente similar al de producción, conectado a motores de bases de datos, optimmizadores y caches, para desarrollar los templates, es utilizar potencia y complejidad innecesaria. Podría bastar con un servidor web simple con servicio ficticio de datos, incluso datos en hardcode. Para esa etapa, en ese contexto, es suficiente.

El ambiente que sirve muy bien para desarrollar backend no necesariamente es el mejor para desarrollar frontend.

El mito del framework zero

A veces alguien propone no usar ningún framework. Después de todo, no tenemos que preocuparnos de aprender a usar un framework si este no existe en primer lugar, ¿no es así? Terminan de desarrollar un sistema y dicen "no he usado ningún framework".

Pero si analizamos su trabajo, encontraremos un conjunto de módulos, herramientas, convenciones y patrones de uso. No habrá sido bautizado, pero eso es un framework.

Entonces, ¿siempre hay un framework?. Así es.

La cuestión se reduce a si es tuyo o de alguien más.

Es mejor que sea mío, después de todo, tengo así el control absoluto de mi proyecto y no tengo que aprender nada más, ¿no es así?

Como sabes, hay muchas peculiaridades que tener en cuenta a la hora de resolver un problema para el mundo real. Diferencias entre navegadores, inconsistencias en los lenguajes, cosas que no funcionan como se supone que deberían funcionar. Y suelen ser criaturas elusivas, que no se muestran frente al desarrollador sino que les gusta saltar frente a la cara del usuario.

Puede ser que seas un desarrollador genial. El mejor del mundo. Pero, ¿tienes realmente todas esas horas hombre para atender los issues que provienen del uso de tu software?, ¿tienes el tiempo para documentarlo detalladamente?. Quizás sea buena idea volverlo un proyecto abierto y aceptar la ayuda de la comunidad. Con organización, promoción, trabajo y algo de tiempo quizás lleguemos a obtener... algo parecido a uno de los frameworks que podríamos haber elegido al inicio? Pero, está bien, ¿no?, después de todo ¡tenemos un nuevo framework!.

¿Era el problema principal que querías resolver? ¿Era realmente necesario?

Usar un framework propio otorga no solo un gran poder, sino una gran responsabilidad.

En estos tiempos es fácil retroceder ante la primera dificultad y tratar de hacer todo desde cero, puro, como a mi me gusta. Es la ilusión de que si construyes la herramienta perfecta, lo que constuyas con esa herramienta también lo será. Pero son dos cuestiones completamente diferentes. Puedes ser bueno haciendo herramientas, pero eso no garantiza que harás una buena mesa.

Un buen consejo es no caer en la parálisis del perfeccionismo. Usar primero lo que ya hay. Luego corrige lo que puedas. Luego mejora lo que puedas.

Los bundlers

Un bundler, como webpack, puede ayudar mucho a la hora de construir los bundles que se suelen requerir para desplegar una aplicación.

En la etapa de despliegue.

Sin embargo, hay flujos de trabajo que fuerzan a usar el bundler en la etapa de desarrollo.

Eso le agrega complejidad al trabajo. Puede ser una máquina mínima para el contexto de despliegue, pero no lo es para el contexto de desarrollo.

Transpiladores

Un transpilador permite usar una sintaxis más cómoda en la fuente. Luego de la transpilación se obtendrá un resultado que se puede usar en el despliegue.

Puede ser que para la parte de desarrollo se obtenga menos complejidad. Pero es a cambio de mayor complejidad para compartir código, mantenerlo y depurarlo.

¿Realmente te está permitiendo el transpilador tener un flujo de trabajo más simple y ser más productivo? 

A veces, se critica alguna librería por su tamaño. Cuando usas transpiladores quizas la fuente sea pequeña, pero el resultado puede ser más grande que lo normal y menos optimizable.

A veces es simplemente la ilusión de que usar lo mejor producirá lo mejor.

Es importante tener en cuenta el contexto y buscar la simplicidad de manera más holística.

#NoEstimates

   

https://oikosofy.safechkout.net/NoEstimates-Book  

Un desarrollador (o su representante) conversa con el cliente (o su representante):

- ¿Qué es lo que se necesita hacer?

- ABC, ¿cuánto tiempo te tomará?

- x

Luego de x tiempo:

- Ya pasó x, ¿cómo vamos?

- Aún en la tarea

- Vamos retrasados

Finalmente:

- Ya está listo ABC

- Ok, pasa la prueba. Pero se atrasaron y%

- Ok, trataremos de hacerlo mejor

Situaciones de ese tipo se presentan durante el desarrollo de un producto y nos parecen normales. Sin embargo, expresan una serie de supuestos que no son necesariamente ciertos. Ni siquiera relevantes.

¿Qué es lo se necesita hacer?

Supone que el cliente (o su representante) saben lo que se necesita hacer. Casi siempre no es así, y determinar lo que se necesita hacer es algo que habrá que resolver. ¿Qué es lo que quieres resolver? suele ser una mejor pregunta.  

¿Cuánto tiempo te tomará?

¿Cuánto tiempo toma hacer algo? Si has hecho algo similar varias veces, puedes tener una idea. Pero como programador habrás experimentado que muchas veces hacer exactamente lo mismo, con la misma gente, toma un tiempo diferente. Algunas razones:

• La programación es una actividad creativa
• Las actividades creativas requieren una buena conexión con el subconciente
• La conexión con el subconciente es sensible al humor, el stress, etc
• Los equipos de trabajo están conformados por personas

Y, si nunca has hecho algo similar, quizás sientas que debas importar la respuesta que otro desarrollador similar, de otro equipo similar, para un cliente similar. Pero eso no es correcto por algunas razones:

• El trabajo no lo va a realizar ese desarrollador ni ese equipo para tu cliente en tu contexto. Cada equipo es distinto y el rendimiento de un equipo es sensible al contexto.
• En realidad, no estás seguro de que lo que hay que hacer sea similar a lo que ellos hicieron.

Cuando nunca has hecho algo similar, es necesario empezar a hacer y ver qué tal lo vas haciendo, antes de poder ofrecer alguna estimación sincera.

Vamos atrasados

Supone que la estimación fue correcta. Si hubieras dicho una cifra mayor estarías a salvo. Algo como el doble más el 10% más el número que pensaste. De hecho, muchos desarroladores, o sus representantes, usan ese tipo de tácticas para estar tranquilos; pero el cliente, o su reprepresentante, saben que puede pasar y entonces se produce un regateo de tiempos estimados.

Cualquier supuesto atraso o adelanto es irreal si la estimación no es correcta. ¿Es correcta la estimación? Ya vimos que no es posible que lo sea.

Imagina que un entrenador se acerca te mira y te dice 'mmm tu debes estar saltando unos 150 cm'. 'Sí señor', respondes, mientras le ayudas a colocar la valla. Tomas tu distancia, corres y saltas, llevándote la valla de encuentro. 'Qué mal' dice el entrenador. 'Sí señor', respondes. Si hubieran puesto la vaya a 60 cm hubiera sido 'Qué bien, excelente'. Así de absurda es la situación.

Sería mejor aprender a aceptar las capacidades reales de la gente y trabajar con eso, en lugar de intentar hacer pronósticos y calificaciones arbitrarias.

Además, considerar que, tanto para el clima como para los humanos, todos los pronósticos pueden fallar.

Aprendiendo a programar

Aunque términos como ingeniería de software y ciencias de la computación dan la impresión de que hay un dominio del tema, en realidad estamos aprendiendo a programar.

Quizás no se trata tanto de algoritmos óptimos, sino de encontrar un proceso sostenible que permita desarrollar sistemas también sostenibles. Lo óptimo será alcanzado eventualmente.

Persiguiendo la ilusión del óptimo inmediato es que se suele perder el camino, del mismo modo que un artista principiante que trata de hacer un cuadro trabajando perfectamente cada centímetro cuadrado, para lograr un resultado que no cuadra porque las partes no siguen un bosquejo que nunca trazó.

Encontramos buenas prácticas en programación imperativa. Pero el retorno de la programación funcional parece indicar que son soluciones creadas para problemas generados por usar el modelo imperativo en primer lugar. 

Así, estamos en camino de aprender el oficio de programar.

Programación mental

En los años 70, cuando los ciclos computacionales eran muy caros, nadie podía imaginar usar las computadoras para diseñar software. El software era diseñado en papel, para luego ser codificado por programadores y funcionara a la primera, si era posible.

En las escuelas de programación se incentivaba a la gente hacer todo en papel antes de escribir una línea de código. Correr una línea de código en una computadora era más caro que correrlas en la cabeza, así que los programadores usaban sus cabezas, y mucho papel, como simuladores de computadoras.

En los años 80, con el ascenso de la computación personal, hacer software se volvió una actividad comercial importante. Así que la industria y las universidades impulsaron más la creación de productos de software. Como venían haciendo, tratando de usar la experiencia que tenían en desarrollar otros tipos de productos. Sin embargo, la ejecución de los proyectos de desarrollo de software empezó a mostrar que había cosas importantes que funcionaban de modo diferente.

En los años 90, cuando los ciclos computacionales ya no costaban lo que antes, los programadores se dieron cuenta que tenía más sentido usar la misma computadora para explorar con ella las cosas que quisieramos que ejecute, en lugar de seguir intentando que nuestros cerebros traten de imitar ese proceso.

Considerar los icebergs y los andamios

Lo que se quiere desarrollar se puede representar con algo como:

No es cierto que alguien pueda desarrollar una versión final directamente. Similar a un iceberg, las 9/10 partes de lo que se tiene que hacer queda debajo de las aguas.

Los andamios son necesarios para levantar y producir lo que se verá. Es la infraestructura util que sin embargo será removida y descartada luego. La construcción de andamios también es parte de la producción de software.

Aprovechar la computadora para explorar

El software de hoy es más complejo que el de los 70s, cuando era normal instar a resolver el diseño primero en papel y simulando mentalmente los procesos que realizaría la computadora.

Hoy es mejor aprovechar la potencia computacional disponible.

TDD (Test Driven Development) es una técnica que construye cajas de prueba que determinan cuando el software está cumpliendo lo que se requiere. TDD promueve un proceso de descubrimiento para diseñar software.

Hay partes del diseño que se puede realizar con más flexibilidad mentalmente, pero hay otras donde es más razonable usar la computadora. Permitirse codear, fallando y acertando, explorando, ayuda a tener una mejor estimación. 

¿Es necesario estimar?

Los manejadores de proyectos han sido entrenados a resolver problemas con contextos definidos, desempeños uniformes y destinos determinados.

Por otro lado, la mayor parte del desarrollo de sistemas consiste en adaptarse a un contexto cambiante y manejar los desempeños irregulares hacia destinos inciertos.

Y es insistir en usar buenas herramientas en un contexto equivocado lo que conduce a muchos de los problemas en el desarrollo de software.

El uso de estimaciones es un ejemplo de eso. No es muy util tratar de estimar algo en un contexto con tanta variabilidad. Se convierte en una tarea ingrata que solo produce halagos o llamadas de atención completamente arbitrarias. Sin embargo, es algo que se sigue haciendo.

#NoEstimates, de Vasco Duarte, es un libro que habla sobre eso.

En el video, Vasco explica como las estadísticas de story points muestran un comportamiento irregular sobre el que es inútil tratar de hacer estimaciones.

En cambio, el número de historias que puede resolver un equipo por periodo muestra un comportamiento más regular.

Es decir, es irrelevante tratar de asignar puntos de dificultad a las historias.

Y parece ser que las estimaciones en desarrollo de software vendrían a ser un error metodológico.

El 80-20 en programación

Esta la observación de que el 80% de los problemas se debe a un 20% de las causas. Sin embargo, ocurre que con frecuencia la gente usa casi todo su tiempo en atender ese 20% que, en el mejor de los casos, dejará el 80% de los problemas sin resolver.

Lo hacemos. Y hasta nos sentimos orgullosos por el esfuerzo.... pero estamos apuntando al porcentaje equivocado.

Quizás lo hacemos por la misma razón que el hombre que busca su anillo bajo la luz del farol en lugar de en la esquina donde se le perdió... dice que porque aquí hay más luz.

Es muy difundido en la comunidad de programadores el hábito de procurar escribir código con el menor número de líneas, realizar el algoritmo más eficiente o la solución más elegante. Largas discusiones se arman en la búsqueda del mejor framework o incluso el mejor lenguaje de programación.

Y disfrutamos de los placeres que nos da lograr esas cosas.

Pero que nos de placer o nos haga sentir poderosos no significa necesariamente que estemos resolviendo algo.

En realidad, no importa si el código no es el más eficiente, ni si tu lenguaje de programación no es el más elegante. Lo que importa al final es los problemas que llegas a resolver con él.

Los programadores puristas sufren viendo como prosperan lenguajes feos como PHP y Javascript. Niegan con la cabeza. O se burlan. O los odian.

Quizás tengan que ver más allá y tratar de comprender la razón por la cual prosperan. No es una cuestión de lenguaje, sino de utilidad.

De modo parecido a como el valor de un bien no es cuánto te cuesta hacerlo, sino lo que el comprador está dispuesto a pagar por él (la razón de la oferta y la demanda), el valor de un programa no esta determinado por cuán pequeño has logrado tu código o que tan eficiente es tu solución... incluso en los casos que parece que así es, el verdadero valor es lo que le permite hacer al usuario.

Por ejemplo, PHP y Javascript empezaron como lenguajes de juguete. Algo que permitiera llenar fácilmente el vacío de un lenguaje de programación en un servidor web, o en un navegador. A pesar de todas las críticas técnicas que se les puedan hacer, el hecho es que ambos son de lo más útil. Democratizaron el desarrollo web y lo siguen haciendo.

El anillo que los programadores buscamos no está bajo el farol del código mínimo o más eficiente, o el purismo académico. Está en la desconocida esquina del uso que la gente le da, ahora.

Quizás debamos invertir más nuestro tiempo en apuntar a ese 80%.

Kanbiando con Kanban

Hace unos días, en mi trabajo, hicimos una actividad interesante.

Se propuso a los miembros del equipo un problema de programación no muy complejo. Se eligió un lenguaje de programación y una sola computadora, cuya pantalla se reflejaba en un televisor para todos, donde cada uno trataba de avanzar lo que pudiera durante 5 minutos.

Excepto el jefe, que debía mantenerse al margen haciendo intervenciones ocasionales, nadie más que quien estaba en su turno podía hablar, contando a los demás que iba haciendo y por qué lo hacía.

Además podía buscar en Google, y modificar o borrar el código previo.

Se sucedieron varias rondas y paso un par de horas sin que lográramos escribir una solución funcional.

Entendíamos la solución a la que queríamos llegar, y probablemente todos hubieran podido escribirla trabajando solos durante quince minutos o media hora. Pero, por alguna razón, no la lográbamos alcanzar.

Cuando terminó la jornada, me retire, pero el problema continuaba en manos que quienes podían quedarse.

Me sentía frustrado, pero, conforme pasaba el tiempo me iba sintiendo además instruido. Un problema simple y solucionable se había vuelto prácticamente irresoluble debido a las condiciones de trabajo impuestas.

Estas condiciones fueron tales que prácticamente anulaban la comunicación. Eso inhabilitaba el trabajo en equipo. Al menos, él trabajo en equipo usual.

Reflexionando, me di cuenta que, al inicio, nadie asumió el reto como un trabajo en equipo. Cada uno quería, de ser posible, terminar el problema en su turno.

Luego, cuando las primeras rondas iban mostrando que no sería tan fácil, apareció gente que prefirió hacer explícita una estrategia en lugar de programar. Entonces, el trabajo de todos empezó a encauzarse y parecía que se resolvería pronto. Nos estábamos adaptando.

Es allí donde el jefe cambió de pronto las reglas. Dijo que estaba clara la solución y que el reto sería ahora tratar de escribirla una sola persona, desde cero, en 5 minutos.

Además de transformar el problema en una competencia de tipeo, de entrada, eso destruía la comunicación incipiente que había surgido espontáneamente. Fue entonces cuando me retiré.

Camino a casa iba pensando que pasaría si esa prueba se repitiera cada semana. Creo que iniciaríamos sacrificando tiempo de programación para establecer mejor primero un marco de trabajo y luego la estrategia para resolver el problema. Y luego recién empezaríamos a codear.

Me pregunte luego cuántos proyectos habrá así en la vida real. Con gente competente y sin embargo sin avances significativos. Y todo por una organización contraproducente.

Deming, el padre de la mejora continua de la calidad, decía que el 95% del resultado éxito o fracaso se debía a la organización y solo 5% a la gente.

Pero no es obvio. Mucha gente tiende a culpar a la gente y lanzarse a tomar medidas correctivas en ese sentido. Llamadas de atención, recorte de privilegios, castigos, en el peor de los casos. Capacitaciones y coaching en el mejor de los casos.

Pero, si la causa es la organización, no se solucionará nada. A menos que se empondere a la gente para que la pueda mejorar.

Un par de días después, asistimos a un seminario sobre Kanban (la metodología de visualización de flujo de trabajo inspirada en las prácticas de Toyota).

Resulta que es una herramienta muy simple y poderosa para visualizar el estado del flujo de trabajo en una organización. Y para hacer evidentes sus virtudes y defectos.

Siendo evidentes los defectos, es más fácil proponer cambios de políticas e ir gradualmente cambiando la organización.

Yo pensaba que venía utilizando Kanban, al menos en mis proyectos personales. Descubrí que lo estaba haciendo de modo incompleto. Para que Kanban haga su magia, es necesario hacer hacer explícitos los límites de trabajo en progreso (WIP, por sus siglas en inglés) y las políticas de aceptación de tareas.

Ahora estoy leyendo y aprendiendo más al respecto. Un libro que me parece sumamente útil y fácil de leer es "Scrum y Kanban: Usando lo mejor de ambos", de Henrik Knigerg y Mattias Skarin.

Estoy viendo que podría usarlo también para mejorar mi forma de estudiar... y hasta para procesar con más eficacia las montones de cosas que quiero hacer en la vida (Personal Kanban)

Una gran virtud de Kanban es que te permite iniciar como eres ahora, con lo que tienes ahora.

Viva Kanban \(^_^)/

En equipo

Es muy diferente escribir código solo que en equipo.

Cuando eres solo una persona, tienes más libertad para elegir lo que te gusta o desechar lo que no te gusta. Para elegir usar patrones que solo tu conoces, para inventar tu propio framework, para usar los hackings que te gustan...

Cuando eres solo una persona, escribes código para solucionar un problema. Y punto.

Pero cuando estás en un equipo, escribes código para solucionar el problema de modo que otros puedan entender la solución y mantenerla.

Eso puede ser un poco más complicado. Porque la mayoría de tu equipo puede tener otras preferencias de formato, usar mejor otros frameworks, y cosas como los hackings (que te hacen googlear media hora para entenderlos), no son recomendados.

Pierdes la sensación de control total que puedes sentir cuando dominas tu código. En su lugar, va apareciendo el sentimiento de que todo es caos.

Y, sin embargo, del caos surge un orden, y soluciones valiosas, si las sabes ver. Es cuestión de abrir la mente para estar dispuesto a aprender... que nunca se acaba de aprender. Y que hay soluciones que no son tuyas ni mías, sino de ambos.

Cuando aparece la sinergia, donde uno más uno es más que dos, es como magia que jamás conocerías si no fuera porque trabajas en equipo. Y entonces, lo valoras.

Justo a Tiempo

Just In Time (Justo a Tiempo), JIT, es una filosofía de producción.

Sus principios se basan en los que empleaba Toyota en los 1970, pero adecuados a occidente.

En el libro "Justo a Tiempo", de Edward J. Hay, mencionan que algo principal en JIT es la eliminación de desperdicio.

Los japoneses definen desperdicio como "todo lo que sea distinto de la cantidad mínima de equipo, materiales, piezas y tiempo laboral absolutamente esenciales para la producción".

A Hay le parece que determinar lo que es absolutamente esencial es subjetivo y redefine el desperdicio como "todo lo que sea distinto de los recursos mínimos absolutos de materiales, máquinas y mano de obra necesarios para agregar valor al producto".

Estoy leyendo sobre JIT y otros temas de metodologías ágiles porque estoy interesado en hallar mejores formas de desarrollar software en equipo.

En mi caso, la definición original de desperdicio, como aquello que no es el mínimo esencial para producir algo sí tiene mucho sentido.

En TDD, se va escalando sobre mínimos necesarios para producir algo. Cada escalón debe ser trivial respecto al anterior. Nada de considerar posibles mejoras por adelantado. Nada de generalizaciones antes de tiempo. Nada de de optimizaciones prematuras. Primero, lo mínimo necesario para que funcione. Las optimizaciones llegan a través de reflexión y refactorizaciones.

La definición japonesa de desperdicio la entiendo muy bien en ese contexto.

En cambio, la definición de Hay, como aquello que no agrega valor al producto, me parece contraproducente. Y realmente subjetivo, al menos desde el punto de vista de TDD.

Porque no faltarán clientes, jefes de producto o jefes de equipo que insistan en incluir por adelantado una funcionalidad X porque opinan que eso agrega valor al producto (y no están pensando en el producto actual sino el que está dos ciclos adelante, o incluso el final, o más allá...).

En cambio con la definición original uno está a salvo: ¿es absolutamente necesario para que funcione ahora? No. Entonces lo anotamos en la lista de deseos, pero la implementaremos cuando sea su momento, no antes.

Bueno, eso esta es una nota en el camino... continuaré leyendo el libro...  :-)

Sobre autores

DRM (Digital Rights Management) es una clase de tecnologías usadas para controlar la copia de contenido digital después de la venta.

¿Por qué?
Las nuevas tecnologías facilitan la copia de contenido.

El copyright es un concepto legal para asegurar la exclusividad en el derecho de copiar contenido.

¿Por qué?
El contenido puede ser considerado como un producto.

El derecho de autor es un concepto legal para atribuir a un autor el copyright del contenido que produzca.

¿Por qué?
Para que el copyright pueda ser considerado como un producto.

¿Por qué?
Si algo es valioso, quien más gana es el intermediario, el encargado de la distribución.
Es una gran ventaja asegurar la exclusividad en la distribución.

Cuando alguien produce contenido, si su valor de distribución es alto, el intermediario tenderá a asegurar la exclusividad de su servicio.

El derecho de autor es un producto que el distribuidor le compra al autor para asegurar esa exclusividad.

El distribuidor defiende el derecho de autor para asegurar que ese producto siga existiendo.

El concepto de derecho de autor no ha existido siempre. Cuando aparecieron impresores que reclamaban a perpetuidad la exclusividad en la copia de los libros que habían adquirido de los autores, los gobiernos establecieron leyes con plazos menores (en el siglo XVIII). Desde entonces se ha jugado de esa manera.

¿Cuál es el problema?

El contenido, a pesar de que le han dado ese nombre, es contenedor de conocimiento. Las limitaciones comerciales para la distribución de productos, cuando son aplicadas a contenedores de conocimiento, limitan la distribución de conocimiento.

Antes, el conocimiento se difundía lentamente, principalmente de manera oral. Cuando apareció la imprenta, el conocimiento se pudo difundir principalmente por vía escrita. Eso facilitó que se empezara a considerar al contenedor de conocimiento como un producto comercial.

¿Es el conocimiento un producto comercial?

En un mundo ideal, las obras contendrían como referencia los nombres del autor o los autores que contribuyeron a su creación. Porque eso es útil para contactarlos, documentar su desarrollo, mejorar el conocimiento.

Actualmente, si la preocupación por los autores fuera sincera, se defenderían más bien derechos de atribución, para asegurar que la contribución de cada autor figure en la obra y sus derivados.

Pero lo que se defienden son cosas que permitan exclusividad comercial del contenedor, aún a pesar de que eso limite el libre desarrollo de lo que contienen, que es el conocimiento.

Lo saben los autores de libros y música, que realmente reciben bajas comisiones de parte de las distribuidoras. La mayor parte va siempre para el intermediario. Por eso, algunos autores están optando por auto publicarse o usar canales de distribución menos onerosos. Incluso, el propio autor debe pedirles permiso para citarse a si mismo.

Hubo un tiempo, reciente, en que la distribución comercial fue aliada de la distribución de conocimiento. Porque no estaba al alcance de la mayoría imprimir un libro o editar un disco. Pero la tecnología ha avanzado y ahora tenemos el poder de hacerlo. Ahora podemos contribuir a la distribución de conocimiento.

Eso significa el final de una era para los distribuidores. Tendrán que descubrir o inventarse nuevos roles. Sin embargo, lo que hacen muchos es usar sus recursos para tratar de salvar su antigua forma de vida lo más que puedan.

La opción extrema, es renunciar al copyright y usar el copyleft. Es decir, salvaguardar el derecho de atribución, pero permitir la libre distribución y modificación de la obra, con la condición que cada copia y sus derivados tenga también el mismo copyleft.

Así es como el software libre ha podido hacer tantos ciclos de desarrollo y lograr avances notables comparados con las alternativas con copyright. Así es también como Wikipedia dejó fuera a MS Encarta e incluso a la Enciclopedia Británica. Así es como el conocimiento se abre paso.

El conocimiento merece que veamos más allá de su aspecto comercial, que ha sido como el bote que ha permitido llegar a esta playa. Porque es la búsqueda del conocimiento la razón de todo lo que nos trae hasta aquí. Deberíamos honrarlo, respetarlo, cultivarlo. Dejar que sea libre y nos lleve a donde seamos capaces de ir.

Dropbox + Dokuwiki

Dropbox + Dokuwiki

Se dice que quienes no recuerdan el pasado están condenados a repetirlo. Por eso es bastante útil conocer algo de historia. Por eso también es útil llevar un diario personal o, en la vida profesional, algún tipo de bitácora.

Al poco tiempo de haber hecho algo, se tiende a olvidar los detalles. Con el tiempo, se van olvidando más aspectos. Es más fácil y eficiente recordar con ayuda de nuestra bitácora, que volver a realizar la investigación, las pruebas, y el desarrollo.

Una bitácora se puede llevar en papel. Pero puede ser mas sencillo realizar búsquedas en un medio digital.

Una alternativa podría ser algo como Google Docs. Es como un documento que puede ser tan largo como se quiera. Un problema es que mientras más largo sea el documento, más difícil es de manejarlo, por lo que se tiene de dividir la bitácora en partes más pequeñas, quizás por meses. Pero un problema mayor es que si la conexión de Internet falla, quedamos sin acceso a ella, en particular a nuestras notas sobre qué hacer cuando hay problemas de red (-_-)'

Otra alternativa es usar un wiki, que permite que la información crezca de manera más orgánica. Hay muchas ofertas. Las que son online, tendrían también el problema del difícil acceso cuando falla la conexión a Internet.

Entonces quedan las que son para instalar uno mismo, en el localhost. Luego, está el problema de tener el mismo contenido de computadora en computadora si, por ejemplo, usamos a veces la del trabajo, otras veces la de la casa, y otras una portátil. Hacer esa sincronización se vuelve tediosa si involucra base de datos; es mucho más sencillo copiar y pegar archivos que exportar e importar tablas. Así, es más fácil usar un wiki como dokuwiki, cuyo contenido se almacena en archivos de texto simple, que mediawiki, que almacena en base de datos.

Finalmente, la sincronización se puede automatizar usando dropbox. Lo que suelo hacer es crear dentro del directorio web un enlace simbólico a un subdirectorio de mi carpeta dropbox. Por ejemplo, htdocs/dropbox/ apuntando hacia Dropbox/htdocs/. Si instalo dokuwiki en dropbox/dokuwiki, aparecerá en todas las computadoras donde tenga dropbox (además del acceso online), y se mantendra sincronizado automáticamente. Genial!

Confieso que este razonamiento no llegó a mi en el mismo orden en que lo estoy contando. Durante mucho tiempo usé un wiki en un hosting, haciendo backups locales. Luego usé unos años Google Docs, desechando muchas veces la idea de volver a los wikis porque quería ahorrarme el costo de mantener un hosting (y un hosting gratuito suele tener la presión de ingresar cada mes para que la cuenta se mantenga viva). Un día, me animé a instalar dokuwiki en mi dropbox de desarrollo y... eureka, me dí cuenta que era una buena idea (^_^).

Ojalá le sirva de ayuda a alguien más también.

Creando nuevas opciones

Caminando por una tienda, encontré un juguete con forma de notebook.

Lo encendí y comencé a navegar por las distintas opciones que ofrecía.

Había juegos para aprender el alfabeto, los números, las notas musicales, para escribir mensajes, y así por el estilo.

Pensé que llegaría un momento en que uno habría explorado todas las opciones. Entonces querria más.

La diferencia entre una computadora y el juguete era que no había opción para agregar cosas. O quitar cosas. O modificar las que habían.

¿Cuántas personas usan las computadoras de ese modo? Es decir, como un gran conjunto de opciones que consumir, simplemente, sin poder modificarlas. Un ejemplo que me viene a la mente es el de los diccionarios. Sería tan útil que nos permitieran agregar nuestras propias definiciones y, sin embargo, debemos conformarnos con descargar las que hayan hecho otros.

Se podría pensar que es algo que le corresponde a los programadores. Pero pienso que programar una computadora debería ser algo tan simple que podamos hacerlo todos.

Me parece que con la consola de comandos íbamos por un camino que eventualmente nos conduciria a intérpretes de lenguajes humanos. Primero por escrito y luego por voz. Un día cercano podríamos comandar una computadora como si conversáramos con ella, como en Star Trek.

Pero apareció el sistema de menús y ratón y hubo un desvío.

Un sistema de menús presenta las opciones en una estructura jerárquica. Eso permite verlas con más claridad. El ratón permite navegar en ese sistema. Comparado con escribir los comandos, puede resultar más cómodo, más rápido... para ciertas cosas.

Quienes usan la consola de comandos pueden notar que hay cosas que la consola permite y el sistema de menús no.

Si usamos la consola de comandos simplemente como un modo de llegar a las opciones que ofrece el sistema de menús, no hay mucha ventaja (sería más cómodo usar el ratón). La magia de la consola de comandos aparece cuando permite crear nuevas opciones y manipularlas con una expresividad que quizás esté más allá de las posibilidades de un sistema jerárquico de presentación.

Los lenguajes de programación son un modo de crear esas nuevas opciones. Antes, en la época de la consola de comandos, se hacía el intento de acercar estos lenguajes a la gente. Estaban BASIC, LOGO y así por el estilo. Pero eso fue decayendo conforme se popularizaba el ratón.

El problema con el mundo del ratón es que tiene un límite, igual que el juguete. Como en una tierra plana, llegará el momento, tarde o temprano, en que se habrá recorrido cada opción y, parado en el borde de ese mundo, querrá más.

Claro que los programadores se encargarán de ampliarlo, proveyendo nuevas opciones que estarán disponibles con solo pasar a la siguiente versión. Dependemos de ellos para eso. Pero ¿no sería mejor que cada uno pudiera crear por si mismo nuevas opciones, en lugar de tener que esperar a que a alguien más se les ocurra y las programe?

En el desarrollo de programas, se va tomando más en cuenta el papel del usuario en la definición del producto y su implementación. Las ideas de los usuarios (recolectadas a través de foros o emails) son tomadas en cuenta en el diseño. Los errores que encuentran ayudan a mejorar el producto. Se compite para ver quién logra escuchar mejor a los usuarios y traducir lo que dicen a mejoras en el software. Pero, viéndolo bien, es como si los usuarios programaran las computadoras a través de los programadores. ¿No sería mejor que la programación pudiera ser directa?

Yo soy programador, pero me parece que muchas veces estamos cumpliendo simplemente el rol de intermediarios es una tarea que debería poder ser realizada directamente por los usuarios. Programar debería ser algo mas simple y cualquier persona debería sentirse capaz de comunicar a la computadora lo que quisiera que hiciera. Encontrar un modo en que la gente pueda definir nuevas opciones, o expresarlas de otro modo, luego compartirlas con los demás y permitir que evolucionen.

Imagine que puede agregar opciones a su árbol de menús. Imagine que puede operar con las opciones que ya tiene para crear otras nuevas. Imagine que incluso puede crear nuevas operaciones para manipular esas opciones. Imagine que puede compartir todo eso con otros usuarios. Y todo eso de un modo que le resulta natural, lógico, simple.

Esa forma de ver la computación era más evidente cuando se usaba la consola de comandos, ese infinito universo negro poblado de letras fosforescentes. Pero pienso que también se podría hacer en el sistema de menús, si abrimos la puerta.

Liberando la V, otra forma de usar un framework MVC

En el esquema MVC, se tienen modelos que proveen datos, y controladores que toman los datos y los procesan de algún modo antes de enviar el resultado a la vista.

En web, los framework MVC tratan de seguir este esquema para organizar el trabajo. En teoría, parte del equipo se puede enfocar en los modelos, otro en los controladores y otro en las vistas.

Al margen de si en la práctica realmente se cumple esto, es notable un problema: los modelos, vistas y controladores desarrollados determinan finalmente un API no estándar que termina "enjaulando" el producto final. Si decide actualizar el framework a la siguiente versión, encontrará que puede acarrear para el site un trabajo similar a volverlo a hacer. Aún más difícil es pasar un site de un framework a otro.

Esto genera algunos vicios. Si otro framework implementa cierta característica ventajosa, no lo podemos usar; tenemos que esperar hasta que algo similar sea implementado en el que usamos. Esa característica debe ser expresada otra vez, en los términos de nuestro framework.

En mi opinión, esto ocurre porque la página web ha sido forzada a encajar en el esquema MVC sobrescribiendo sus características estándar por otras propietarias, definidas por su sistema de templates particular.

Sí, aunque el framework sea open source, en este caso se está comportando como un ente propietario. Y eso es lo que provoca esta limitación de libertad.

Para tener más libertad, libere la vista. Puede desarrollar su sitio web de modo que las vistas sean HTML estándar y las partes dinámicas carguen con javascript (AJAX) los datos obtenidos de invocar algún framework.

Por ejemplo. Si uso Drupal como framework, puedo tener un subdirectorio drupal dentro de mi site, e invocar con javascript a algo como drupal/action.json, cuyo resultado reflejo en la página.

No hay problema con las páginas del site mientras no cambie el modo de invocar la accion. Si luego cambio la versión de drupal, no seria necesario cambiar las vistas.

Si, en lugar de usar drupal como nombre del subdirectorio, hubiera usado algo como framework, y colocara dentro acciones que se invocaran del mismo modo, entonces, podría usar cualquier framework, con tal que siguiera el protocolo esperado por las vistas.

Esta forma de trabajar puede permitir funcionar un sitio dinámico que use muchos frameworks diferentes en simultaneo. Uno para el login, otro para los listados, otro para comunicaciones, etc. El que mejor haga lo que queremos. También facilita la actualización de los frameworks a versiones superiores.

Usar javascript para esto me parece un camino relativamente asequible en este momento. Pero si alguien no desea usar javascript para eso, podría usar un framework unobstrusivo (que respete la integridad de las páginas), como uphp, para hacer el trabajo de reemplazo. uphp usa querypath para ubicar un elemento en la página (al estilo jquery, pero con php), y reemplazarlo por algún resultado; todo eso en el lado del servidor.

En este otro modo, no son las vistas las que invocan las acciones, sino los controladores que se disponen en el framework unobstrusivo (o uframework, para abreviar). El uframework podria invocar a otros frameworks para hacer los reemplazos de los resultados en las ubicaciones pertinentes en la vista. Igual, se podría usar varios frameworks a la vez.

La idea principal es que la vista salga de la jaula del framework, se respete su integridad, tal como es, y sea independiente de los motores que se usen para generar el contenido dinámico.

Liberando los sitios dinámicos

Imagine que le hicieran una página web y, un tiempo después, usted quiere modificar el documento HTML.

Imagine que puede abrirla en cualquier editor de texto, modificarla y volverla a grabar. Sin importar si se hizo en Dreamweaver, Geany, Notepad, o cualquier otro. Qué libertad.

Claro que no sólo lo podemos imaginar, de hecho podemos hacerlo.

Entonces, ¿por qué hemos permitido que esta libertad y conveniencia sea recortada por los frameworks? Porque eso es lo que ocurre.

Cuando hacemos un sitio dinámico, digamos en CakePHP, y, un tiempo después, usted quiere modificarlo, tiene que usar no sólo CakePHP, sino la misma versión de CakePHP. Del mismo modo si hubiera usado Zend, CodeIgniter o Drupal.

Es como si le dijeran que para abrir un HTML tiene que usar Notepad 4 y no otro, porque no es compatible. Que si quiere el mismo site para Notepad 5 hay que volverlo a hacer.

Sí, un site dinámico es más complejo que un documento HTML, pero la razón es similar. Es importante que el producto sea independiente de la herramienta usada para fabricarla. No sólo porque es un gran ahorro de esfuerzo y duplicidad. Sino también para que tengamos la libertad de elegir cualquier herramienta que queramos.

En el desarrollo web han aparecido islas, o silos. Al comienzo fue entre lenguajes, como ASP, JSP, PHP, Python, Ruby. Luego entre frameworks dentro de esos lenguajes. Y entre versiones de un mismo framework.

Muchos desarrolladores se amarran a cierta plataforma porque sus productos no pueden ser modificados con otra. Expresar un sitio dinámico en otro framework (o versión de framework) puede ser tanto trabajo como hacerlo de nuevo.

Después de todos los discursos que nos dan sobre la reinvención de la rueda, KISS (Keep It Simple, Stupid: Mantenlo Simple, Estúpido), DRY (Don't Repeat Yourself: No te Repitas), etc ¿no le parece poco razonable?

Hay razones por las que se prefirió que los protocolos web usaran texto simple. Para que cualquiera pudiera entrar a manejarlos. Quizás debemos recordarlo más seguido.

Imagine que le hicieran un sitio dinámico y, un tiempo después, usted quiere modificar el site.

Imagine que puede usar cualquier framework, modificarlo y guardarlo. Sin importar si se hizo en Drupal 6 o Drupal 7. O si se hizo en Zend o CodeIgniter. Incluso sin importar si se hizo en PHP, Ruby, Python o ASP. Qué libertad.

Claro que sólo lo podemos imaginar, pero podemos hacerlo.

Software libre

Cuando alguien se entera que hay en el mundo del software gente que contribuye voluntariamente diseñando, programando y probando programas que se distribuyen líbremente, a menudo se oye la pregunta ¿y que ganan ellos haciendo eso?

Puede ser difícil tratar de explicarle a alguien que te contempla con una mirada esceptica que es lo que ganan. Y la mirada esceptica se vuelve de confusión cuando no aparece mencionado el dinero. Porque eso es en realidad lo que preguntan, ¿de que forma ganan dinero por el trabajo que hacen?

Cuando uno va comprendiendo la respuesta, se da cuenta de que hay varias cuestiones previas que hay que atender. Cuestiones que tienen que ver con nuestros hábitos culturales.

La propia pregunta de cuánto dinero se gana por ese trabajo evidencia que damos por supuesto que trabajamos para ganar dinero. 'Por supuesto'. Si es lo que acaba de pensar, puede que al mirar un espejo descubra la mirada esceptica de la que hablo.

Hay una historia que cuenta de un millonario que estaba de vacaciones paseando por una playa y conversa con un pescador que encontró descansando bajo la sombra. Quizás podrías tener un bote más, le sugirió. ¿Para qué?, le preguntó el pescador. Podrías pescar más y tener más dinero. ¿Para qué?. Con el tiempo podrías tener una flota de barcos, y mucho dinero. ¿Para qué?. Cuando te retiraras, podrías descansar tranquilo y pasar el tiempo que quisieras con tu familia. Pero, eso es lo que estoy haciendo ahora.

A fin de cuentas, trabajamos por lo que queremos realizar con el dinero, pero llega a ser tan complicado obtenerlo y administrarlo que acabamos en medio del camino. Para dificultarlo más, realmente hay muchísima gente que, por diversas razones, trabaja en cosas que no les gusta, y llegan a pensar que el trabajo es simplemente algo que hay que hacer para obtener dinero.

La razón por la que hay gente que realiza trabajo voluntario sin recibir dinero es que recibe algo más. Cuando alguien disfruta el trabajo que hace, diseñando, programando, probando, el sólo hacerlo ya es una recompensa en sí misma. A esto se suma el producto que se logra; algo único, que encontró su propio camino, con la sinergía de todos. Es como si todos juntos construyeran una casa. Una sola persona no haría mucho con el salario que podria recibir por su trabajo. Tampoco nadie podría pagar la suma de todos los salarios. En la cultura ortodoxa de trabajar por dinero, el proyecto es imposible. Sin embargo, al trabajar por lo que realmente se quiere realizar, se realiza la casa.

Internet ha ayudado mucho a que este tipo de trabajo comunitario sea posible, porque facilita una forma de organización horizontal, distribuida, descentralizada. Es el tipo de organización con la capacidad de adaptación y el poder conjunto (pero no junto) que se necesita para cambiar el mundo en el lugar que queremos realizar. En estos proyectos, la libertad está no sólo en el software.

Programando una mejor sociedad

Hoy, en Perú, como cada año, el Presidente da un mensaje a la nación.

Mientras lo escucho, reflexiono sobre el significado de las cosas que se hacen. Y el por qué se hacen de ese modo.

Yo no sigo con mucho detalle los acontecimientos políticos ni las noticias. Quizás podría decir que contemplo el panorama, y trato de entender.

Nacemos siendo habitantes del país de nuestros padres. Aprendemos a ser gobernados por reglas que alguien más creó. Pero luego vamos notando que podemos hacer algo al respecto.

Nuestro destino está influido por una sociedad que sigue reglas acordadas por ella misma. Es como si la sociedad se programara a sí misma.

En los detalles, tal vez la mayoría de la gente encuentre que la política y la programación son dos cosas muy diferentes, pero pienso que tienen algunas similitudes que podrían ayudarnos en la búsqueda de una sociedad mejor.

Qué tan buena es una sociedad. Cómo debería construirse. Qué tan bueno es un programa. Cómo debe construirse.

En el mundo de la programación tenemos experiencias y propuestas que quizás podrían aplicarse a la construcción de las reglas que guían nuestra sociedad. Principalmente las provenientes del movimiento de software libre, que han mostrado como cosas que antes parecían imposibles en realidad son muy posibles y prácticas. Se decía, por ejemplo, que, como cada vez que se agregaba un programador a un equipo se observaba un retraso en el avance y un aumento en la complejidad del proyecto, había un tamaño que jamás podría superarse. Los proyectos open source, como Linux, con miles de colaboradores alrededor del mundo, mostraron que el límite está determinado por la forma de organizarse. Una forma diferente de organizar el trabajo permitió coordinar el trabajo de muchísima más gente.

En nuestros proyectos locales, podemos tener la oportunidad de ver como nuestras decisiones afectan el trabajo que hacemos. Podemos ser como el soberano del proyecto de programación que implementamos. Ser el presidente de nuestro código. Y desempeñar también roles equivalentes al del legislador, magistrado, policía, etc. (quizás, cualquier sistema, alcanzado cierto nivel de complejidad, pueda generar roles como esos)

Algunas veces tenemos las mejores intenciones, y planteamos resolver las cosas de un modo que nos parece bueno, pero luego nos estrellamos con muros que nosotros mismos construimos.

Después de mucha prueba y error, los programadores han reunido un conjunto de buenas prácticas que sirven como pautas en nuestro trabajo. La experiencia de los miles de programadores en proyectos extensos también ha sido util para los programadores de proyectos más pequeños. Aquí menciono algunas:

El principio KISS (Keep It Simple as poSible*). Si hay dos maneras de hacer algo, es mejor usar la más simple. ¿Por qué? Cuando algo puede fallar, falla; así que es mejor minimizar el número de cosas que pueden fallar para facilitar el inevitable proceso de mantenimiento y mejora. Además, hay cierto grado de complejidad que los humanos podemos manejar con comodidad. Cuanto más simple, hay más capacidad mental disponible para la creatividad.

Reutilizar las cosas tanto como sea posible. Si algo funciona bien, no hay que estar repitiendo una y otra vez el mismo trabajo. Sin embargo, tener al mismo tiempo la libertad de reinventar la rueda y proponer alternativas, porque así es como se encuentran mejores opciones que puedan reemplazar a la anterior.

Minimizar el acoplamiento. Es decir procurar que el cambio que se hace en un componente no requiera hacer cambios coordinados en los demás. Esto facilita su mantenimiento y evolución.

Me pregunto por los montones de procedimientos que hay en nuestra sociedad. Por las duplicidades y los acoplamientos en las funciones municipales y ministeriales, en la policía y en el serenazgo. Por los pequeños feudos administrativos en los que se convierten las universidades, e incluso las facultades dentro de la misma universidad aunque sea pública. Por las absurdas reglas que se plantean y no se evalúan. Por el sistema de justicia que obliga a pelear una y otra vez las mismas batallas (¿por qué, si la justicia debiera ser igual para todos?). Por las reglas que no se siguen y las coordinaciones que no se hacen porque el protocolo resulta más complejo que el problema que se quiere resolver.

Las leyes y reglas mál dadas se observan en la práctica, al tratar de ejecutarlas. Igual que los frameworks en programación. Por más buenas intenciones que se hayan tenido al momento de darlas, por más que hayan funcionado en otros casos, para otras personas y otras circunstancias, cuando vemos que no funcionan en nuestro caso particular, debemos aceptar los hechos y tratar de hacer algo constructivo al respecto.

Es importante que las reglas sean simples, claras en sus intenciones, transparentes en su funcionamiento, y corregibles en su evolución. ¿Son así las leyes que tratan de aplicar en nuestra sociedad?.

Me parece también importante reconocer que telarañas de complejidad se pueden tejer cuando se trata de aplicar una regla que no se puede cumplir. Imaginemos el ejemplo absurdo de alguien que pusiera la regla de no respirar más de 30 veces por minuto. De pronto, todo el comportamiento de la gente cambiaría radicalmente. La gente no podría correr o hacer mucho esfuerzo porque la conduciría a un acto ilegal. Para verificar el cumplimiento de la norma se necesitaría policías que eligieran individuos sospechos (quizás demasiado chaposos) y les hicieran una auditoría. Seguramente habría excepciones para esos policías (que a veces tendrían que perseguir a los criminales) y los militares y agentes secretos. Aumentaría el trabajo de los jueces y abogados. Líderes sociales reclamarían ampliar el número a 31. Fuerzas conservadoras presionarían para disminuirlo a 29. Aparecerían libros y películas contando anécdotas y actos heroicos al respecto. Con el tiempo, tendríamos demasiada gente cuyo bienestar depende de la existencia de tal regla que, si alguien se preguntara por ella, nos tildarían primero de soñadores, luego de locos, y después de subversivos. Nos amedentrarían hasta que ellos mismos tuvieran una razón para hacerse la misma cuestión. He visto reglas así surgir incluso familias y en pequeños grupos de amigos. ¿Cuántas reglas como esa habrán en nuestra sociedad? Incluso las podrá reconocer en algunos dogmas religiosos.

Como programadores, podemos experimientar con reglas en las sociedades que representamos en un proyecto de desarrollo de software y aceptar con humildad que funciona y qué no funciona. Podemos tomar nota de ello, ganar experiencia, y desarrollar una intuición que puede servirnos para hacer una mejor tarea cuando tengamos la oportunidad de contribuir por una sociedad mejor.

* KISS, Keep It Simple, Stupid, era la versión original. Creo que el tono tenía la intención de llamar la atención entre amigos. Aquí uso una versión más cordial.

Crédito de la imágen: canada.com