Simplificar
A igualdad de condiciones (“ceteris paribus”, suelen decir los economistas):
Lo simple es mejor que lo enredado.
Lo breve es mejor que lo extenso.
Lo concreto es mejor que lo vago.
Lo directo es mejor que lo indirecto.
En la práctica suelen haber tradeoffs. Por ejemplo:
Abreviar puede enredar. Típico por ejemplo al escribir líneas código demasiado clever que no se entiende tan fácil como escribir lo mismo en tres líneas.
Abstraer puede simplificar. Es la gracia de las abstracciones: remover cosas concretas para desenredar o clarificar.
Simplificar puede dejar cosas en el aire. Los proverbios son simples y recordables, pero también vagos. Una interfaz o experiencia intuitiva puede dejar muy perdido a un usuario que no entendió la simplificación que hace que sea “intuitiva” (miren la experiencia de los adultos mayores con la tecnología).
Aún así, mi tip de hoy es que vale oro sesgarse hacia lo simple, breve, concreto y directo.
¿Cuando? Cuando escribes un texto. Cuando programas. Cuando diseñas. Cuando armas procesos o procedimientos. Cuando presentas. Cuando haces un pitch. ¡Todo el tiempo!
¿Por qué no es obvio o natural? Porque lo simple no suele ser fácil. Lo directo puede incomodar. Lo concreto a veces parece mundano, poco elevado. También confundimos lo complicado/enredado como algo más pro (sobre todo cuando somos estamos partiendo y tenemos poca experiencia — pero también ocurre a todo nivel en cargo cults dentro de organizaciones). Explicar en simple requiere más esfuerzo. ¡Escribir algo más breve toma más tiempo!
“I only made this letter longer because I had not the leisure to make it shorter”
— Blaise Pascal (el mismo en cuyo honor se bautizó un lenguaje de programación)
Podría dar ejemplos para ser más concreto, pero hoy escogí ser breve. Puedo continuar en otra entrega. O mejor aún, ustedes me ayudan con casos prácticos en los comentarios:
Voy a dejar un ejemplo acá en los comentarios. No muy concreto la verdad, pero es una aplicación específica de los principios que describo en el post. En los equipos de producto solemos tener que tomar decisiones sin mucha certidumbre. ¿Nos jugamos por el feature A que es mas simple pero menos valioso para los usuarios? ¿O por el feature B que parece mas valioso pero es harto mas caro de implementar o mantener? Mi respuesta: Por el A, todo el rato. Claro que hay que ponernos de acuerdo de antemano en qué cosas esperamos que pasen si nos equivocamos y debimos habernos ido por el B. Así, en caso que esas cosas ocurran, siempre podemos complicar más nuestra solución.
Pero si hubiéramos tomado el otro camino e implementado B desde el comienzo, entonces después de implementar la solución complicada ya quedamos casados con esa complejidad, aunque quizás era innecesaria. Muy rara vez podemos darnos el lujo de simplificarlo y quitarle features a un producto.
Me recordaste el cuento más breve del mundo "Cuando despertó, el dinosaurio todavía estaba allí". Buena entrega y buen recordatorio de feature A vs B.