Book review: "Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients"

Book cover

Introduction

The book "Workout: Games, Tools & Practices to Engage People, Improve Work, and Delight Clients" is Jurgen Appelo's third book. It's like the second part of Management 3.0 which gives a different approach to management.
It focuses on management practices whereas Management 3.0 is more theoretical.

Although these kind of books aren't my favorite, I decided to read it because his blog posts are very good and I frequently read them.

Good practices

In the author's opinion, a good practice should:

• engage people and their interactions.
• enable people to improve the system.
• help to delight all clients.

This is a good pattern to know when a manager is following a good practice or not. When you have doubts about whether a practice is good or bad these three points should help you.

The top 3, for me, were kudo box (www.management30.com/kudo-box), merit money (www.management30.com/merit-money) and delegation boards (www.management30.com/delegation-boards).

I'm going to write just about kudo box and other different subject (the law of requisite variety) because I don't want to write a long blog post but If you want to know more about these practices, in the links next to them you will find a lot of information.

Law of Requisite Variety

This law says "if a system is to be stable, the number of states of its control mechanism must be greater than or equal to the number of states in the system being controlled".
This means that anything that controls a system must be at least as complex as the system being controlled.
Organizations are complex adaptative systems. Then, for example, a manager of a team in an organization should be as complex as the team who is managed. As you can image that's a ridiculous statement. In simple terms, a manager can't manage a group of people.

Kudo box

This practice consists of writing a letter to a colleague when she did something good for the team. All the letters are put in the kudo box and, for example, once a month the box is opened and all the letters are read aloud.
Each letter should focus on individual effort instead of outcome because a great outcome requires many individuals' effort.

Recap

Despite the amount of pages, this book is easy to read. What I'm more impressed about is that it gave me a different point of view on management.

I'm not a big fan of managers or management but now I know that is because of all the bad practices that I've suffered in my career.
It also shows me that it's possible to create an environment where people really want to work when we focus on the real important things (see good practices).

In short, if you have money buy this book as soon as possible or if you don't have any money the book is free when you sign up here:

https://management30.com/product/workouts/

Ejemplo mejorado de doble de test

El artículo anterior trataba de un ejemplo de doble de test de tipo stub.
El stub se llama StubUserDAO e implementa el método findUserBy, devolviendo siempre el mismo objeto.

Si quisiéramos que findUserBy devolviera otro User tendríamos que crear otra clase como StubUserDAO que devolviera ese User, ya que StubUserDAO siempre devuelve el mismo User.

Como puedes imaginarte, no es una solución flexible, ya que casi con cada nueva prueba tenemos que crear una clase parecida a StubUserDAO.

Para solucionar este problema, en este artículo te quiero presentar la versión de un doble de tipo de tipo stub:



La principal diferente, de este doble de test en relación con el anterior es que podemos cambiar el User que va a devolver el método findUserBy.
Podemos cambiar el usuario que devuelve el método utilizando el método.
En el código, el test should_throw_exception_when_passwords_are_different_version1 hace que que StubUserDAOv2 devuelva un usuario con contraseña "other_password", y el test should_throw_exception_when_passwords_are_different_version2 hace que devuelva un usuario con contraseña "another_contraseña".

Como he comentado al principio, la principal ventaja de este tipo de stub es flexible ya que permite devolver diferentes tipos de valores sin tener que crear una nueva clase.
Otra ventaja de este tipo de stub es que la configuración del stub para que devuelve el usuario es el propio stub. Al tener la configuración en el stub queda claro lo que estamos probando, porque podemos ver la contraseña del usuario y la contraseña que utilizamos en el signin al mismo tiempo ya que están al lado.
Esto simplifica mucho el comprobar que es lo que fue mal cuando el test falla.

Un par de comentarios sobre el ejemplo:

• Recuerda inicializar siempre stub. Así nos evitamos desagradables efectos secundarios como que si ejecutas todos los test no todos pasan, pero si ejecutas uno en concreto pasa (también puede ser el efecto contrario). Esto es debido a que un test comparte usuario con otro test a través del stub.
• Hay que utilizar como atributo en la clase de test el objeto StubUserDAOv2, y no UserDAO. Parece una tontería pero la primera vez que creé el stub, me quede un buen rato atascado porque Eclipse me decía que no podía utilizar el método setUserFoundByEmail y era porque utilicé UserDAO:

Refactorizar y test unitarios

Imagen de http://blog.arnaud-lefebvre.fr/

El proceso que sigo cuando estoy desarrollando una nueva funcionalidad es:

1. desarrollo la nueva funcionalidad de la forma más rápida posible para que simplemente funcione.
2. refactorizo el código para que sea más fácil de entender y para que sea más fácil de mantener.

Refactorizar es cambiar el código sin cambiar su comportamiento. El código debe de funcionar de la misma manera antes y después de cambiarlo.
Refactorizar consiste en muchos cambios pequeños en el código que hacen que nuestro código y diseño mejoren.

Cada vez que cambiamos nuestro código hay que comprobar que funciona. Los test unitarios son la forma más rápida que conozco de comprobar que el código funciona.
Si no tengo test unitarios tengo que ejecutar la aplicación y comprobar manualmente que el código que he cambiado funciona. El refactorizar se hace muchas veces por lo que hacer esta comprobación consumirá mucho de nuestro tiempo.

Resumen

Refactorizar es muy importante en mi proceso de desarrollo porque hace que mi código sea fácil de entender y de mantener.
Escribo test unitarios ya que es la forma más rápida que conozco de comprobar que mi código sigue funcionando después de refactorizar.
Si refactorizar es también importante para ti, test unitarios también deberían de ser importante debido a que la otra opción, que es comprobar de forma manual, te va a tomar mucho mas tiempo.