Folklore in Software Engineering: A Definition and Conceptual Foundations
Este artículo define y caracteriza el folclore de la ingeniería de software mediante la síntesis de una revisión de la literatura con entrevistas a 12 profesionales suecos para establecer un marco conceptual que permita comprender cómo las narrativas informales, los mitos y las heurísticas moldean la identidad profesional, los valores y el conocimiento colectivo dentro de las comunidades de desarrollo.
Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo
Imagina a un equipo de desarrollo de software no solo como un grupo de personas escribiendo código, sino como una tribu moderna viviendo en una aldea digital. Así como las tribus antiguas tenían historias sobre por qué ocurre el trueno, rituales para asegurar una buena cosecha y bromas que solo los ancianos entienden, los ingenieros de software tienen su propia versión de estos artefactos culturales.
Este artículo, titulado "Folklore en la Ingeniería de Software", sostiene que los equipos de software están llenos de folklore: historias, mitos, bromas internas y reglas no escritas que se transmiten de persona a persona, no a través de manuales oficiales, sino mediante charlas de pasillo, pausas para el café y sesiones de incorporación.
Aquí hay un desglose de lo que los autores encontraron, utilizando analogías simples:
1. ¿Qué es el "Folklore del Software"?
Piensa en el folklore como el "libro de reglas no escrito" de un equipo.
- Los Manuales Oficiales son como las leyes del gobierno: claras, escritas y que se supone deben seguirse exactamente.
- El Folklore es como los "chismes del pueblo" o las "leyendas familiares". Es aquello que la gente realmente cree y hace, incluso si contradice las reglas oficiales.
Los autores lo definen como historias y atajos (heurísticos) transmitidos informalmente que moldean cómo los desarrolladores se ven a sí mismos, qué valoran y cómo trabajan juntos. Es el "lore" de la ocupación.
2. Los Tres Ingredientes Principales del Folklore del Software
Los investigadores dividieron este folklore en tres categorías principales, utilizando ejemplos de su estudio con 12 experimentados profesionales suecos de software:
A. Mitos y Leyendas (Los "Relatos Exagerados")
Estas son historias que todos creen que son ciertas, aunque no estén respaldadas por datos duros.
- La Leyenda del "Desarrollador 10x": Existe la creencia persistente de que un programador supergenio vale por diez programadores promedio. El artículo señala que esto es a menudo un mito utilizado para explicar por qué algunos proyectos tienen éxito o fracasan, pero rara vez se demuestra.
- La Promesa de "Libre de Errores": Una creencia común es que, si sigues un proceso específico a la perfección (como una lista de verificación), el software mágicamente no tendrá errores. En realidad, los errores siguen ocurriendo, pero la historia persiste para dar a los gerentes una sensación de control.
- El Hype de "Lo Nuevo es Mejor": La idea de que la tecnología o el framework más reciente es automáticamente superior, simplemente por ser nuevo, independientemente de si se ajusta al problema específico.
B. Rituales y Práctras (Las "Ceremonias")
Estas son acciones repetidas que tienen un significado más profundo que solo "hacer el trabajo".
- La Reunión Diaria (Daily Stand-up): Oficialmente, esta es una reunión de 15 minutos para sincronizarse. Desde la perspectiva del folklore, puede convertirse en un ritual donde las personas "actúan que están trabajando" para el jefe, o un pegamento social que une al equipo.
- El "Tollgate" (Punto de Control): Una reunión donde se revisa un proyecto antes de pasar a la siguiente fase. Algunos equipos tratan esto como una ceremonia mágica donde "las cosas encajan" y el software de repente funciona, incluso si el trabajo fue desordenado anteriormente.
- Nombrar los Sprints con Postres: Algunos equipos nombran sus ciclos de trabajo con nombres de galletas o pasteles. Si alcanzan sus metas, reciben un premio. Esto convierte un plazo estresante en un juego compartido.
C. Artefactos y Humor (Los "Chistes Internos")
Esto incluye memes, bromas y objetos físicos que portan un significado cultural.
- Memes: El artículo menciona memes como "This is Fine" (un perro sentado en una habitación en llamas), que los desarrolladores usan para expresar que están viviendo en el caos pero fingiendo que todo está bien.
- El "Escritorio Desordenado": Existe la creencia de que un escritorio desordenado es una insignia de honor, que muestra que un desarrollador está sumergido en sus pensamientos.
- Las Pruebas como una Carga: Un chiste común es que las pruebas son una tarea aburrida y tediosa en comparación con el trabajo "emocionante" de programar. Este chiste refuerza la idea de que los testers son menos importantes que los desarrolladores.
3. ¿Cómo se propaga este Folklore?
El artículo explica que este conocimiento no viaja a través de libros de texto. Se propaga como un virus o una historia de fogata:
- Incorporación (Onboarding): Cuando una persona nueva se une, no solo lee un manual; escucha las "historias de guerra" de los veteranos.
- El Agua de la Fuente (Water Cooler): Las historias se intercambian en las salas de café, los almuerzos y los canales de chat.
- Mentoría: Los desarrolladores senior enseñan a los juniors no solo respondiendo preguntas, sino diciéndoles: "Intentamos eso hace 20 años y falló", sin explicar exactamente por qué.
4. ¿Por qué es esto importante?
Los autores argumentan que debemos dejar de ignorar este folklore y empezar a estudiarlo.
- Lo Bueno: El folklore puede ser un atajo útil. Ayuda a las personas nuevas a aprender la "forma real" en que funcionan las cosas en una empresa específica más rápido que leyendo un manual. Construye identidad de equipo y ayuda a las personas a lidiar con el estrés mediante el humor.
- Lo Malo: El folklore también puede ser peligroso. Si todos creen en un mito (como "las pruebas son una pérdida de tiempo"), podrían tomar malas decisiones que perjudiquen al producto. También puede evitar que los equipos prueben métodos nuevos y mejores porque "intentamos eso una vez y no funcionó" (aunque las circunstancias fueran diferentes).
La Conclusión Final
El artículo concluye que el Folklore de la Ingeniería de Software es la colección de historias, creencias y rituales compartidos informalmente que definen cómo operan los equipos de software.
Al igual que un historiador estudia los mitos para entender una cultura, los investigadores y gerentes de software deberían estudiar estos "mitos de software" para entender por qué los equipos toman las decisiones que toman. Al hacer visibles estas historias invisibles, los equipos pueden mantener las tradiciones útiles (como los buenos chistes internos que elevan la moral) mientras desafían los mitos dañinos (como la idea de que algunas personas son simplemente 10 veces mejores por naturaleza).
En resumen: El software no se trata solo de lógica y código; también se trata de las historias que nos contamos a nosotros mismos sobre el código.
¿Ahogado en artículos de tu campo?
Recibe resúmenes diarios de los artículos más novedosos que coincidan con tus palabras clave de investigación — con resúmenes técnicos, en tu idioma.