Sobre artesanos y máquinas: una filosofía del software bien hecho

Hay una silla en el MoMA de Nueva York que lleva ahí desde 1963. La Shell Chair de Hans Wegner, un carpintero danés que nunca se consideró artista. Sin adornos. Sin tornillos visibles. Sin nada que no necesite. Cada curva sigue la forma del cuerpo humano, y cada unión de madera existe porque la estructura la requiere. Wegner diseñó más de 500 sillas en su vida. Cuando le preguntaban por qué tantas, respondía: “Todavía no he hecho la perfecta.”

Esa silla es lo que quiero decir cuando digo “bien hecho.”

La mayoría de la gente, cuando habla de software “bien hecho,” quiere decir software sin bugs. Un sistema que no se cae, que responde rápido, que hace lo que prometía. Y sí, eso es necesario. Pero es necesario del mismo modo en que es necesario que una silla no se rompa cuando te sientas. No romper al contacto es el mínimo. No el estándar.

El software bien hecho es como la silla de Wegner: cumple su propósito con exactitud, no contiene nada innecesario, y envejece bien. Puedes usarlo durante años sin que se vuelva un estorbo. Se adapta a tus necesidades porque fue diseñado con suficiente comprensión del problema como para anticipar el cambio sin intentar predecirlo. Es simple en la superficie y preciso en la estructura. No te pide que te adaptes a él --- él se adapta a ti.

Esto suena abstracto. Quiero hacerlo concreto. Y para eso necesito hablar de filosofía.

Pirsig y la motocicleta

En 1974, Robert Pirsig publicó Zen y el arte del mantenimiento de motocicletas, un libro que vendió cinco millones de copias y que, debajo de su historia de un viaje en moto por Estados Unidos, es un tratado sobre qué significa “calidad.”

Pirsig identifica dos formas de ver el mundo. La visión romántica se enfoca en la experiencia inmediata: cómo se ve algo, cómo se siente, la primera impresión. La visión clásica se enfoca en la estructura: cómo funciona algo, por qué está organizado así, la lógica interna que sostiene la apariencia.

Su argumento central es que la calidad real requiere ambas. Un motor de motocicleta que funciona perfectamente pero está cubierto de grasa y herrumbre no tiene calidad (le falta la dimensión romántica). Una motocicleta cromada y reluciente cuyo motor se calienta cada cincuenta kilómetros tampoco la tiene (le falta la dimensión clásica). La calidad genuina vive en la intersección: la cosa que funciona impecablemente y se presenta con claridad.

Pirsig cuenta una historia sobre su amigo John, que viaja con él en otra moto. John no quiere saber nada sobre el funcionamiento interno de su motocicleta. Cuando algo se descompone, lo lleva al mecánico. La máquina es una caja negra que produce experiencias --- el viento, la carretera, la libertad --- y abrir esa caja le arruina la experiencia. John es puramente romántico.

Pirsig, en cambio, no puede evitar pensar en los pistones, el carburador, el timing del encendido. Para él, entender la estructura es la experiencia. La belleza de una motocicleta bien afinada está tanto en su sonido como en la elegancia de su ingeniería. Pirsig es clásico.

La calidad del software tiene la misma dualidad. Un sistema puede tener una interfaz hermosa pero un código insostenible. O una arquitectura elegante pero una experiencia de usuario confusa. “Bien hecho” significa que ambas dimensiones están resueltas.

Piensa en las aplicaciones que usas todos los días. Las que realmente te gustan --- no las que toleras, sino las que disfrutas --- probablemente tienen ambas cualidades. La interfaz es clara y agradable (romántica). Y cuando las usas intensamente, descubres que los flujos de trabajo están bien pensados, que los datos se sincronizan correctamente, que los errores se manejan con gracia, que el sistema anticipa tus necesidades sin abrumarte con opciones (clásica).

Las que te frustran suelen fallar en una de las dos dimensiones. O son bonitas pero frágiles: se ven bien en la demo y se rompen en el uso real. O son sólidas pero hostiles. Funcionan, pero usarlas es una experiencia desagradable, llena de fricciones innecesarias y flujos que parecen diseñados para la conveniencia del programador, no del usuario.

La industria del software tiene una tendencia histórica a valorar la dimensión clásica sobre la romántica. “Funciona” se considera suficiente. El código es elegante, la arquitectura está bien, las pruebas pasan, y si el usuario tiene que leer un manual para entender la interfaz, bueno, “es un problema de entrenamiento.” Esta inclinación clásica ha producido décadas de software poderoso pero hostil, desde las interfaces de línea de comandos de Unix hasta los ERPs empresariales que requieren certificación para operar.

Pero el péndulo también oscila demasiado al otro lado. El diseño centrado en el usuario, llevado al extremo, produce software que es delicioso al primer contacto pero hueco por dentro. Interfaces que priorizan la estética sobre la función. Animaciones que retrasan la productividad. Simplificaciones que esconden complejidad necesaria en lugar de resolverla. Software romántico que se desmorona bajo presión.

La disciplina del artesano es mantener ambas dimensiones en tensión productiva. No sacrificar la estructura por la apariencia ni la experiencia por la elegancia técnica. Cada decisión vive en esa intersección, y cada decisión es un juicio, no una fórmula.

Wabi-sabi digital

Hay un concepto estético japonés llamado wabi-sabi que tiene mucho que enseñarnos sobre software. Más de lo que parece a primera vista.

Wabi-sabi es la estética de lo imperfecto, lo impermanente y lo incompleto. Emerge de la tradición budista zen y se manifiesta en la cerámica, la arquitectura, los jardines y la ceremonia del té. Un tazón de té raku con una grieta reparada en oro (kintsugi) es más bello que un tazón perfecto, porque la grieta cuenta una historia. Un jardín zen no intenta replicar la naturaleza --- la sugiere con arena y piedras, dejando espacio para que tu mente complete la imagen.

Los tres principios centrales de wabi-sabi son: fukinsei (asimetría, irregularidad), kanso (simplicidad, eliminación de lo innecesario) y koko (austeridad, la belleza de lo esencial). Estos principios, traducidos al software, producen una filosofía de desarrollo que va radicalmente en contra de las tendencias dominantes de la industria.

Impermanencia. El software cambia. Siempre ha cambiado y siempre cambiará. La industria trata esto como un problema que resolver: frameworks que prometen estabilidad, arquitecturas que prometen durabilidad, documentación que promete capturar el estado del sistema para siempre. Wabi-sabi lo trata como una propiedad fundamental que hay que aceptar y diseñar para ella.

El software bien hecho no pretende ser permanente. Pretende ser fácil de cambiar. Hay una diferencia enorme entre construir algo que intenta no cambiar nunca y construir algo que acepta el cambio como parte de su naturaleza. Lo primero produce sistemas rígidos y frágiles que acumulan deuda técnica porque cada modificación lucha contra la estructura original. Lo segundo produce sistemas flexibles que envejecen bien porque el cambio fue una consideración de diseño, no una agresión posterior.

Piensa en la diferencia entre un edificio de concreto monolítico y una casa tradicional japonesa con paredes de shoji (papel y madera). El edificio de concreto es inmutable: cualquier cambio requiere demoler y reconstruir. La casa japonesa se reconfigura deslizando paneles. Ambos son refugio. Pero uno asume permanencia y el otro asume cambio, y esa diferencia de filosofía produce estructuras radicalmente diferentes.

Imperfección. “Good enough” tiene mala reputación en ingeniería de software. Suena a mediocridad, a cortar esquinas. Pero wabi-sabi propone que la búsqueda de la perfección es enemiga de la bondad. No porque la perfección sea inalcanzable (que lo es), sino porque la obsesión con alcanzarla distorsiona las decisiones.

El equipo que busca la solución perfecta no entrega nada durante meses mientras evalúa opciones. El equipo que acepta la imperfección entrega algo que funciona la semana siguiente y lo mejora basándose en uso real. ¿Cuál produjo mejor software al final del trimestre? Casi siempre el segundo, porque su software incorpora retroalimentación del mundo real mientras el primero sigue refinando abstracciones teóricas.

Esto no es un argumento a favor de la chapucería. Es un argumento a favor de la honestidad sobre qué nivel de refinamiento es apropiado para cada situación. Un prototipo que valida una hipótesis de negocio no necesita cobertura de pruebas del 95%. Un sistema de procesamiento de pagos sí. La imperfección aceptable depende del contexto, y el artesano es la persona que sabe calibrar esa diferencia.

El artesano no busca la perfección. Busca la adecuación: el nivel exacto de calidad que el problema requiere. Ni más ni menos.

Incompletitud. El jardín zen más famoso del mundo, en el templo Ryoan-ji de Kioto, tiene quince piedras. Desde cualquier punto de observación solo puedes ver catorce. No importa dónde te sientes, siempre hay una piedra oculta. Esto es deliberado. La incompletitud invita a la participación del observador, que completa el jardín en su mente.

El software tiene una relación complicada con la incompletitud. La industria nos ha condicionado a pensar que “completo” es bueno y “incompleto” es un fracaso. Pero el software más exitoso de la historia es casi siempre incompleto. Deliberada, estratégicamente incompleto.

Unix no hace nada por sí solo. Es un conjunto de herramientas pequeñas que puedes combinar para hacer casi cualquier cosa. Cada herramienta es “incompleta” en el sentido de que no resuelve todo el problema. Pero esa incompletitud es precisamente lo que hace al sistema poderoso: te permite combinar las piezas de formas que los creadores nunca anticiparon.

El iPhone original no tenía copiar y pegar. No tenía apps de terceros. No tenía MMS. Era espectacularmente incompleto. Y era espectacularmente exitoso, porque lo que sí hacía lo hacía extraordinariamente bien. La incompletitud no fue un defecto. Fue una decisión de diseño que priorizaba la excelencia de lo presente sobre la mediocridad de lo exhaustivo.

Enviar lo que importa, no todo. Construir la funcionalidad central con profundidad en lugar de construir toda la funcionalidad con superficialidad. Eso es wabi-sabi aplicado al software, y es una de las decisiones más difíciles que un equipo puede tomar, porque requiere el coraje de decir “esto no” cuando la presión es siempre agregar más.

El enemigo del craft: la complejidad gratuita

Si la filosofía del artesano se resume en una disciplina, es esta: saber qué no construir.

La complejidad en software tiene dos formas. La esencial es inherente al problema: un sistema de nómina es complejo porque las leyes fiscales son complejas. No hay forma de simplificar la ley fiscal reescribiendo el código. La accidental es la que agregamos nosotros: la capa de abstracción que nadie pidió, el patrón de diseño que aplicamos porque lo aprendimos la semana pasada, la arquitectura de microservicios para una aplicación que tiene tres endpoints.

Fred Brooks hizo esta distinción en 1986 en su ensayo “No Silver Bullet,” y cuarenta años después sigue siendo la observación más penetrante sobre ingeniería de software que existe. La mayor parte del sufrimiento en software no viene de la complejidad del problema. Viene de la complejidad que agregamos al resolverlo.

¿Por qué agregamos complejidad gratuita? Por varias razones, ninguna de ellas noble.

Por miedo. “¿Y si necesitamos escalar a un millón de usuarios?” Entonces construye para un millón de usuarios cuando tengas cien mil. Construir para un millón cuando tienes cien es ingeniería basada en ansiedad, no en datos. El código que escribes para manejar escala que no necesitas es código que tienes que mantener, depurar y entender, y que hace más lento cada cambio futuro.

Por ego. La arquitectura compleja se siente como trabajo sofisticado. Un diagrama con veinte microservicios y tres colas de mensajes es impresionante en una presentación. Que ese diagrama sea necesario para una aplicación con 500 usuarios es irrelevante --- se ve profesional. La complejidad como demostración de competencia técnica es una de las patologías más destructivas de la industria.

Por imitación. Netflix usa microservicios, así que nosotros deberíamos usar microservicios. Google tiene un sistema de build distribuido, o sea que nosotros deberíamos tener uno. Las empresas más exitosas del mundo son exitosas a pesar de su complejidad, no gracias a ella. Copiar su arquitectura sin copiar su escala es como ponerte el uniforme de un astronauta y esperar llegar a la luna.

Por falta de restricciones. Cuando el tiempo y el presupuesto son ilimitados (o parecen ilimitados) no hay presión para simplificar. La restricción es amiga del buen diseño. Un equipo que tiene seis semanas para entregar no tiene tiempo para complejidad gratuita. Un equipo que tiene seis meses se inventa problemas que resolver.

La complejidad gratuita es deuda que pagas con interés compuesto. Cada capa innecesaria hace más lenta cada modificación futura. Cada abstracción prematura es una apuesta sobre un futuro que probablemente no llegará.

El artesano del software se define, más que por lo que construye, por lo que se niega a construir. Propone un monolito cuando el equipo quiere microservicios. Elimina una tabla de la base de datos porque nadie la usa. Dice “no necesitamos eso” cuando todos están entusiasmados con la nueva funcionalidad. Es impopular por las razones correctas.

Hay una frase atribuida a Saint-Exupery (sí, el de El Principito, que además era aviador e inventor): “La perfección se alcanza, no cuando no hay nada más que agregar, sino cuando no hay nada más que quitar.” Sea o no la cita exacta, la idea es profundamente correcta. El software bien hecho no se reconoce por todo lo que tiene, sino por todo lo que logra no tener.

Máquinas que hacen máquinas

Aquí es donde la filosofía se encuentra con la realidad de 2026.

Si la IA escribe el código, ¿qué significa “artesanía”? Si la producción se automatiza, ¿dónde vive el oficio? Suenan a preguntas existenciales. La respuesta es sorprendentemente práctica.

Piensa en un director de cine. El director no opera la cámara (generalmente). No edita el negativo. No mezcla el sonido. No construye los sets. Cada una de esas tareas la ejecuta un especialista con habilidades técnicas enormes. Pero nadie confundiría la habilidad del camarógrafo con la habilidad del director. El director decide qué historia contar, cómo contarla, qué incluir, qué cortar, qué enfatizar, qué dejar en la ambigüedad. Su oficio es de otro orden: no ejecuta, dirige la ejecución.

Cuando la IA escribe código, el desarrollador se convierte en director. Su oficio se mueve hacia arriba en la cadena de decisiones. Ya no es “¿cómo implemento esta función?” sino “¿debería existir esta función?” Ya no es “¿cuál es el algoritmo más eficiente?” sino “¿estamos resolviendo el problema correcto?” Ya no es “¿cómo estructuro este módulo?” sino “¿por qué existe este módulo y cómo encaja en el sistema?”

Este desplazamiento hacia arriba no reduce la dificultad. La aumenta. Es más fácil escribir código que decidir qué código debería escribirse. Es más fácil implementar una especificación que cuestionar si la especificación tiene sentido. Es más fácil resolver un problema técnico que determinar si el problema vale la pena resolverlo.

La artesanía del software en la era de la IA se manifiesta en varias dimensiones nuevas.

El oficio del prompting arquitectónico. No me refiero a escribir prompts bonitos. Me refiero a la habilidad de descomponer un sistema complejo en instrucciones que una IA pueda ejecutar correctamente. Esto requiere un entendimiento profundo de la arquitectura, los patrones, las dependencias y los edge cases. La persona que puede pedir “construye una API REST con autenticación” obtiene un resultado genérico. La persona que puede especificar el modelo de datos, los patrones de acceso, las políticas de autorización, los modos de falla y las restricciones de rendimiento obtiene un resultado que funciona en producción.

El oficio de la evaluación. Cuando la IA genera código, alguien tiene que decidir si el código es bueno. No si compila, no si pasa los tests, sino si es bueno. Si la arquitectura es apropiada. Si las decisiones de diseño son correctas. Si la solución es mantenible. Esta evaluación requiere exactamente el tipo de juicio que define al artesano: la capacidad de distinguir entre “funciona” y “funciona bien.”

El oficio de la composición. La IA genera piezas. El artesano las ensambla en un todo coherente. Esto es más difícil de lo que suena. Un sistema no es una colección de partes que funcionan individualmente, es un conjunto de partes que funcionan juntas. La habilidad de componer módulos generados por IA en un sistema que tiene consistencia, claridad y coherencia es una forma de artesanía que no existía hace tres años.

El oficio de la restricción. Quizás el más importante. Cuando la IA puede construir cualquier cosa en horas, la tentación de construir todo es enorme. “Agreguemos esta funcionalidad, la IA lo hace en veinte minutos.” Pero cada funcionalidad agregada es complejidad permanente. El artesano en la era de la IA es, más que nunca, la persona que dice no. Porque la facilidad de construcción no reduce el costo de mantenimiento. Cada línea de código, la haya escrito un humano o una máquina, es una línea que alguien tendrá que entender, depurar y modificar en el futuro.

El artesano del siglo XXI no se define por su habilidad de producir. Se define por su criterio para decidir qué merece ser producido.

Una ética del software

Quiero terminar con algo que rara vez se discute en la industria del software: la dimensión moral de la calidad.

Cuando el software es malo (no malo como “tiene bugs,” sino malo como “es innecesariamente confuso, frágil, lento, o complicado”) alguien paga el costo. Y ese alguien casi nunca es el desarrollador que lo escribió.

El empleado que pierde treinta minutos al día peleando con un ERP mal diseñado paga el costo. La enfermera que tiene que hacer seis clics para registrar un signo vital porque nadie pensó en su flujo de trabajo paga el costo. El pequeño empresario que no puede entender su propio dashboard de ventas paga el costo. La persona mayor que no puede completar un trámite en línea porque la interfaz asume habilidades digitales que no tiene paga el costo.

Estos costos son reales. Se miden en horas perdidas, frustración acumulada, errores inducidos por el sistema, y oportunidades desperdiciadas. Y se distribuyen de manera regresiva: las personas con menos poder, menos opciones y menos soporte técnico son las que más sufren el software mal hecho.

Hay una palabra para producir algo cuyo costo lo pagan otros: es irresponsabilidad. Y cuando ese algo se produce a sabiendas --- cuando el equipo sabe que la interfaz es confusa pero la entrega de todas formas porque el deadline no negocia --- se acerca a algo más grave.

No estoy sugiriendo que cada bug sea una falla ética. La imperfección es inevitable y, como discutimos, a veces deseable. Lo que sugiero es que la indiferencia deliberada hacia la calidad tiene una dimensión moral que la industria prefiere no examinar.

La industria del software se ha construido sobre una cultura que normaliza la mediocridad. “Move fast and break things” fue literalmente un eslogan corporativo. “Shipping is a feature” se repite como si fuera sabiduría, cuando la versión honesta sería “entregar es una prioridad, pero entregar basura no es un logro.” Y el lenguaje que usamos lo delata: “deuda técnica” como si fuera una inversión estratégica y no negligencia acumulada. “MVP” como excusa para software que no merece las siglas “viable.”

Comparar esto con otras profesiones es revelador. Un arquitecto que diseña un edificio incómodo y confuso no se defiende diciendo “pero se mantiene en pie.” Un médico que prescribe un tratamiento efectivo pero innecesariamente doloroso no dice “pero el paciente se curó.” En otras profesiones, “funciona” es el piso, no el techo. En software, demasiado seguido es el techo.

El software mal hecho no es un problema estético. Es un problema ético. Cada interfaz confusa le roba tiempo a alguien que no eligió usarla.

¿Qué significa tomar la calidad como una postura ética? Significa varias cosas concretas.

Significa que cuando estás decidiendo entre entregar algo mediocre a tiempo o algo bueno una semana tarde, el cálculo incluye a las personas que van a usar el software, no solo al gerente que estableció el deadline. A veces la respuesta correcta es entregar a tiempo. A veces es pedir la semana extra. Pero la decisión tiene que considerar al usuario final, no solo al stakeholder que firma los cheques.

Significa que la simplicidad no es una preferencia estética sino una obligación. Cada capa de complejidad innecesaria es un costo que se transfiere al usuario. Cada menú que requiere tres clics cuando podría requerir uno es una decisión que priorizó la conveniencia del desarrollador sobre la del usuario. Cada mensaje de error críptico es una abdicación de responsabilidad.

Significa que la accesibilidad no es un “nice to have” sino un requisito moral. Cuando tu software excluye a personas con discapacidades visuales, motoras o cognitivas, estás haciendo una declaración sobre quién merece acceder a tu servicio. Esa declaración no se vuelve más aceptable porque sea implícita.

Significa que la documentación --- tanto técnica como de usuario --- es un acto de respeto. Documentar tu código es respetar al desarrollador que viene después de ti. Documentar tu producto es respetar al usuario que tiene que entenderlo sin tu ayuda.

No estoy proponiendo una utopía. Las restricciones de tiempo, presupuesto y recursos son reales. A veces hay que enviar software imperfecto porque la alternativa es no enviar nada. La ética del software no es absolutista. Es contextual y pragmática.

Pero existe. Y el artesano es la persona que la toma en serio.

La silla de Wegner en el MoMA no es perfecta. Él mismo lo dijo. Pero cada decisión en esa silla fue tomada con conciencia de que alguien se iba a sentar en ella. Que alguien iba a pasar horas de su vida en contacto con ese objeto. Que la experiencia de esa persona importaba, no como dato de mercado, sino como hecho humano.

Eso es lo que significa hacer software bien hecho. No la ausencia de defectos. No la pureza técnica. No la elegancia arquitectónica como fin en sí misma. Sino la conciencia persistente, a veces incómoda, de que lo que construyes va a formar parte de la vida de otra persona, y que esa persona merece que te hayas tomado el trabajo en serio.

No hace falta ser perfecto. Hace falta que te importe.