Eat Your Own Food: cuando el que hace el software también lo tiene que usar

Imaginá que entrás a un restaurante, el chef te recomienda el plato estrella y, cuando le preguntás si lo come, responde: «No, yo pido delivery del local de enfrente».

Con el software pasa algo parecido. Una empresa puede mostrar una demo impecable, prometer que su sistema ahorra tiempo y tener una presentación llena de flechas. Pero hay una pregunta mucho más reveladora: ¿lo usa para hacer su propio trabajo?

Esa es la idea detrás de Eat Your Own Food, una forma amable de referirse al concepto conocido en tecnología como eating your own dog food o dogfooding: usar el producto que uno mismo desarrolla, en situaciones reales, para descubrir sus problemas y mejorarlo. La traducción literal, «comer tu propia comida para perros», tiene menos glamour que una presentación comercial. Y una historia bastante más entretenida.

Primero hubo perros. Después llegaron los servidores

Una de las historias más repetidas vincula la expresión con los avisos de ALPO protagonizados por Lorne Greene en los años setenta. El actor recomendaba el alimento y mostraba que también se lo daba a sus propios perros. El mensaje publicitario era fácil de entender: confío en lo que vendo lo suficiente como para usarlo en casa.

Acá podés ver una copia de archivo de uno de esos anuncios, publicada en YouTube por Bionic Disco y atribuida a 1976:

Un anuncio de ALPO con Lorne Greene, atribuido a 1976. Esta campaña suele citarse como antecedente de la expresión. Ver el video en YouTube.

Hay un detalle importante: no está demostrado que ese anuncio haya dado origen al término en Microsoft. Tampoco hace falta imaginar a Greene comiendo alimento para perros: la idea era que lo elegía para los suyos. La reconstrucción de GeekWire distingue esa asociación popular de la historia que cuenta uno de sus protagonistas.

Microsoft convirtió la frase en una forma de trabajar

El salto al software suele situarse en Microsoft, en 1988. Paul Maritz, entonces directivo de la compañía, contó años después que había escuchado la expresión de Jim Harris, uno de los fundadores de Compaq.

Según su relato, Maritz envió un correo al equipo de LAN Manager para pedirles que usaran el software que estaban desarrollando. Brian Valentine respondió organizando un servidor llamado dogfood. El producto dejó de ser algo que se construía para otros: pasó a sostener el trabajo cotidiano de sus propios creadores.

Maritz lo cuenta en primera persona en el podcast de TiE Seattle, aproximadamente desde el minuto 11:32. Es un testimonio retrospectivo, no el correo original conservado en pantalla, pero explica muy bien por qué la expresión prendió: cuando tu jornada depende del producto, los problemas dejan de ser abstractos.

El bug cambia de prioridad cuando te arruina la mañana

Supongamos que desarrollás un sistema de tareas. En la demo, creás una tarea, la asignás y la marcás como terminada. Todo perfecto. Aplausos.

Ahora usalo durante dos semanas para coordinar un proyecto de verdad. Aparecen otras preguntas: ¿cómo encontrás lo que quedó pendiente? ¿Por qué llegan cinco avisos del mismo cambio? ¿Qué pasa si una persona se va de vacaciones? ¿Cómo recuperás una tarea que cerraste por error?

El dogfooding pone al equipo frente a esas fricciones. Un paso innecesario que parecía menor en una reunión se vuelve bastante menos simpático cuando hay que repetirlo veinte veces por día.

Para la industria del software, esto aporta varias cosas:

• Problemas que aparecen antes. El uso sostenido puede revelar errores, lentitud y casos que una prueba aislada no había contemplado.
• Prioridades más cercanas al trabajo real. Se entiende mejor qué impide terminar una tarea y qué es apenas una preferencia estética.
• Mejor comunicación entre equipos. Desarrollo, producto y soporte pueden hablar de experiencias concretas, no solo de tickets o supuestos.
• Responsabilidad por la experiencia completa. Importan también el alta de una cuenta, los permisos, los mensajes de error, la documentación y la recuperación cuando algo falla.

Google y GitLab también se sentaron a la mesa

En diciembre de 2009, Google publicó An Android dogfood diet for the holidays. Contó que sus empleados estaban probando un dispositivo móvil con Android para experimentar con nuevas capacidades y aportar comentarios. El producto salía del laboratorio y entraba en los bolsillos de personas que podían encontrarse con problemas durante el día.

GitLab, por su parte, documenta el dogfooding como parte de su trabajo de producto e ingeniería. Usar su propia plataforma para desarrollar software les permite convertir necesidades internas en observaciones sobre el producto.

Los ejemplos muestran algo útil: el valor aparece cuando la experiencia se registra, se discute y se transforma en mejoras. Instalar la aplicación y olvidarse de ella no cuenta como un gran experimento.

La trampa: el chef ya sabe dónde está todo

Quien creó un sistema conoce sus atajos, entiende su vocabulario y sabe qué botón conviene no tocar todavía. Un cliente nuevo no tiene esas ventajas.

Además, el equipo interno puede trabajar con pocos usuarios, computadoras rápidas y una conexión excelente. Sus clientes pueden tener otras necesidades, distintos niveles de experiencia, requisitos de accesibilidad y volúmenes de datos mucho mayores.

Por eso, usar el producto propio complementa las pruebas y la investigación con usuarios reales. Siguen haciendo falta controles de seguridad, pruebas automatizadas, evaluaciones de rendimiento y conversaciones con las personas a las que el producto pretende servir. Que algo le resulte cómodo al equipo no demuestra que sea útil para todo el mercado.

Cómo aplicarlo sin poner la operación en riesgo

No necesitás ser Microsoft ni fabricar teléfonos. Podés empezar por un proceso acotado:

1. Elegí una tarea que importe. Gestionar solicitudes, preparar reportes o seguir oportunidades comerciales. Tiene que haber trabajo real detrás.
2. Usá el recorrido normal. Probá con los permisos de un usuario común y sin resolver cada problema directamente en la base de datos.
3. Definí límites y una salida. Elegí datos adecuados, protegé la información y mantené una alternativa si el sistema falla. Los procesos críticos requieren más controles.
4. Anotá lo que molesta. Pasos confusos, tareas que tardan demasiado, errores y soluciones improvisadas. Medí cuánto lleva completar el trabajo.
5. Corregí y volvé a probar. Contrastá lo aprendido con usuarios externos antes de convertir cada necesidad interna en una nueva funcionalidad.

En un desarrollo a medida, también puede aplicarse a los componentes y procesos que el proveedor comparte con sus clientes. Cuando el dominio es muy específico, como una operación médica o industrial, hace falta sumar a quienes realmente conocen esa actividad. El equipo técnico no puede reemplazar esa experiencia.

Antes de servirlo, probalo

El dogfooding propone una prueba de coherencia: si creés que tu software mejora el trabajo de alguien, buscá una oportunidad real y segura para experimentar esa mejora vos también.

Y si usarlo te da ganas de volver a la planilla anterior, mejor enterarte antes de que le pase al cliente.

La próxima vez que evalúes una herramienta, además de pedir una demo, preguntá: «¿Qué parte de su propio trabajo hacen con este producto y qué cambiaron después de usarlo?». La respuesta puede enseñarte más que varias diapositivas. El chef puede explicar la receta. Lo interesante es saber qué pasó cuando se sentó a comer.