Carlos Ble

Carlos Ble

I am a professional software developer, I solve problems.

I also teach and mentor developers to build better software.

Developing software since 2001.

Can I help you?

  • Do you need high quality tailor-made software?
  • Need training on TDD, clean code or refactoring?
  • Do you need a technical consultant?
  • May I pair with you to write better code?

Events

Upcoming training courses:

  1. TDD - [en Español] - 6 y 7 Octubre
    Gran Canaria
  2. TDD - [in English] - October 20, 21 & 22
    London, UK
  3. TDD - [en Español] - 29, 30 y 31 de Octubre.
    Madrid, Spain

Conferences:

  1. I'll be at the Agile Testing Days 2014
  2. I'll be at the London Test Gathering Workshops.

Archive for October, 2011



RS: demasiado cambio de contexto

La semana pasada hicimos la primera retrospectiva "formal" en equipo, guiada por Dani, con lo que había aprendido en el taller de Joserra Díaz en la CAS2011. Retrospectiva

El punto en el que más coincidimos es que teníamos demasiados cambios de contexto, es decir, demasiado cambio de tarea. Cuando se cambia de tarea se tardan al menos 15 minutos en ubicarse y empezar a resolverla.
Inicialmente habiamos pensado en dedicar las primeras dos horas del día a que todo el mundo resolviese incidencias y luego el resto del día todo el mundo desarrollando nuevos requisitos. Sin embargo despues de un mes parece que la idea no funciona bien y vamos a intentar que haya una pareja que se dedique toda la semana a las incidencias mientras el resto desarrolla. La pareja va rotando para que todas las semanas haya compañeros nuevos atendiendo las incidencias.

Por otra parte la automatización del proceso de despliegue aumenta su prioridad ya que el despliegue manual es muy propenso a errores.

Como me ven a mi desde la oficina

Como me ven a mi desde la oficina

Esta semana hemos empezado a hacer BDD con Javascript y Jasmine para desarrollar nuevas funcionalidades. Nos ha quedado un diseño con el que de momento estamos muy contentos.capas Estamos usando Backbone pero sólo para los DTOs y las colecciones de DTOs (models de Backbone). La cobertura de tests es casi del 100% y el diseño, muy desacoplado y reutilizable. Rotando las parejas durante la semana, hemos conseguido que casi la mitad del equipo ya esté familiarizado con este diseño y con la forma de hacer BDD. El trabajo en pareja está resultando muy muy productivo.

pyDoubles 1.4 released

Thanks to Nestor Salceda, now pyDoubles do not raise errors on assertion failures, but just fails :-). Subtle difference but an important one. The other change is a new method alias, suggested by an user:

mock.assert_that_is_satisfied()

is now also:

mock.assert_expectations()

Both methods are the same, just use whichever you fancy.

Thanks also to David Villa for some fine tuning and for packaging pyDoubles for Debian.

Thanks for your feedback, which makes this releases happen :-)

Con este post se abre una posible serie de posts de retrospectiva semanal sobre el trabajo de nuestro equipo. Las conclusiones que más suenan en mi cabeza pasan a estar escritas en el blog para que cuando las lea con el tiempo compruebe si hemos aprendido la lección o no.

La conclusión que me llevo de esta semana es que para que un equipo pequeño haga grandes cosas, todos deben ser capaces de enfrentar los problemas con la misma visión que el propietario de la empresa, además del punto de vista técnico.  Con la visión de querer hacer ganar al equipo y a la empresa, de crecer (sea lo que sea que se entienda por crecimiento). Con una visión de todo el bosque, que no se pierde entre los árboles. A veces los técnicos trabajamos desde la perspectiva equivocada, un punto de partida inadecuado.
A veces porque las personas se creen sin permiso a sugerir propuesta de un calado más profundo y a veces porque no se dan cuenta que no todo tiene que resolverse escribiendo líneas de código.

El ejemplo de la semana:

Nos ha tocado hacer frente a un problema de rendimiento en la aplicación. No sabíamos por qué pero algunos usuarios sufrían ralentización y teníamos que arreglarlo cuanto antes. En la mayoría de los casos que he visto en mi vida, el cuello de botella está en el acceso a datos (yo diría 90%) pero también hay problemas de ancho de banda que salen a relucir cuando hay mala conexión a Internet, así como posibles problemas de renderizado en máquinas antiguas (había alguna CPU al 100%). Algunas personas con más conocimiento de la aplicación sugirieron cambiar la forma en que se renderizan contenidos para reducir la cantidad de información que se envía por la red (quitar algunos controles ASP.NET) ya que no se daba con el problema en base de datos. Empezamos a mirar el código y después de 3 horas vi que el trabajo no sólo era tremendo sino muy propenso a errores. Podíamos tardar semanas en cambiar toda la aplicación y sin garantías de estabilidad. Pero lo peor de todo: sin estar seguros de la ganancia que conseguiríamos. ¿Cómo vamos  a invertir semanas sin tener ni la más remota idea del beneficio que podíamos conseguir? ¿sin saber realmente cuál era el cuello de botella? Más de uno se habría pegado tranquilamente los días haciendo ese trabajo sin más (no necesariamente de este equipo), total, como le pagan para programar...

Era mucho más rápido desplazarse hasta el cliente con una conexión 3G potente y un portátil de altas prestaciones para probar 2 cosas: Que ni el hardware ni el ancho de banda son problema. En caso que alguna de estas cosas fuese problema, es muchísimo mejor pagarle a nuestro cliente la conexión a internet y comprarle una máquina más potente para que pueda trabajar, en lugar de invertir semanas de trabajo de desarrollo.

Pero esta perspectiva sólo te viene a la cabeza si estas pensando en el dinero que va a suponer para la empresa tu decisión y tu capacidad resolutiva.

De aquí la importancia de cambiar de dimensión para ver los problemas de otro color. Según desde donde mires, te implicarás de una manera o de otra.

La otra gran lección que ha salido es que nunca nunca nunca se pueden hacer refactorings grandes en solitario, ni tan siquiera por 2 minutos, cuando no hay una gran batería de tests automáticos de respaldo. Llevaba años ya acostumbrado a tener mis tests y a hacer refactorings tranquilote y esta semana, me confié como si tuviera los tests e introduje varios bugs por refactorizar en solitario, a pesar de que fue por apenas unos minutos. Ya tenemos todos los puestos con doble teclado-ratón y doble pantalla y la ergonomía se ha mejorado así que no hay excusa para no sentarse en pareja a hacer refactoring. ¡Prohibido hacerlo en solitario!

Nuevo proyecto: SaludOnNet

foto-team-18102011En enero de 2011 tuve ocasión de compartir una semana de trabajo en la oficina de SaludOnNet en Madrid. Daniel Ortube, CTO de la empresa me contrató porque siempre mantiene un ojo en la comunidad de Agile Spain. Impartí formación de introducción a TDD y estuve 2 días trabajando con ellos en su día a día para diagnosticar posibles puntos de mejora. La experiencia fue muy buena. Se trata de una empresa con tiempo en el mercado como para no ser ya una start-up, pero que en muchos aspectos aún lo es. Sólo 6 desarrolladores y sin jerarquías ni protocolos de empresas grandes. El CEO de la empresa, Carlos Falcato, se involucró desde el primer momento en la semana de trabajo y se interesó muchísimo por los resultados y sobre todo por el qué hacer para llevar a su empresa  a lo más alto en términos de calidad para sus clientes.

En septiembre Dani había visto la propuesta de iExpertos.com de contratarnos para hacer equipo y nos lanzaron la oferta a mí y a mi buen amigo Oscar Moreno. Oscar se muda a Madrid y yo trabajo desde casa. De vez en cuando me doy un salto por Madrid para tomarnos unas birras corporativas más que nada.

El reto es grande y las metas espectaculares. La compañía está pasando de ser nacional a multinacional gracias a la calidad de su producto durante años y al know-how que se tiene del funcionamiento de la sanidad privada. No hay competencia en cuanto al know-how y tampoco en cuanto a funcionalidad del producto. Pero saben que para jugar en primera división tiene que haber un salto al siguiente nivel de calidad ténica que permita ofrecer a sus clientes el nivel de servicio correspondiente.

La historia de la empresa es bonita porque el CEO fue la persona que escribió la primera versión de su software, hace ya una década. Empezó siendo una aplicación para el negocio familiar que se basaba en el fuerte conocimiento del dominio. Ya hace años que Carlos no tiene tiempo de escribir ni una sola línea de código :-)

Nos encontramos con 800k (800.000) líneas de código legado que necesitan soportar ahora gran cantidad de cambios (nueva funcionalidad). Vamos a pasar de miles de usuarios a millones y nuestros usuarios ya no solo estarán en España sino en toda Latinoamérica y pronto en Norteamérica también. Y como en toda empresa de desarrollo de software, hay mucha deuda técnica. Vértigo por un lado y reto por otro.

daily1En este primer de trabajo hemos introducido kanban como proceso y estamos haciendo toneladas de refactoring acompañado de tests automáticos. En principio son tests de integración pero ya empezamos a tener tests unitarios. Hacemos un daily meeting de 15 minutos por la mañana con un iPad que me permite ver el panel y ver a los demás con buena mobilidad, imagen y sonido. Tenemos un kanban para incidencias y un kanban de desarrollo de nueva funcionalidad. El objetivo de esta primera etapa es estabilizar el proceso de releases, con plazos semanales. El product owner deja la semana planificada el viernes, con lo que le gustaria tener para el próximo y el lunes, el equipo de desarrollo decide cuántas de esas tarjetas se compromete a tener para el viernes, sin perjudicar la calidad del producto.
Ya vamos agregando tests automáticos que demuestran los bugs antes de arreglarlos y en la funcionalidad nueva lo intentamos con TDD.

daily9Yo trabajo practicamente todo el tiempo haciendo pair programming con los compañeros, de manera rotatoria. Suelo trabajar con dos personas cada día. Es la mejor manera de que mi conocimiento vaya calando en el equipo. He descubierto que con un buen ancho de banda (800kbits de subida y 10mbits de bajada, desde mi lado y muuucho más desde la oficina), la programación en pareja en remoto es igual de buena que en persona. Usamos skype para ir hablando y teamviewer para compartir escritorio.

Quitamos TFS porque nadie se apañaba demasiado bien con él y usamos Mercurial como control de versiones. Hacemos commit cada pocas líneas de manera que podemos seguir el código de los demás. A mí me va permitiendo corregir malas prácticas y sentir que el código va teniendo propiedad colectiva.

Mi objetivo es llevar al equipo al siguiente nivel, donde ya no haga falta un lead developer y exista esa paz sostenible que se produce en los equipos que han interiorizado eXtreme Programming.

daily81

Estamos volcados con la calidad del producto porque sabemos que repercute en el cliente hoy pero en nosotros mañana. Estoy contento de iniciar este proyecto porque la empresa se ha dado cuenta que sólo con el salto de calidad podía llegar a donde se han propuesto. Lo han intentado todo y ya saben por experiencia que el software hay que hacerlo bien, con las mejores técnicas disponibles para ello.

Si nos sale todo bien, en 2012 el producto se habrá expandido a todo Brasil y a otros paises de Sudamérica y habremos crecido también en número de desarrolladores.
Pronto organizaremos algún coding dojo en abierto para que quien quiera se acerque a programar con nosotros y conozca la oficina.

Estoy cumpliendo mes y medio en el equipo y Oscar se acaba de incorporar hoy, 18 de octubre de 2011, fecha en que hemos tomado la foto de equipo de arriba.

Seguiremos informando :-)

Existe la creencia de que si una herramienta creada y vendida por una compañía de renombre, permite realizar determinadas prácticas, estas son buenas. Error.

Las compañías que hacen negocio vendiendo herramientas para desarrolladores saben perfectamente que la mayoría de sus clientes se dedica a hacer ñapas y se lo pone fácil para que siga con ellas. Simplemente le dan a sus clientes lo que les piden, guantes ignifugos para seguir metidos en el fuego y gasolina para que no pare de arder.

Una de las empresas que mejor marketing hace de estas herramientas es Microsoft. Lo pone todo "a guevo" para que los desarrolladores de su plataforma hagan la chapuza más y más gordas. Pero esto no significa que Microsoft no haga buen software ni tenga gente muy buena trabajando. Significa que sabe hacer dinero muy bien. Y no significa que el uso de esas herramientas sea correcto. Lo digo porque se ve amenudo a la gente haciendo las cosas mal, animados por la herramienta.

Algunos ejemplos:
- El debugger: Poder depurar las webs como hace Visual Studio es una maravilla, no he visto debugger mejor en mi vida. Pero un buen artesano no necesita el debugger en el 97% de las veces. Y cuando lo necesita le vale con un "print".  Usa el debugger habitualmente significa que tu proceso de desarrollo es ineficiente y tu código malo.
- El poder colapsar bloques de codigo (regions): El código de un método debe caber en una pantalla y el de una clase no debería tener mas de 3 pantallas. El hecho de que puedas anotar bloques con "#region" y meter toneladas de código, no significa que sea una buena práctica. No puedes conformarte con meter regions en tus miles de líneas de código.
- Autogeneración de tests automáticos: Pex explora el código y genera tests que recorren todos sus caminos de ejecución posibles. ¿Y luego quién entiende y mantiene esos tests? No queremos 100% de cobertura sin más, queremos saber por qué fallan los tests y cómo arreglarlo!
- DataTables: .Net trae de serie clases que permiten manejar estructuras de tabla para transformar una tabla SQL en una Tabla C#.  El sueño de todo chapucero que quiere limitarse a conectar tablas SQL con una UI. ¡Los DataTables deberían estar terminantemente prohibidos!, porque rompen la posibilidad de orientar a objetos.

No cargues la responsabilidad de tu poco cuidado en la herramienta.

He puesto ejemplos de código .Net porque lo estoy trabajando recientemente pero esto pasa con Java y con todo. Lo único que cuando la herramienta la saca una empresa como Jetbrains, Microsoft, Attlassian, etc, la gente no se cuestiona su uso. Ahora me vienen pocos ejemplos a la mente pero hay muuuuchos más. ¿Te animas a ponerlos en los comentarios?

El los últimos dos años he pasado por muchas empresas para formar a los
equipos y tambien para hacer coaching. La experiencia es totalmente recomendable porque se aprende muchísimo. Ahora con el paso del tiempo
he tenido la ocasión de revisitar alguna empresa por la que pasé y tambien de recibir feedback por email de otros grupos donde estuve. Voy pudiendo hacer
balance de resultados y quería compartirlos con todas las personas que he
visitado. Este post está inspirado en el ultimo de JM Beas, donde cuenta su visita a una empresa. Me recuerda mucho a mis experiencias y me anima a compartir mi punto de vista ahora con el paso del tiempo.

En general, en una semana de visita a una empresa para formación y/o coaching, me ha dado tiempo de:
- Diagnosticar su problemática a nivel técnico
- Diagnosticar su problemática a nivel de cultura de equipo y empresa
- Hacerles ver los problemas entre personas y proponerles soluciones
- Animarles a encontrar sus propias soluciones
- Trazar una hoja de ruta hacia el cambio

Ha habido tambien todo tipo de anécdotas. En una de las empresas que me había solicitado por 4 dias, me pidieron que me marchara a casa despues de 2 dias de formación. Dijeron que estaban en un momento de prisas y que no podian dedicarme el tiempo. Esto sólo me pasó una vez afortunadamente.

En el resto de casos, la experiencia a nivel personal fue absolutamente gratificante y se que tanto de mi lado como del lado del equipo, hubo una sensación de estar trabajando en la dirección correcta. Se respiraba optimismo y ganas de mejorar cuando la semana estaba concluyendo.
Mi pensamiento era que estaban iniciando el proceso de cambio hacia el desarrollo sostenible, hacia la agilidad.

Con el paso del tiempo sin embargo, la mayoría de los grupos por donde pasé, volvieron a compartarse exactamente igual que si yo nunca hubiera estado allí. Bastaron unas semanas para que todo quedase en un sueño. Los sitios donde quedó más espíritu de cambio fueron aquellos donde ya habia una cierta disciplina y experiencia con las práctica ágiles, ya que mi visita fue mas un refuerzo que un comienzo.

En la empresa donde actualmente soy mentor y lead developer, SaludOnNet,
ocurrió esto. En Enero estuve allí y quedé encantado con los chicos, con
la gerencia, con las ganas que había. Me gustó tanto la experiencia que cuando han decidido contratarme para largo tiempo, accedí encantado. Y entonces he visto que justo despues de que yo había estado allí, algunos métodos "static" habian cambiado por métodos de instancia y que había un wiki con buenas prácticas pero que ya nadie leía. Había sido como una pequeña ola que termina en la orilla sin hacer mucho ruido.
Ahora llevando ya un mes con el grupo, veo clarísimamente que en menos de 6 meses no conseguiremos asumir un cambio realmente tangible y sin vuelta atrás. Esto ya me lo había dicho Juan Gutiérrez cuando estuve trabajando con ellos en Burdeos una semana (por cierto, estupenda experiencia). En empresas como Nokia o F-Secure lo tienen muy claro y traen a coaches por meses.

El tono de este post no es negativo, no le estoy diciendo a las empresas que no contraten a externos por una semana. De hecho yo todavia tengo que ir a Donewtech y a Aventia antes que acabe el año. Lo que quiero hacer es bajar la expectativa de aquellas empresas que piensan que con una semana todos sus males se evaporarán. Resulta que los malos hábitos solo se marchan cuando son reemplazados por hábitos buenos, y los hábitos se hacen en el día a día.
Por este sencillo razonamiento la expectativa de la empresa que contrata al externo por una semana, debe ser la de recibir a alguien que les dará un gran punto de vista de la situación en la que están. Les ayudará a entender su problemática, a saber por dónde empezar a cambiar. Y habrá un conocimiento mutuo como para que ambas partes sepan si quieren seguir trabajando juntas en el futuro. Pero el cambio no se producirá con esa semana.
El impacto de una visita corta será mayor cuando el equipo ya se encuentre inmerso en el cambio, contando con personas dentro del equipo que ya practiquen la agilidad y le pongan ganas de mejorar.
Muchos equipos no sólo necesitan un coach sino un lead developer que sepa ir reduciendo la deuda técnica y que sea buen mentor para que el resto aprenda buenas practicas cuando se programa en pareja. En la mayoría de los sitios donde usan Java, me encuentro que la gente programa estilo Jabol, como dice Enrique Amodeo :-)

Gracias a Xavier Quesada, tambien estuve una semana en Bruselas con un estupendo equipo y puedo confirmar que allí ocurre lo mismo. En su caso, ya cuentan con Xavi como coach con lo cual van con buen rumbo y el cambio no deja de avanzar. Sin embargo necesitan un lead developer para ayudarles a entender cómo mejorar técnicamente. En este caso concreto la formación ayuda muchísimo asi que es probable que volvamos a colaborar en el futuro próximo.

Solo me queda decirles a las personas con quienes he trabajado en una visita corta, que ha sido estupendo y que siguen contando con los profesionales que hay en iExpertos.com para ayudarles a continuar su proceso de mejora continua. Todo pasa por sentirse responsables del cambio, sin esperar que sea el que viene de fuera el que resuelva la papeleta. Nadie mejor que uno mismo para cuidarse. El de fuera echa una mano, peso quien tiene que dar el paso es quien ya está dentro.

Profesionalmente visitar todas estas empresas me ha enriquecido más de lo que puedo medir y me ha permitido encontrar trabajos como el que tengo ahora, donde trato de ser el motor del cambio desde dentro.
Las empresas que decidieron contratarme y que han visto cómo el arranque se quedó en nada, siguen teniendo la oportunidad de retomar el trabajo porque hay profesionales como JM Beas o Enrique Amodeo que han tendido su mano para ayudar. No penseis que porque en una semana no llegó la solución, es imposible alcanzarla.
Tambien podeis volver a contar conmigo, aunque tendrá que ser ya hacia la mitad del año que viene.

Animo y a seguir mejorando :-)

Hasta hace poco iExpertos era nuestra pequeña gran empresa de desarrollo de software y formación pero tal como anuncié en la #XPWeek, desde ahora pasa a ser un grupo de profesionales independientes. Ya no es una empresa como tal. Ahora es una marca y una alianza de profesionales con ideas comunes. No llega a ser comunidad porque somos pocos y no es previsible que seamos numerosos.

Las puertas están abiertas para aceptar a nuevos artesanos del software. El requisito es venir avalado por un miembro del grupo, el cual necesitará haber trabajado directamente con el candidato para poder confirmar de primera mano que su trabajo es excelente y su compromiso con el cliente es máximo.

La otra gran noticia es que Enrique Amodeo se une a iExpertos y vamos a ampliar nuestro catálogo de formación para que desde ya, recorra el país llevando su conocimiento a las empresas. Mis clientes irán siendo también clientes de Enrique si así lo desea.

En esta nueva etapa de iExpertos, yo viajaré menos y estaré más centrado en el proyecto en que me encuentro actualmente,  SaludOnNet, haciendo de "agile" mentor y lead developer, hasta que el equipo no necesite ningun mentor ni lead developer. Proximamente hablaré de esta nueva etapa :-)
Este año me pierdo la CAS2011 por motivos de trabajo pero con el reto de ir a la CAS2012 hablando de cómo nuestro proyecto en SaludOnNet pasó de cero a ágil en un año.

En breve espero anunciar más incorporaciones al grupo.

La web de iExpertos está pendiente de un cambio de look, ya que como bien se comenta, tiene un aspecto muy anticuado.