Carlos Ble

Carlos Ble

I am a professional software developer, I solve problems.

I also teach and mentor developers to build better software.

Working as an independent professional since 2009.

Can I help you?

  • Do you need high quality tailor-made software?
  • Need training on TDD, clean code or refactoring?
  • Is it risky? do you need advise?
  • May I pair with you to write better code?

Events

Upcoming public training courses:

  1. [in English] May 5, 6 & 7
    TDD - Train the Trainers (iSQI)
    Potsdam, Berlin
  2. [en Español] 23, 24 y 25 de Abril.
    Curso de TDD con examen de certificacion iSQI
    Madrid
  3. [en Español] 29, 30 y 31 de Octubre.
    Curso de TDD con examen de certificacion iSQI
    Madrid

Conferences:

  1. I'll be at SocratesUK 2014
  2. I'll be at the London Test Gathering Workshops.

Archive for April, 2011



La metáfora del cirujano

Robert C. Martin lleva años diciendo que un desarrollador de software debería parecerse más a un médico que a un albañil. No se refiere a connotaciones relacionadas con el sueldo, el nivel de vida o la valoración social. Se refiere a la importancia del factor humano en estas profesiones.

El grado de profesionalidad es más determinante en una operación quirúrgica que en una etapa de una cadena de montaje de una fábrica. Pueden darse excepciones lógicamente pero digamos que te preocupas más de investigar quién te va a operar del corazón que de la persona que viene a pintarte la casa. En ningún momento estoy diciendo que una profesión sea más digna o importante que otra.

Estos días viendo el programa El Cirujano me gustó ver una pequeña parte del trabajo del Doctor Julio Mayol (@juliomayol) y me pareció una metáfora excelente aplicada al desarrollo de software profesional. Veamos algunos matices:









  • El cirujano no opera solo. Además de cooperar con anestesistas y enfermeros, hay algún otro cirujano que le ayuda --> Programa en pareja.
    Si la tarea requiere una concentración y una ejecución importantes, ¿por qué confiamos en que vamos a programarlo igual de bien solos?
  • Antes de abrir al paciente, se han hecho todos los estudios posibles para conocer el problema y sus soluciones --> Analiza y haz los spikes que sean necesarios. Conoce patrones de diseño, etc. Pero ten en cuenta que si el análisis se dilata demasiado, el paciente se muere.
  • En la sala de operaciones cuenta con todo el instrumental necesario y conoce perfectamente qué herramienta debe usar en cada caso --> Domina tus herramientas. Comprende tus herramientas.
  • Desconfía de su capacidad intelectual y es lo más metódico posible para evitar errores básicos. En la operación se ve cómo el Doctor Mayol recuenta las gasas que saca del cuerpo del paciente, para no olvidar ninguna dentro antes de cerrar --> Practica Test Driven Development.
  • Conoce las posibles consecuencias de cada actuación y está preparado para que las cosas vayan mal --> Equivocate pronto, readapta y sigue.
    Es la esencia de la agilidad, fallar rápido para corregir y mejorar.
  • El cirujano no admite que el paciente le diga cuánto puede tardar en terminar la cirugía ni cómo tiene que hacerlo --> Trabaja sin prisa pero sin pausa. Puedes manterner el foco con la técnica del pomodoro.
  • El cirujano sabe que por encima de todo está la salud de su paciente --> Lo más importante es el negocio de nuestro cliente.

Podríamos seguir con una extensa lista de parecidos "razonables" (yo los veo razonables). Cuando veo todas estas medidas, lo que pienso es en profesionalidad. Si queremos que se nos respete como a un profesional de la medicina, tenemos que ser tan profesionales como ellos. Mientras sigamos trabajando sin ser suficientemente rigurosos, seguiremos estando en el lado de la magia y las ñapas.
Steve McConnell dice en Code Complete que uno de los indicadores de profesionalidad es cuando dejas de creer en la magia y te preocupas por entender el comportamiento de tus herramientas. Recuerda que las máquinas de hoy en día siguen siendo deterministas.

La metáfora del cirujano deja de ser válida en muchos aspectos. Cuando cometemos un error básico y entregamos un producto defectuosos, generalmente nadie muere por ello. Esto es positivo y muchiiisimo menos estresante para nosotros. Aunque tambien hay excepciones.
Por el contrario, en nuestro sector los cambios son mucho más rápidos y teniendo en cuenta que aparecen herramientas nuevas todos los días y que a veces te ves forzado a cambiar con rapidez, no siempre puedes dominar la herramienta. Yo mismo me equivoqué hace unos meses con la elección de la plataforma cloud para nuestro proyecto. Sintoma de que hay que seguir madurando profesionalmente. Sin embargo lo importante es la progresión, la superación, la retrospectiva.

Aunque existen situaciones (sobre todo de mercado) que obstaculizan a veces nuestra profesionalidad, la meta debe ser alcanzarla, reconocer su ausencia y perseguir su consecución. Una cosa llevará a la otra. El mercado no nos favorecerá si no lo exigimos nosotros mismos.

Debemos reivindicar nuestra competencia con hechos y no sólo con titulaciones.

¿Has cursado algún curso de TDD con nosotros? Entonces dispones de una plataforma de eLearning para continuar tu formación en eXtreme Programming:

El portal de eLearning de iExpertos

  • Para los asistentes al curso que lo hicieran a través de su empresa y que todavía continúen en esa empresa, el acceso es gratuito.
  • Para los asistentes a algún curso abierto que pagaron su propia matrícula, el acceso también es gratuito.
  • En otros casos, consulta conmigo la tarifa de acceso a la plataforma.

Hemos montado un moodle para dar continuidad a la práctica guiada de eXtreme Programming. Esto es, valor añadido para nuestros clientes, para todos aquellos que han confiado en nosotros.

En principio se van a ir planteando ejercicios (comenzamos con la kata de los Roboexplorers) para que cada cual pueda ir practicando, buscando una dificultad acorde a la formación que hemos impartido.

La idea es seguir aprendiendo juntos y estar listos para el siguiente curso presencial, que será el de TDD avanzado y que empezará a impartirse despues del verano. Dependiendo de la respuesta que tenga este sistema online, incluso habra modulos de pago alternativos a la formación presencial, acompañados de videoconferencia. Todavía no lo sabemos, depende de vuestro feedback.

Nos estamos poniendo en contacto con todos nuestros alumnos pero puede que no tengamos los datos de todos los asistentes a los cursos abiertos.

Por favor create una cuenta en el moodle lo antes posible: http://elearning.iexpertos.com/login/index.php
Sube tu foto e indica qué curso hiciste con nosotros, si fue abierto, dónde y cuándo se celebró o en qué empresa. El plazo de inscripción se cierra a finales de abril, y a principios de mayo empezamos con contenidos online.
La plataforma está temporalmente alojada en un hosting de poca capacidad. Si tienes problemas para acceder a alguna url, reintentalo varias veces, más adelante migraremos a otro servidor.

Para todas aquellas personas que nos han comentado que quieren iniciar su formación con nosotros, tanto desde España como desde Latinoamérica, decirles que todavía no tenemos el moodle preparado para esto. Más adelante ofreceremos esta opción pero a día de hoy no es posible.
En este 2011 se volverá a celebrar un curso presencial abierto de TDD en Madrid y tal vez otro en Barcelona para todos esos profesionales que quieren dar el salto a XP.

Un dojo, una causa

¿Por qué los coding dojo tiene que ser gratis? Me parece bien que sean sin ánimo de lucro porque el facilitador del dojo no tiene que trabajar con los asistentes,
"sólo" llevar la marcha del grupo. Sin embargo, se nos ha ocurrido ir un poco más lejos y aprovechar el buen rollo que produce el acto social de codificar juntos. Nuestra idea es donar dinero a alguna buena causa. El facilitador del dojo elige una ONG local. Al final del dojo explica la campaña que esa ONG está llevando en esa cuidad y los asistentes al dojo donan la cantidad que quieran. El facilitador recauda y se encarga de que el dinero llegue a su destino.

En el pasado dojo de Bilbao, la ONG elegida fue SoSBilbao.org, una protectora de animales. Apenas eramos 12 personas y se recaudarón 70€ que hoy han sido transferidos a esta protectora. Un acto muy generoso por parte de los asistentes.

Nos vemos pronto en el dojo de Barcelona, donde alguna otra buena causa se verá apoyada por la generosidad de los intrépidos desarrolladores :-)

Kata: Roboexplorers

Hoy hemos trabajado juntos por primera vez en la kata de los Roboexplorers (no encuentro ahora un nombre mejor) en el coding dojo de Bilbao. Gracias a @vgaltes y @plainconcepts por ceder el espacio y ser tan buenos anfitriones.

¿De qué van los roboexplorer? Son robots (autónomos) que juegan en un servidor de juego. Como dijo @jmbeas, es algo como la idea de @mattwynne, aunque la idea de robots en servidores es más vieja, la ví por primera vez hace mucho en la universidad.

En este caso se trata de aplicar los principios ágiles a un desarrollo que tiene un objetivo un poco distinto al de una kata tipoe StringCalculator. Se trata de escribir el mejor código posible pero llegando a producir "valor para el cliente", es decir, algo que funcione, por poco que sea lo que haga. Así que no sólo está el código, sino elegir la estrategia que produzca un resultado con valor en el menor tiempo posible y sin embargo, sin prisas.

He ideado un juego muy sencillito basado en el buscaminas y me he puesto a programar un robot y tambien un motor de juego. Al programar ambas cosas traté de analizar las ventajas y las dificultades de usar TDD para el diseño y la implementación de ambas cosas.
Sabemos de sobra que TDD es genial cuando el problema es fácilmente fraccionable en subproblemas. Cuando la división es intuitiva, la aplicación de TDD también lo es y se hace directa.
Sin embargo, cuando el problema se presenta con un nivel de abstracción mayor, es más dificil pensar en su composición.

Al programar el servidor de juego, el cual se basa en validación del estado, la aplicación de TDD no sólo ha sido fácil y directa sino imprescindible a la hora de abordar la gran casuística que se puede presentar. Sin embargo, al diseñar el robot, he terminado con más código de test que código de producción. Aproximadamente el doble.
Ha sido natural usar TDD por la costumbre de programar sólo lo que pide una especificación pero ha habido que prestar mucha atención a la fragilidad de los tests, ya que la mayoría se basan en la interacción (dobles a saco). Al ir haciendo cambios en los requisitos se ha notado enseguida el beneficio de tener una batería de tests de respaldo pero me quedaba la duda de si TDD me había ayudado a hacer emerger el diseño o si la arquitectura que tenía en mente me había aportado toda la información que necesitaba. Es decir, hasta qué punto, unos tests que te están contando con cierto detalle el comportamiento interno de tu código de producción te ayudan escribiéndolos a priori y no despues.
Cuando el código de producción ha quedado tan pequeño, la única ventaja clara es la atención que le prestas a la "testabilidad" del código y la calidad de la batería de tests que queda, lo cual no es poco. Es decir, si en este caso no hay más beneficios, lo haría por eso.

He querido presentar el problema a la gente y estudiar cómo lo abordaban. Cómo se enfrentaban a un problema que te requiere un cierto esfuerzo arquitectónico. Sin contarles nada del problema antes, para verles trabajar desde el momento cero. Por eso de momento no vamos a publicar las reglas del juego, para probarlo en más dojos por diferentes ciudades.

El resultado en este primer dojo ha sido que nadie ha terminado una
primera versión del robot. La gente empezaba a tirar líneas, con los tests por delante, pero sin saber hacia donde ir. Perdiendo el objetivo de alto nivel y sin terminar de saber qué comportamiento querían darle. Se han oido algunas frases como "TDD es bueno para el validar entrada y salida pero no para validar comportamiento, para eso mejor BDD". Esto es un indicador de que no tenemos maduro el concepto de diseño marcado por ejemplos, que es el significado de TDD y BDD. Siempre digo que TDD y BDD son lo mismo, para mí el concepto es el mismo.
Parece que la gente se empieza a defender con las katas tipo StringCalculator pero que no practica TDD/BDD en su día a día. Parece que hay un cierto malentendido entre TDD y la arquitectura o el diseño.
TDD no es ponerse a tirar código esperando que el objetivo que queremos emerja, lo que emerge son los pequeños detalles, pero no la finalidad. Esta la tenemos que saber nosotros primero para guiar la marcha con paso firme. El código te habla y te guía cuando sabes a dónde quieres ir, pero no te ayuda si tu no sabes hacia dónde vas.

En este experimento hay mucha más información que extraer como por ejemplo, de qué manera reutilizamos la información y el propio código que extraemos de los spikes. En este caso lo que ha ocurrido es que los spikes han sido directamente incluidos en código de producción, tan pronto como daban un resultado plausible. Logicamente esto nos ocurre a todos, por eso es interesante hacer el ejercicio y poner la cámara lenta a ratos.

Hacia el final de este primer dojo, los intrépidos participantes han ido encontrando el camino que les ofrecía sensación de rumbo correcto y si hubiesemos tenido tal vez un pomodoro más hubiésemos tenido robots funcionales y certeros.
Hay más matices que ya se irán contando en otros blogs y que iré enlazando desde aquí.

La idea ahora es repetir el dojo en más sitios y seguir sacando conclusiones juntos. De aquí a la CAS 2011 que se celebrará en Castellón en el último cuarto del año, vamos a ver si conseguimos completar un estudio riguroso acerca de todo esto.
Aviso que el dojo puede llegar a ser frustrante por su dificultad, pero... esto es un dojo, no un curso de TDD ;-)

Después de varios dojos pondremos el código del servidor en la red para que cualquiera pueda practicar con sus propios robots y podremos incluso organizar un campeonato.

¿Es sólo CRUD?

CRUD = Create, Read, Update, Delete, para que nos entendamos.

Pocas características útiles son sólo CRUD. Si parece CRUD puede que no hayamos pensado lo suficiente en el punto del vista del usuario final o en las decisiones de arquitectura. Puede ser CRUD, pero en principio lo consideraría un mal olor.

En nuestro proyecto actual estamos implementando la posibilidad de hacer comentarios sobre un usuario. Es decir, unos usuarios hacen comentarios de otros. En un primer momento pensé...
"esto es un CRUD, sólo hay que crear comentarios, borrarlos, publicarlos y despublicarlos... una entidad Comment con unos cuantos campos bastará y el ORM hará todo por mí".
Antes de lanzarme a tirar código a saco, sin embargo, dediqué unos minutos a analizar la situación.

La postura de "queremos la funcionalidad de los comentarios" expresada tal que así es la típica del product owner que sólo quiere meter más y más funcionalidad pero sin ponerse en la piel del usuario de verdad.

Cuando me puse a pensar como usuario me vinieron estas ideas:
Me gustaría que cuando alguien me hace un comentario, me llegase un email por si quiero poder ocultar el comentario, o simplemente para enterarme el primero. En caso que quiera ocultar el comentario quiero que haya un link directo en el email para que sea rápido y cómodo.
Me gustaría que sólo se mostrasen los últimos N comentarios y que
no me llegasen miles de avisos si algun sistema de spam intenta hacerlo.
En realidad, me gustaría poder configurar cúando me llegan notificaciones por email y cúando no.

Si me hubiese lanzado a hacer CRUD, cuando hubiese querido implementar estas características, que como usuario si me aportan mucho más sentido, probablemente hubiese comenzado el spaguetti code. Total, para hacer CRUD no uso TDD, uso el ORM y a correr. Así que de haberlo hecho, ahora tendría que seguir tirando líneas o borrar y rehacer.

De aquí la importancia de preguntarse realmente qué valor aportan para el usuario, las decisiones que tomamos sobre el producto.

Si lo planteamos ahora desde el punto de vista de la arquitectura, debemos considerar cuestiones como rendimiento, escalabilidad, interfaz de usuario y unas cuantas cosas más.
Me gustaría que los comentarios se almacenasen en caché para que el acceso fuese rápido y pudiese escalar con frontales memcache.  Esto implica que antes cambios como el borrado de comentarios la caché se debería actualizar.
Además me gustaría que a la hora de mostrar el comentario, me diese opciones de borrarlo si soy el autor, o de hacerlo invisible o visible si soy el usuario al que va dirigido el comentario. En fin, empieza a no ser trivial la forma en que voy a mostrar la información.
Además quiero que cuando alguien responda a un comentario, la conversación se vea reflejada en forma de comentarios anidados de alguna manera.
Teniendo en cuenta estas consideraciones básicas, si hubiese tirado por el CRUD, de nuevo vendría el spaguetti code.

Como siempre, lo que hemos hecho ha sido pensar primero en los casos que más nos interesan, definir los escenarios y hacer TDD de arriba a abajo sin importar del todo qué campos tendra la entidad Comment. Hemos diseñado la estrategia de caché (como ya teniamos arquitectura de caché, ha sido muy fácil) y con algún mock aquí y allá hemos podido especificar los comportamientos que van a aportar el valor que queremos.

Muchas veces el spaguetti code se produce por no detenerse 2 minutos a pensar como un usuario final o no ponerse el sombrero de arquitecto ;-)