5/ Rápido y sucio no, házmelo cuanto peor mejor

Mantener la simplicidad nos recuerda al principio KISS (Keep It Simple, Stupid!) pero en el caso de «Peor es mejor» se refiere a q el diseño debe ser simple en su implementación y en su interfaz pero sobre todo en la implementación

El software basado en «Peor es mejor» tendrá más éxito q un software desarrollado buscando hacer «lo correcto» (enfoque MIT)

Pongamos que desarrollas un programa que no es lo mejor del mundo pero es simple y funciona.

6/ Rápido y sucio no, házmelo cuanto peor mejor

Será fácil de adaptar a otro tipo de arquitecturas, más rápido y con menor esfuerzo que uno complejo que podría ser mucho mejor y con más funcionalidades

El software peor se moverá rápidamente porque se porta y compila sin andar instalando mil dependencias y adaptaciones.

Una vez distribuido el software «peor» generará una presión por mejorar sus funcionalidades pero … los usuarios ya habrán aceptado lo peor como mejor que lo correcto.

7/ Rápido y sucio no, házmelo cuanto peor mejor

Ganará aceptación, condicionará a los users a aceptar menos y luego será mejorado para ir acercándose a «lo correcto». Nadie va a querer (ni los expertos) ponerse a mejorar algo muy complejo … mientras que algo «peor» pero más sencillo será «mejor» y más gente le meterá mano para mejorarlo.

Resumen

Mientras que «Rápido y sucio» es una filosofía «tente mientras cobro», cortoplacista «Peor es mejor» busca la viralidad ...

8/ Rápido y sucio no, házmelo cuanto peor mejor

Esto en redes se ve bien con lo de «Peor es mejor». Un toot complejo en el q se detallan cosas técnicas tendrá poca aceptación y nadie comentará mientras que un toot en el q se habla de algo que todo el mundo entiende, que se pide a gritos colaboración para mejorar … posiblemente tendrá más comentarios y será de mayor utilidad para un número más amplio de gente.

Por tanto hemos aprendido que házmelo rápido y sucio no, házmelo peor porque es mejor