¿No han tenido tecnologia en sus manos, que es simple, eficaz, y resuelve un problema?
Y luego, entran en una empresa, y esa misma tecnologia, ahora es simplemente odiosa, una pesadilla, compleja, e inutil
Yo vivo esa sensacion demasiado, no solo me pasa con la estadistica, (tranquilo lector fantasma, no voy a referir a mi articulo de metricas) me pasa tambien con la tecnologia.
Creo que el ejemplo que mayor gastritis me causa es Git. Honestamente Git es increible, es todo lo que escribi al inicio del artículo. Git es un gestor de contenido, literalmente ‘Initial revision of “git”, the information manager from hell’ una herramienta hecha exclusivamente para el proyecto de linux.
Que de hecho, resuelve muchos problemas de los gestores de contenido. Y que agarro fuerza y popularidad, debido a la vida. Debido a la simplicidad, aunque de eso escribire otro día.
Git permite, tomar contenido en texto, y versionarlo a traves del tiempo, permite compartirlo sin credenciales, y permite traer modificaciones de forma remota.
Ya nadie sabe de esto, esta en un lugar muy elitista del internet, debido a Github, y eso esta bien, es mucho mas facil, trabajar desde Github que desde dispositivos remotos por SSH.
Pero me desvie, ¿como llegamos al punto de ‘el problema son las personas?. Pues GitOps, de hecho, otro dia explotare con Gitops. No, no. Hoy vamos a algo mas simple.
El problema son las personas, porque tratan de crear procesos, sin organizacionales, sobre una herramienta que esta tan util y estable que soporta la estupides.
En git existen los conceptos bien sencillos de Commits (un estado en el tiempo), Branch grupos de confirmaciones con un identificador, Remotos diferentes grupos de ramas en otra ubicacion, Pull traer los datos de un remoto, Push enviar los datos a un remoto.
Y una funcionalidad enviar un correo para que alguien haga Pull de tus commits. ‘Request a Pull’. Nadie usa esto ahora todo son ‘Pull Request’ o ‘Merge Requests’ introducidos por las UI de Github y Gitlab respectivamente.
Un flujo de trabajo que hace sentido, es tener un repositorio central, crear una rama, confirmar cambios, y solicitar un Pull al dueño de la rama principal de tu rama.
Ahora bien, el problema son las personas porque
- ¿No seria bueno tener multiples niveles de aprobacion por cada Pull Request?
- ¿No seria bueno que cada pull request tenga validaciones automatizadas?
- ¿No seria bueno que cada pull request se evalue en diferentes ambentes y builds?
- ¿No seria bueno, que estos pull request muy complejos los evalue una Gen AI?
- ¿No seria bueno utilizar documentos de Microsoft Word para la documentacion?
- ¿No seria bueno guardar en Microsoft Excel, los resultados de las pruebas dentro del mismo pull request?
- ¿No seria bueno, que cada pull request, tenga un documento llamado version_pull_request_id.txt que tenga un identificador unico?
- ¿No seria bueno que siempre se parta del commit 1?
- ¿No seria bueno que todas las ramas vengan de feature/mejora, a develop/mejora. Y luego en la integracion se vaya a master/mejora?
- ¿No seria bueno, hacer Merge Pulls?
Podria seguir toda la noche.
NO, no seria bueno nada de eso. Para una solucion, se define un flujo de trabajo. Que haga sentido para esa solucion, para esas personas.
Por favor organizaciones, con metricas idiotas, dejen de medir la productvidad por cantidad de commits, dejen de estandarizar el nombre de los commits porque que a nadie le importan y nunca van a volver atras.
Por eso Linux funciona, solo un grupo definido de personas es capaz de integrar, y el resto es solo burocracia y bloqueos de esas personas que cuidan el trabajo.
Y si no te gusta, solo crea tu propia version. Supongo que debo pensar lo mismo sobre mi propia organizacion, pero me falta capital.