Programa

En Mercadona Tech vivimos entre dos mundos, uno de productos 100% digitales como es nuestro e-commerce y otro de productos con una carga muy grande de operativa física como son todas las herramientas que construimos de apoyo a nuestra cadena logística. Quería compartir todos los aprendizajes de cómo un equipo aplicando los mismos principios, valores y prácticas de una metodología como XP se encuentra con problemas y soluciones muy diferentes para estos dos mundos.

Para algunos de nosotros, programar no es sólo nuestra profesión, sino también un hobby. Algunas personas aplican este hobby a cosas objetivamente útiles como side projects o contribuir a opensource, mientras que otras personas, entre las que me incluyo, lo aplican a retos absurdos y bastante inútiles pero súper divertidos. En esta charla os contaré la historia de uno de estos retos, cómo llegué a él a través de concursos de programación, y cómo algunas de estas cosas que parecen bastante inútiles en la superficie puede que no lo sean tanto.

¡Por fin! Dos años después, por fin vamos a hablar de arquitectura en el front en la SCPNA… aunque la charla no va a ser solamente sobre arquitectura, ni solamente sobre el front end. Voy a compartir lo aprendido intentando crear aplicaciones web durables y mantenibles en el tiempo. ¿Planazo, no?

Hace unos años escribí este post medio de broma titulado "El Método Konmari aplicado al desarrollo software", y de hecho tenía planeado dar una charla al respecto. Ahora me gustaría cambiar un poco el contenido de esta charla y aplicarlo también a lo que he aprendido en los últimos años y la relación entre el Método Konmari, el desarrollo software y la ingeniería de datos. Es una charla que sirve mucho para relacionar aspectos comunes entre el desarrollo software y la ingeniería de datos desde un punto de vista práctico pero también muy metafórico

Se basa en la importancia y el valor de escribir código de calidad para tener proyectos fáciles de mantener y con los que se puede trabajar con comodidad en el día a día.

Lo único que diferencia un proyecto greenfield de uno legacy son pequeños que todos introducimos de forma involuntaria que degradan nuestro código poco a poco con el paso del tiempo, lo cual resulta insostenible en el largo plazo. Sin embargo, hay formas de evitarlo y reducir su impacto.

¿Cuántas veces habremos escuchado que TDD es lo mejor y que screenshot testing es tan caro que casi no debería ni utilizarse? ¿Y que todo el mundo debería ser full-stack y separar entre front y back es el demonio? Y que los equipos de desarrollo deben desplegar sus propios productos es algo que tenemos claro, ¿no? Con frecuencia sentamos cátedra sobre este tipo de prácticas rozando a veces el fanatismo. En esta charla veremos cómo el mismo tipo de práctica puede ser a la vez la ideal para aplicar en un tipo de proyecto y la peor idea para aplicar a otros. Porque el desarrollo de software depende tanto del contexto, que lo más importante es abandonar los dogmas. Revisitaremos los pilares del desarrollo e intentaremos extraer los matices que hacen las técnicas importantes.

Aprender es cosa de cada una/o, pero ¿podemos ayudar en algo? Es más, ¿deberíamos hacerlo? Y si vamos a hacerlo, ¿cómo se puede hacer bien?, ¿en qué pilares podemos basarnos? Y eso, ¿a qué consecuencias prácticas lleva?

Os contaremos nuestro camino de los 2 últimos años, nuestro aprendizaje y cómo detrás de todas estas decisiones está una reflexión acerca de nuestra profesión. Porque, ¿lo nuestro es realmente una profesión?

Vivimos en la Edad de Oro de la profesión del desarrollo de software. Nunca antes tuvimos tan buena posición, nunca tanta influencia. Realmente hemos llegado a donde queríamos estar... así que no queda mucho por discutir. Nada que ver aquí, circulen...