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.

One Response to Make It Work, Make It Right, Make It Fast

  1. Sebastián says:

    Cuando empiezo a pensar en optimizar prematuramente ni bien empiezo un proyecto me acuerdo de “Make It Work, Make It Right, Make It Fast” incluso llego a colocarlo en comentario dentro del código para no olvidarme jaja.

    ¡Saludos!

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>