Una de las cosas que más buscamos cuando construimos productos es simplificar. Queremos menos pasos, menos infraestructura, menos dependencias y menos cosas que mantener. Muchas veces esa búsqueda mejora realmente un producto, porque eliminar elementos innecesarios puede hacer que todo sea más fácil de entender y utilizar. El problema aparece cuando empezamos a confundir simplificar con hacer desaparecer la complejidad.
Pensé bastante en esto leyendo sobre las llamadas blockchains que buscan la simplicidad en la partición humana. La idea, reducida a lo esencial, consiste en conseguir que los validadores no necesiten almacenar grandes cantidades de información para verificar lo que ocurre dentro de la red. Si esto fuera posible de una manera práctica, operar un nodo podría requerir muchos menos recursos y sería más fácil que nuevas personas participaran en la validación del sistema. Cabe destacar que en Hive se ha trabajado en hacer que los nodos sean más ligeros.
Lo interesante es que la información que dejamos de almacenar en un lugar no simplemente desaparece. En algunos modelos termina siendo el usuario quien necesita mantener determinada información actualizada para demostrar el estado de su cuenta. En otros aparecen nuevos actores que almacenan esa información y generan las pruebas necesarias cuando alguien quiere realizar una operación. El sistema puede hacerse más ligero para el validador, pero esa ligereza tiene un costo que termina apareciendo en otra parte de la arquitectura.
Cuando lo llevé fuera de blockchain me di cuenta de que hacemos algo parecido constantemente cuando desarrollamos productos. Podemos eliminar un backend tradicional y mover más lógica al cliente o navegador. Podemos reemplazar un proceso manual con una automatización y después descubrir que esa automatización también necesita mantenimiento. Podemos eliminar un intermediario porque queremos crear un sistema más abierto, pero muchas de las responsabilidades que cumplía ese intermediario siguen siendo necesarias y terminan distribuidas entre otras personas o componentes.
Eso no significa que simplificar con respecto al desarrollo sea malo. Al contrario, creo que deberíamos buscar sistemas cada vez más simples. Lo que cambia es la pregunta. Antes podría pensar principalmente en qué parte podía eliminar de una arquitectura. Ahora me interesa también saber qué ocurre con la responsabilidad que estaba asociada a esa parte y quién tendrá que asumirla después.
Porque podemos construir algo que desde nuestro lado parece extremadamente simple mientras estamos haciendo que la experiencia sea mucho más complicada para otra persona. También podemos reducir nuestra infraestructura utilizando servicios externos y sentir que eliminamos un problema, cuando en realidad lo convertimos en dependencia.
Tal vez una buena simplificación no sea aquella donde conseguimos hacer desaparecer más elementos, sino aquella donde entendemos mejor dónde debe vivir cada responsabilidad. En tecnología hay complejidades que podemos eliminar, pero existen otras que simplemente estamos moviendo de un lugar a otro.
Y saber distinguir entre ambas puede cambiar bastante la forma en la que diseñamos un producto centrado en blockchain o que usa esta teconología como base.
