Done is better than perfect

El Software es una disciplina dinámica y bastante viva. No me refiero a lo ya conocido que la tecnología válida hoy mañana está obsoleta. Me refiero a que nunca puedes dar algo por cerrado, todo es mejorable. El código que escribes hoy, mañana te das cuenta que lo puedes mejorar. El caso de uso que has implementado hoy, mañana te das cuenta que está incompleto o, incluso, obsoleto. Se te ocurre una nueva idea, un comentario,... Algo normal con tareas que requieren cierta creatividad.

Esto provoca muchas veces entrar en la dinámica de buscar siempre algo mejor, no cerrar una implementación hasta que no cumple los estándares de perfección marcados, tener el producto final. Es muy fácil entrar en una situación de encontrar una solución mejor y no saber parar. Pero esto puede llevar a muchos problemas.

Uno de ellos es no ver nunca el momento de cerrar. Cada día te das cuenta que puedes mejorar lo que hiciste lo de ayer, o que no tienes lo que pretendías tener, o se te ha ocurrido una idea nueva, o... Y la lista no acaba y retrasas y retrasas y retrasas. Y el producto nunca sale y pierdes oportunidades.

Por eso siempre he sido muy fan de la expresión que titula este post: "Done is better than perfect". Mejor tener algo hecho que perseguir esa perfección que difícilmente llega y que, como dice el tweet que encabeza el post, hace que el trabajo nunca termine. Un producto hecho, siempre se podrá lanzar, probarlo y, mientras ves si funciona, ir trabajando en esa perfección que quieres alcanzar. Lo que se conoce como MVP (Product Viable Mínimo)

También hay quien lo ve desde otro punto de vista, el de "Fail fast", que no es más que prueba rápido algo. Si te funciona ya lo tienes en marcha, pero si algo falla lo sabrás rápido.

Cuando hablo de no perseguir la perfección no me refiero a lanzar cualquier cosa. Perfección y calidad son conceptos muy diferenciados. Hagas lo que hagas, siempre deberá tener unos mínimos de calidad que tú te marques, los que quieres que te identifiquen, aunque no sea la solución final que deseas.

Software is an alive and dynamic discipline. I don't mean about what we know that valid technology today is obsolete tomorrow. I mean that one can never close anything, since everything is improvable. Code written today, one realises the next day that can be improved. The use case implemented today, one realises later that is not complete or, even obsolete. A new idea comes up, new comments,... Something normal with tasks that require some creativity.

This makes many times to get into the cycle of always looking for the best solution. Not finding the time to close an implementation if it doesn't fit with the perfection standards seeked, what one considers the final product. It's easy to be in the situation of finding a better solution and not finding the stop point.

You never see the right time to finish. Everyday you realise you can improve what you did yesterday, or you got a new idea, or... And the list is endless and delay, and delay. And the product is never launched and you lose opportunities.

That's why I've always been such a fan of the highlight of this post: "Done is better than perfect". It's always better to have something done that waiting for that perfection and, as the tweet at the beginning of this post says, makes the work never finishes. You can always launch something done, test it and, in the meantime, improve it to the level you would like to reach. Which is known as MVP (Minimum Viable Product)

Also known as "Fail fast", which is something as simple as, test it as fast as you can. If it works you already have something, if it fails you'll know it quickly.

When I talk about not pursuing the perfection I don't mean launching whatever. Perfection and quality are different concepts. Whatever you do, do it always with your expected quality levels, those you want to be identified, although it's not the final solution you wish.