Programar rápido, programar despacio

Tras varios años de vida del proyecto pasamos la gran mayoría de las horas estudiando el código, buscando bugs o tratando de entenderlo.

Miguel A. Gómez · Seguir2 min read · 3 Ago 2023

El reconocido psicólogo y Premio Nobel de Economía, Daniel Kahneman, concibió la idea de que hay dos sistemas de pensamiento que dirigen la forma en que pensamos:

El sistema 1 es rápido, emocional e intuitivo.

El sistema 2 es lento, racional y lógico.

Lo que Kahneman dice en su libro “Pensar rápido, pensar despacio”,  es que siempre que podemos recurrimos al sistema "rápido".

El sistema lento es costoso y agotador.

Compartimos el sistema 1 con muchos animales, lo que nos permite hacer cosas como:

Determinar si un objeto está más lejos que otro.

Caminar manteniendo el equilibrio.

O localizar de dónde viene un sonido específico.

También es bueno en el reconocimiento de patrones, gracias a esto podemos:

Completar la frase “de tal palo…”.

Resolver cálculos sencillos 5x5=?.

O en el caso de los developers, entender código sencillo y directo.

En cambio, el sistema lento es una característica que solo tenemos los humanos.

Es el responsable del razonamiento complejo.

Nos permite planificar eventos futuros, participar en debates o debuggear un código enrevesado.

Como dijimos al principio, usar el sistema lento conlleva un sobreesfuerzo mental.

A la hora de programar también avanzamos a dos velocidades.

Verás.

Cuando empezamos un proyecto nuevo, un greenfield, vamos muy rápido implementando las primeras funcionalidades.

Prácticamente usamos todo el rato el sistema 1.

Nos cabe todo el código en un mapa mental.

Pero esto no dura mucho tiempo.

Poco a poco, casi sin darnos cuenta, el ritmo se va perdiendo.

Empezamos a usar mucho más el sistema lento que el sistema rápido.

Con el paso de los meses, vamos invirtiendo cada vez menos esfuerzo  en escribir código y más en leerlo, sobre todo depurando.

Y tras varios años de vida del proyecto pasamos la gran mayoría de las horas estudiando el código, buscando bugs o tratando de entenderlo.

El código acaba degenerándose.

Pero, ¿por qué pasa esto?

El principal motivo es porque añadimos más complejidad de la necesaria para resolver el problema.

Nos gusta hacer las cosas más difíciles de lo que son.

Escribimos código innecesario o escogemos soluciones mucho más complicadas de lo que deberían ser, sin darnos cuenta de que hay otras mucho más sencillas.

Toda esa morralla extra que añadimos se conoce como complejidad accidental.

Además, tenemos el grave problema de que le prestamos muy poca atención a los pequeños detalles.

Caemos en descuidos triviales que poco a poco van empeorando la legibilidad del código.

Lo que provoca que cada vez podamos utilizar menos el sistema rápido y que introducir nuevos cambios acabe siendo un proceso tedioso.

Bien.

¿Cómo podemos evitar esto?

Aplicando las 4 reglas del código sostenible, que son:

• El código está bien cubierto por baterías de test automáticos.
• Esos test son sostenibles: son útiles y fáciles de mantener.
• Las abstracciones son adecuadas y precisas.
• Hay una notable intención, bien explícita, en cada línea de código escrita.