Make It Work, Make It Right, Make It Fast

Hace unos años, me topé con esta frase aplicada al desarrollo de
software:

”Make It Work, Make It Right, Make It Fast”

Es decir, algo como:

“Primero que funcione, luego hacerlo bien, luego hacerlo rápido”

No recuerdo la fuente original. Frecuentemente se la atribuye a Kent Beck,
pero parece que hay precedentes, ver:

http://c2.com/cgi/wiki?MakeItWorkMakeItRightMakeItFast

En la última década, comencé a comprender la aplicación de estos consejos, y
realmente pienzo que mis habilidades de desarrollo de software se vieron
mejoradas por adoptar esta manera de hacer las cosas. Podría asociar los dos
primeros pasos con TDD (Test-Driven Development), pero se puede emplear la frase
en contextos más amplios. Revisemos que pienso de cada parte, y cómo las aplico
cada día.

Make It Work

Sí, en vez de intentar hacer “LO CORRECTO” desde el vamos, pongo primero mi
esfuerzo en hacer algo que funcione (una función, un método, un rama de un caso
de uso, una experiencia de usuario). No me preocupo por si la implementación
interna es la mejor, ni trato de aplicar todos los patrones del libro. Escribo
código que funciona. Simple código, y que funciona. Siguiendo esta
recomendación, veo que escribo código simple, que me permite ir comprendiendo el
dominio del problema. Si lo que tengo que estregar es una rama de un caso de uso
(no un caso de uso completo), el entregable puede que arroje luz sobre el modelo
de negocios del dominio, y aún permite una retroalimentación temprana de parte
de los usuarios de la aplicación.

Sin embargo, si hubiera intentado desde el vamos hacer “lo correcto”, podría
haber perdido mi tiempo y esfuerzo en algo que no es seguro que es lo que el
sistema y los usuarios necesitan.

Como caso especial de aplicación de esta máxima: “make it work” es una parte
esencial de TDD, el segundo paso: hacer que el test pase a verde.

Make It Right

Solamente cuando ya tengo algo de código andando como quiero, vuelvo a él y
lo mejore. Puedo remover duplicación de código, aplicar algún patrón porque me
lo pide el contexto (evito aplicar un patrón solamente por un impulso
irresistible de “patronitis”), exploro nuevas implementaciones alternativas.
Esta es la oportunidad de remover o hacer decrecer cualquier dueda técnica que
haya quedado, cualquier reliquia de código tóxico. Si veo algo que está
implementado de forma extraña, voy y lo trato de reescribir mejor.

Cuando lo que escribo lo escribo siguiendo el flujo de trabajo de TDD, aplico
este consejo en el paso de refactoreo. TDD me ayuda a controlar el nivel de
deuda técnica, manteniéndolo a un nivel bajo. Y teniendo todo escrito bato
tests, puedo explorar con confianza otras implementaciones alternativas, sin
sufrir en el proceso. Es realmente un paso creativo. Algunos programadores
pinesas que TDD obstruye la creatividad, pero yo veo lo contrario: estos dos
pasos son una forma de ejercitarla.

Make It Fast

Solamente entonces me preocupo de la velocidad de ejecución, y cuando el caso
de uso y contexto lo amerita. Hay tantos factores que pueden influir en el
rendimiento, que sólo me pongo a revisarlo cuando YA tengo una implementación
andando. Si Uds. tienden a escribir código en las anteriores fases, pensando en
“esto lo pongo así, porque de esta manera la ejecución va a ser más rápida”, les
pediría que revisen su actitud. Yo no sé (y Uds. tampoco) si un métod será lo
suficientemente rápido, si no tenemos un claro caso de uso que necesita tal
nivel de velocidad, y sin haber MEDIDO el rendimiento antes de la optimización.
No optimizar lo que no se mide.

Más veces de las que hubiera deseado, me encuentro con proyectos donde se
tomaron decisiones apresuradas pensando en el reandimiento: alguien que agrega
procedimientos almacenados “porque son más rápidos”, pero sin tener evidencia de
esa afirmación, sin ninguna prueba automatizada que mida realmente el
rendimiento. Y entonces, comienza a emerger en el medio del sistema, un
procedimiento almacenado de cientos de líneas, con lógica de negocio incluida,
porque “así es más rápido”. Y peor, escrito sin tests.

Luego de haber practicado esta frase en mis proyectos personales y
profesionales, les puedo asegurar que realmente me he beneficiado de seguir
estos consejos. Es un placer ver cómo una idea crece hasta llegar a una
implementación concreta y sólida.

Nos leemos!

 

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 18052, 3463. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>