Is The Lean Startup just Mud-Throwing Practice?

I'm reading The Lean Startup book (you should read it as well) and the author suggests that you should release your web as soon as possible despite it's not complete. This way maybe you engage some early adopters. After releasing something you can watch if your assumptions were right and adapt accordingly.

When reading this it came to my mind an old post by Jakob Nielsen (a usability guru) dated from 2000: The Mud-Throwing Theory of Usability. Moreover, I remember watching him in London explaining it theatrically. His theory suggested that some people were building sites like throwing mud at the wall and see if it sticks.

He, in 2000, advocated for some usability practices, just a minimum (paper-prototyping and testing with few users), before releasing anything. Does it contradict The Lean Startup ideas? Not at all, I would say.

In 2000 usability and user experience weren't as known as they are now and Jakob Nielsen was just making them widespread (and selling his services). Currently developers and designers have assumed the importance of users. When Eric Ries (the author of The Lean Startup) suggests to release as soon as possible, he talks about the MVP, Minimum Viable Product, and without usability tests it could not be "viable".

How much to invest in those tests would depend who you ask. Keep it Lean.

Las cinco disfunciones de un equipo

De Patrick Lencioni. 2002. Publicado por Empresa Activa (Urano). 215 páginas

El autor presenta sus ideas de cómo transformar un equipo que no funciona en forma de fábula: una empresa que no funciona contrata a una directora general para conseguir que sus ejecutivos funcionen como equipo. A través de esta historia el autor explica lo que él considera que son los cinco problemas que tienen los equipos.

La novelita (175 páginas del libro), aunque al final tiene diálogos imposibles, tiene buen ritmo y es entretenida. Justo después el autor ha añadido la explicación de las cinco disfunciones y sugerencias para corregirlas.

Las cinco disfunciones de un equipo (según el autor) son:
1. Ausencia de confianza. Los miembros del equipo deberían conocerse bien y confiar unos en otros.
2. Temor al conflicto. Los conflictos son productivos y no hay que huir de ellos.
3. Falta de compromiso. Una vez se toma una decisión, todos la aceptan como si fuese suya.
4. Falta de responsabilidad. Todos los miembros del equipo deben pedir cuentas a los que no funcionan.
5. Falta de atención a los resultados. Hay que dejar claros y perseguir los resultados colectivos.

Qué quieres que te diga. Después de haber leído el Management 3.0 todo esto es muy Management 1.0. Habla de recompensar al equipo económicamente por los resultados, de fijar plazos de entrega para que el equipo funcione o de presionar al equipo. Y continuamente habla del "líder".

Nada empowering, ni auto-organización, ni nada por el estilo. Estamos de acuerdo en la diferencia entre "grupos de personas" y "equipos", y también acepto las dos primeras disfunciones, pero poco más.

Además, puede que las ediciones de "Empresa Activa", todas iguales, te predispongan en contra de un libro, y puede que sea mi caso. Si has leído alguno que ya no te ha gustado, empiezas condicionado.

Pragmatic Programmer

from journeyman to master
De Andrew Hunt y David Thomas. 1999. Publicado por Addison-Wesley Professional. 352 páginas

Me habían recomendado mucho este libro y justamente era la propuesta del Club de Lectura de Agile Barcelona, así que lo inicié con muchas ganas. No en vano es una de las primeras influencias del movimiento de Software Craftmanship.

A lo largo de 7 capítulos, los autores presentan 70 consejos (tips)  para el desarrollo de software.

Los dos primeros capítulos son fantásticos, propios de esos libros de informática que sabes que no caducan. Pero a partir del tercer capítulo la sensación ha sido "lo he leído diez años tarde".
Sin desmerecer el contenido, que es estupendo, gran parte de las ideas que se presentan ya las tenemos más que asumidas: pruebas unitarias, control de versiones, uso de texto plano, etc.

El consejo que más me ha gustado ha sido el 4, "No vivir con ventanas rotas": reparar los pequeños fallos que van quedando en el código para evitar que otros desarrolladores piensen "puedo hacer esta chapuza, ya que he visto esa otra por ahí".

Los cuentos de la sopa de piedras (ser un catalizador del cambio) y de hervir ranas (nadie se da cuenta de los cambios si vienen poco a poco), también son inspiradores, así como el consejo de good enough software (saber cuándo parar), como un pintor que sabe cuándo dejar de poner pintura.

Los dos primeros capítulos también incluyen como consejo 11 el clásico DRY, Don't repeat yourself, una definición de ortogonalidad, y el consejo de utilizar balas trazadoras (tracing bullets) para tener feedback rápido del cliente. Comentándolo con @jaumejornet, @eidrien y @albertcumplido en el club de lectura, no todos entendimos lo mismo por "balas trazadoras". Los autores presentan la idea en contraposición con la idea de "prototipo": un desarrollo exploratorio construido para posteriormente ser desechado. En ese caso yo entiendo una bala trazadora como el resultado de una iteración en metodologías ágiles. Sin más misterios.

El capítulo tres hace una defensa del uso de ficheros de texto plano y de la línea de comandos. Me recordó mucho la lectura de En el principio fue la línea de comandos (también en inglés) de Neal Stephenson, aunque en otro contexto.

En este capítulo también habla de control de versiones, dominar un editor de texto y "rubber ducking": cuando estás tratando de resolver un bug y estás atascado, comentar tus progresos en voz alta (a un patito de goma). A veces, sólo con tratar de explicarlo te das cuenta de algo que no habías tenido en cuenta. En una empresa en la que trabajé a esto le llamábamos "efecto Furby".

En los capítulos 4, 5 y 6 habla de aserciones, diseño por contrato, la Ley de Demeter, diseñar siempre para concurrencia, diseñar para las pruebas y programar por coincidencia. Esto último es el clásico "si funciona, no lo toques".
En estos capítulos también le dedica una sección a hablar del coste de los algoritmos, con aquello del O(n log(n)), aunque me ha parecido un poco fuera de lugar.

Cuando habla de refactoring propone utilizar la metáfora de la jardinería en lugar de la metáfora de la arquitectura a la hora de hablar del desarrollo de software. Muy interesante.

En el capítulo 7 se ríe de la expresión "recogida de requerimientos" y sugiere que se trata más de "excavar a por los requerimientos". También sugiere separar los requerimientos de las políticas de negocio, porque estas últimas pueden cambiar. Y en el consejo 57 dice que algunas cosas es mejor hacerlas que describirlas (por ejemplo "describe cómo hacerte el nudo de los zapatos").

En el capítulo 8 trata de resumir todo lo descrito en los capítulos anteriores poniéndolo en contexto.

He encontrado que es un libro muy interesante y recomendable, pero tenía las expectativas demasiado altas.