Dogfooding en deMartina

Dogfooding: término coloquial para definir el escenario en el que un equipo de desarrollo utiliza su propio producto para demostrar la calidad y las capacidades de este.

Pocas pymes de comercio electrónico de España pueden presumir de contar con un departamento de desarrollo propio (algo que recomiendo encarecidamente si se va en serio sobre vender en Internet). Por eso mismo, para aumentar la calidad del software desarrollado la mejor manera es hacer que sean los mismos desarrolladores los que utilicen el software en un contexto real. ¿Cuántas veces nos hemos sentido desorientados en medio de un proyecto software porque somos incapaces de comprender las necesidades de los usuarios? Involucrarse directamente en la utilización y función del producto aporta una perspectiva excelente para definir las tareas, adquirir el vocabulario interno y priorizar los objetivos a medio plazo.

Image0369Image0370

En deMartina, todos los empleados somos instruidos para trabajar en el almacén independientemente de nuestra posición. Evidentemente nunca lo haremos tan bien como los chicos del almacén, pero resulta conveniente conocer cómo funciona el negocio (cómo se confirma, prepara, comprueba, re-comprueba, evalúa y coloca a la espera de la empresa de logística). A los desarrolladores, esto nos viene genial para huir de la oficinas y degustar las delicatessen con las que se nutren los chicos del almacén…

Image0368

… pero el objetivo principal de nuestras escapadas es recibir feedback de primera mano. Resulta crucial y vale más que 1000 documentos de especificación. Ningún "user story" puede superar a la propia experiencia. En otros proyectos en los que participé, la causa número uno de problemas era desconocimiento del dominio del problema. ¿Se familiarizan tus analistas y programadores de primera mano con el contexto específico del problema? Solo involucrando a todas las partes se consigue montar una plataforma tecnológica con éxito. Nosotros estamos muy orgullosos de nuestra comida de perro, ¿y tú?

Anuncios
Dogfooding en deMartina

¡Es navidad (en la CPU)!

Durante los últimos días se han producido un par de cambios críticos en deMartina de los cuales soy responsable. A saber:

  • Sistema embellecedor de URLs a medida con distribución de carga inteligente a nuestros CDN, theming para los widgets de página, caché por página, etc.
  • Sistema de creación, nombramiento, thumbnailing y distribución de imágenes de producto.

Se trata de un sistemas muy complejos. En principio funcionaban bien. Sin embargo, tras un refactoring sin una batería de tests en la que apoyarse, introduje un bug que consiguió poner a prueba la capacidad de nuestro servidor.

¿Navidades en Junio?

Dado que somos una tienda de juguetes, nuestra máxima actividad en la CPU del servidor se encuentra entre los meses de noviembre y diciembre. Sin embargo, durante la semana pasada fue superada con creces.

Una función encargada de generar identificadores únicos de página para la caché estaba funcionando incorrectamente y siempre devolvía el mismo identificador.

/**
 * Devuelve la firma de una página, con una URL semicanonicalizada. 
 * Si se llama sin parámetros, se utiliza el contexto actual.
 */
 public static function getPageDigest($page = '', $parameters = '', $b_use_prefix = true) 
 {
  // Calcular prefix
  $s_prefix = $b_use_prefix?self::getCurrentPoorsManPseudoCanonicalRelativeUrl():'';
  // Cuidado al modificar esta funcion...
  $s_url = self::getPoorsManPseudoCanonicalRelativeUrl($page, $parameters);
  return sha1("$s_prefix@$s_url");
 }

Pues en la variable $b_use_prefix = true, introducida durante la refactorización, se puso a false. Por lo tanto siempre se estaba devolviendo el mismo identificador de página y cada vez que una página accedía a consultar la caché de urls, se traía unos 400.000 registros, sobrecargando al servidor innecesariamente con cada petición a la página. Me queda así claro que los parámetros por defecto son peligrosos…

tl;dr Nunca introduzcáis parámetros por defecto cuando refactoriceis si no tenéis una batería de tests lo suficientemente extensa.

¡Es navidad (en la CPU)!

La silla rosa

La silla rosaTodas las sillas de reunión de deMartina son azules, blancas o rojas (colores corporativos) excepto la silla rosa. Dadas las anécdotas a su alrededor, decidí hacer un experimento para comprobar los prejuicios “infantiles” de nuestros candidatos para cubrir un puesto de desarrollador.

La historia

Por algún motivo que desconozco, tenemos una silla rosa que rompe la armonía cromática de nuestro mobiliario. Desde que la silla rosa llegó a las oficinas de deMartina se han producido numerosas anécdotas a su alrededor. Una de ellas que se ha convertido en una historia grabada en la mente colectiva de la empresa es la “fobia” que le producía a uno de nuestros programadores, Carlos (que espero que no se enfade por comentar esto). Una vez, en una reunión del equipo al completo, sólo quedaba esa silla vacía y se negó a sentarse. ¿Qué podíamos hacer para continuar? Le cedí mi asiento sin más.

Desde entonces, la silla rosa se ha convertido en un icono, un referente para nuestras bromas sobre “lo macho” de los programadores. Entre ellas, decorar la mesa de un programador que se ausentó de rosa por completo (lapicero, bolígrafo con pompón, pegatinas y la silla, por supuesto). Mobbing sano ;)

El experimento

Los desarrolladores que pasaron nuestro proceso de preselección fueron invitados a realizar una entrevista a las oficinas de deMartina. Les hacíamos pasar a una sala y tomar asiento. Algunos de ellos se bloqueaban a la hora de decidir y preguntaban donde debían sentarse, otros simplemente se sentaban donde creían oportuno.

Disposición de sillas en la mesa de entrevistas

La silla rosa era la más cercana a la puerta, seguida de la azul, después la blanca y finalmente la roja se encontraba más alejada que el resto. La clave de este experimento es ver qué prejuicios de localización y color tenían los candidatos. Asombrosamente ninguno se sentó en la silla rosa. ¿Tiene la mayoría de los desarrolladores un complejo “macho” sin resolver?

La respuesta CORRECTA

No había respuesta correcta en este experimento, pero las mejores opciones eran la silla rosa o azul, en ese orden.

  • La silla rosa habría denotado haber superado algunos de los prejuicios cognitivos de la infancia (signo de madurez) y ser práctico (tomar el camino más corto).
  • La silla azul habría denotado gran interés en la entrevista (alejarse de la puerta) o al menos conocer las convenciones sociales al respecto (el entrevistador es quien siempre está más lejos de la puerta y de frente a ella).
  • La silla blanca habría denotado una personalidad débil e insegura. Miedo a desagradar, a tomar la iniciativa (sin olvidar que estaba de frente a la puerta).
  • La silla roja era la opción más atrevida y extrovertida. Indicaba, por su posición, una falta de visión de equipo.

A los que buscáis trabajo: ¿sabíais que los entrevistadores nos fijamos en detalles como estos? ¿qué otras pruebas extrañas os han hecho (ahora que habéis en la cuenta de este detalle)?

A los que entrevistáis candidatos: ¿qué pruebas poco convencionales (o sutiles) hacéis a la hora de reclutar talento?

La silla rosa