La complejidad tiene que vivir en algún lugar. Si tienes suerte, vive en lugares bien definidos. En el código donde decidiste que debería ir un poco de complejidad, en la documentación que respalda el código, en las sesiones de capacitación para tus ingenieros. Le das un lugar sin tratar de ocultarlo todo. Tú creas formas de manejarlo. Sabes a dónde ir para encontrarte con él cuando lo necesites. Si tienes mala suerte y solo intentaste fingir que la complejidad se podía evitar por completo, no tiene a lugar al que ir en este mundo. Pero no deja de existir.
En el mundo de desarrollo de software creemos que nuestra chamba es “evitar” la complejidad.
¿Cuántas veces te han rechazado un PR porque el código es “demasiado complejo”?
Lo que se nos olvida es que, inherentemente, desarrollar software se tata de resolver problemas complejos. Y para resolver problemas complejos muchas veces se necesitan soluciones complejas.
Aquí es donde entra un concepto del que (creo que) he hablado antes en este blog: que algo sea complejo no necesariamente significa que tiene que ser complicado; así como la simplicidad no implica sencillez.
Puedes crear soluciones sencillas para problemas complejos. Y puedes crear soluciones complicadas para problemas simples.
Muchos equipos de desarrollo están mal calibrados en sus prioridades, e intentan evitar la complejidad a toda costa, cuando lo que deberían de estar evitando es crear soluciones innecesariamente complicadas.
SI estás resolviendo un problema simple, aplica una solución sencilla.
Para un problema complejo, intenta resolverlo de manera sencilla primero, y cede ante las complicaciones cuando sea necesario. Pero no pretendas que puedes hacer desaparecer la complejidad de la ecuación.
Deja un comentario