Más allá de hablar de buenas prácticas

Esta semana pasada, Hari Hariri (@hhariri) escribió un interesante post:

Loved the show but I have toget back to the real world now

Hariri comenta sobre su experiencia en dos conferencias, en dos charlas que dio, para desarrolladores. Escribió:

As usual, to set the context, I asked a series of questions regarding unit tests:

“How many of you know what a Unit Test is” – 80% put up their hand.

“How many of you do Unit Testing?” – 10% put up their hand.

“How many of you think Unit Testing is valuable?” – 80% put up their hand

La primera charla fue enfrente de desarrolladores PHP. Pienso que los desarrolladores PHP todavía trabajan un poco diferente de los demás desarrolladores, pero esto en base a mis recuerdos de programación PHP intensiva. Puede ser que hoy tengan más herramientas a su alcance para su trabajo. Pero la segunda chara de Hari fue en frente de 200 personas interesados en arquitectura de software.

Recientemente, en una charla interna en una compañía de software, @MartinSalias hizo preguntas parecidas, y el resultado fue similar al de Hariri. No tomé notas, pero en una de mis charlas los resultados tenían el mismo bias: a una gran mayoría les gusta y algo conocen de mejores prácticas, disciplinas XP, etc… Pero pocos las implementan.

Entonces, ¿dónde está el problema? Hariri escribe:

“A is good. I like A. I should do A. But I won’t do A”.

People identify themselves with the issues we talk about. They see the value writing automated tests and complying with design principles adds. They get excited, yet they don’t do it. Why?

I usually ask this question too, and the typical responses are:

1. Tight Schedules.

2. Decrease in Productivity. Drag and Drop is more productive

3. Customers want deliverables. Tests are not deliverables

and my all time favorite

4. “I’m paid to write code, not tests”.

Bueno, hay muchas razones, cada desarrollador de software y su equipo pueden tener varias razones para no aplicar TDD, pruebas automáticas, revisión de código, programación de a pares, etc…

Tomemos un tópico, para ser más concretos y avanzar en el tema: TDD. ¿Por qué la gente no está usando más TDD en su trabajo diario? Mis razones candidatas:

- Conocen qué es TDD, pero nunca lo practicaron o practicaron poco, y tienen muchas dudas

- Si trabajan en un equipo, no todos los miembros del equipo están al tanto de lo que es TDD, y la persona que conoce algo no tiene la experiencia como para transmitirla a los demás.

(claro, también puede ser por la impresión de que lleva más tiempo (posición discutible) y que el “management” lo ve como un trabajo adicional sin valor)

¿Qué necesitan? Pienso que necesitan estos puntos:

- Conocer el “rationale”, el fundamento que sustenta a TDD (en general, se aprende en charlas, conferencias, libros…)

- Practicar TDD

- Tener un mentor para preguntar dudas, resolver problemas, revisar patrones

Cuando tuve que realmente comenzar a aprehender (más que aprender) TDD, el segundo punto lo resolví aplicándolo en mis proyectos personales. Y el tercer punto, lo encaré preguntando a otros programadores, usando foros web (poco), leyendo ejemplos, más libros, y principalmente, revisando código abierto; todavía sigo trabajando en los tres puntos. Pero veo que no todos los desarrolladores de software tienen el tiempo disponible para mejorar en sus habilidades, más allá del trabajo diario. Yo promuevo el “auto-aprendizaje”, pero la realidad es que no todos los desarrlladores tienen el tiempo (y la voluntad) de tomar ese camino. Y es un camino no exento de riesgos: al auto-aprender, podemos aprender mal algo sin tener una retroalimentación; sin tener un mentor, es dificultoso aprender temas que abarcan tantos puntos y detalles, como TDD.

Estoy trabajando en equipo en el Proyecto Hogwarts para solver esos puntos: darle a la gente el soporte para aprender TDD, IoC, principios SOLID, y más. No sólo con ejemplos, sino también con fundamentos. No sólo teoría, sino también práctica. No solo práctica, sino evaluación, soporte posterior, detección de puntos débiles, acciones correctivas. En el caso de este proyecto, el cliente final ya compró la idea de las mejores práctica: no tenemos que convencer a un “management” escéptico. Estamos todavía en una etapa temprana del proyecto: los primeros entregables estén en beta, distribuidos internamente. Siguiendo lo ágil, producimos algo y lo entregamos, para conseguir revisión, en vez de esperar a tener todo armado. Espero que cuando el proyecto gane más momento, más material y también la experiencia ganada en el proceso, será publicada y compartida con la comunidad.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 11699, 12114, 3463. Bookmark the permalink.

2 Responses to Más allá de hablar de buenas prácticas

  1. yo no lo encuentro sorprendente, este “problema” es nuestra naturaleza humana, saber lo que es bueno para nosotros y simplemente no hacerlo por la razon que sea (hacer ejercicio, no fumar, comer saludable, etc, etc, etc)

    asi de sencillo

    salu2

  2. Maestro, el anglish lo está matando…

    “Estoy trabajando en equipo en el Proyecto Hogwarts para solver esos puntos”

    ¿Se refiere a solubilizarlos? :D

    Me encantó el post. *Ese* es el espíritu de Hogwarts, exactamente.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>