- En una empresa con una gran deuda técnica, surgían ineficiencias por la duplicación de código y el uso de frameworks obsoletos
- Durante el avance del proyecto, la pérdida de confianza de la dirección y la resistencia al cambio dentro de la organización actuaron como obstáculos principales
- La causa raíz de la deuda técnica son factores humanos como requisitos poco claros, plazos irreales, preferencia por tecnologías obsoletas, respuestas cortoplacistas de la gerencia y orgullo personal
- Para que un proyecto tenga éxito, son esenciales no solo los resultados técnicos, sino también la gestión de percepciones y la comunicación
- Además de sus capacidades técnicas, los ingenieros deben contar con habilidades para colaborar dentro de la organización y manejar relaciones humanas
Deuda técnica y el problema del código duplicado
- En una empresa donde trabajé antes, había una deuda técnica grave: millones de líneas de código, ausencia de pruebas unitarias y uso de frameworks de más de 10 años
- Para ejecutar en Linux un módulo exclusivo de Windows, se resolvió con cientos de miles de líneas de código copiadas y pegadas
- Como resultado, nacieron dos codebases, y agregar funciones o corregir errores requería trabajo por separado en cada una
- Esta situación termina creando una estructura imposible de mantener, y con el tiempo la divergencia entre ambos códigos se agranda
La deuda técnica causada por problemas de personas
- Es difícil convencer a la dirección de impulsar proyectos de deuda técnica, y como al final casi no hay cambios visibles en funcionalidades, faltan resultados tangibles
- El proyecto se retrasó y se perdió la confianza de la dirección
- La esencia del problema no es la tecnología, sino la actitud de las personas y la cultura organizacional
- Muchos desarrolladores se resisten al cambio y se conforman con la forma de trabajar de antes
- La estructura del código refleja la personalidad y la disposición al cambio de quien lo escribió
- La deuda técnica surge de requisitos poco claros, promesas irreales, elección de tecnologías obsoletas, decisiones de la gerencia de interrumpir esfuerzos y orgullo personal
- Cuanto más fuerte es en un equipo la tendencia a evitar el cambio, más se refleja en el código ese rechazo a cambiar
- Varios desarrolladores seguían trabajando durante años exactamente de la misma manera, e incluso se llegó a escuchar: “no quiero aprender cosas nuevas”
- En un entorno así, la deuda se acumula más rápido de lo que puede limpiarse, por lo que antes de reducirla hay que evitar que siga creciendo
- Como en el símil del triage (clasificación de prioridades) en una sala de emergencias, primero hay que “detener el sangrado”
La brecha entre el mundo ideal y la realidad
- Casi no existe un entorno ideal en el que los problemas de ingeniería puedan resolverse separados de la política o del contexto organizacional
- En la mayoría de los proyectos hay interesados no técnicos
- No funciona la actitud de “confíen en nosotros porque lo estamos haciendo”
- La gestión de la percepción de resultados es tan importante como los resultados reales
- Como las personas no técnicas no entienden de forma intuitiva por qué hace falta pagar la deuda técnica, hay que explicarlo en términos cuantitativos y de valor para el negocio
- Si el liderazgo no tiene formación en ingeniería, es necesario mostrar métricas visibles y efectos concretos
- Al final, que el equipo parezca productivo es tan importante como su productividad real
Habilidades necesarias para un ingeniero senior
- A partir de niveles senior, es indispensable la capacidad de colaborar entre áreas y manejar relaciones humanas
- En la formación de ciencias de la computación no se enseña a lidiar con personas, como la personalidad, el orgullo o la gestión de relaciones
- Incluso un ingeniero con gran capacidad técnica puede fallar ante problemas que requieren cambios organizacionales y a gran escala
- La productividad individual puede ser alta, pero su influencia organizacional es limitada
- El rol de “Heads up coder” es importante
- Una persona capaz de mantener una gran profundidad técnica y al mismo tiempo detectar temprano los riesgos del proyecto y coordinar al equipo
- En vez de trabajar rápido en solitario como un núcleo único, cumple el papel de guiar con eficiencia a todo el equipo
- A diferencia del ingeniero puramente técnico, puede moverse leyendo al mismo tiempo el contexto y los riesgos de la organización
Resumen
- En la raíz de los problemas técnicos siempre hay personas
- La mayoría de los problemas técnicos terminan siendo problemas de personas, cultura y comunicación
- La deuda técnica no es un problema del código, sino el resultado de patrones de comportamiento y de la cultura de una organización
- Para resolver la deuda técnica, primero debe existir aceptación del cambio organizacional y comprensión por parte del liderazgo
- Y más adelante en la carrera esperan problemas mayores que no se resuelven solo con excelencia técnica
- Un verdadero ingeniero senior es un líder equilibrado que maneja tanto la tecnología como la comprensión humana
2 comentarios
Si quieren saber más sobre esto en detalle, les recomiendo leer Peopleware.
Comentario en Hacker News
Sentí que la mayoría de los problemas son problemas de comunicación
Los ingenieros están desconectados de la visión del producto o de los clientes, y el equipo de producto trata a los ingenieros como un simple equipo interno tercerizado
Ventas y CS no entienden cómo sus promesas impactan el roadmap del producto
Al final, los objetivos y las métricas de éxito no están alineados, y todos terminan remando por su cuenta
La solución no es “mejores personas”, sino lograr que todos se comprometan con el mismo objetivo y entiendan cómo su rol encaja con el conjunto
Con la vieja deuda técnica pasa lo mismo: no desaparece por ignorarla. Hay que cuantificar el costo y el riesgo que esa deuda le genera a la empresa, equilibrarla con otros objetivos y armar un plan para ir pagándola
Es una sesión donde el usuario está justo al lado, así que puedes conocerlo en persona, hacerte su amigo y aprender sobre su rutina y su contexto
Se agenda automáticamente cada 3 semanas y se realiza sin ítems de acción aparte. Cada vez la gente se sorprende, se corrigen pequeños bugs y se generan conexiones
Lo opero con un programador automático integrado con la API de Slack, y la parte más difícil es coordinar horarios y lograr que la gente participe
La dirección no escucha a los subordinados, y los subordinados compiten por llamar la atención
Hace poco en nuestro departamento un consultor propuso migrar a una nueva plataforma; nadie estaba de acuerdo, pero no se pudo detener. Al final, nadie escucha a nadie
A la pregunta “¿por qué hacemos esto?” solo vuelve una respuesta tipo “confía en mí, hermano”
No creo que ese comportamiento de algunos PM vaya a cambiar. Por eso los ingenieros están asumiendo directamente funciones de producto para cerrar esa brecha de comunicación
Me di cuenta de que mucha gente en realidad no siente orgullo por su trabajo
Para algunas personas es solo un sueldo
Sobre todo los colegas mayores han visto sistemas derrumbarse, así que intentan evitar que eso vuelva a pasar
Cada vez que entro a un trabajo nuevo intento establecer lineamientos claros dentro del plan de 90 días, pero al final lo central es el equipo
Algunos equipos tienen hambre de cambio y otros lo bloquean
Si el líder es ignorante o solo elige la opción más rápida y barata, se vuelve aún más difícil
También me hace pensar en casos como el escándalo de la Post Office británica, donde se conocía el problema internamente pero igual fue bloqueado
Antes más de la mitad era trabajadora independiente, pero ahora queda apenas alrededor del 10%
Lo que construimos ya no es “nuestro”, sino “del empleador”
Aunque trabajes más duro, no recibes recompensa; al contrario, solo te cargan más trabajo
Al final, las personas son tratadas como recursos, y si ya no hacen falta, se las desecha
En una crisis, los primeros en ser despedidos son los trabajadores, mientras el CEO recibe millones de dólares
En una estructura así, es imposible esperar que los empleados se comprometan con la empresa
Quien trabaja menos gana más, y a ti pueden despedirte por un reemplazo que cobra la mitad
Las entrevistas se vuelven cada vez más difíciles, otros se roban el mérito y la inflación se come el salario
Al final, “¿por qué desapareció el orgullo?” parece un misterio, pero en realidad la respuesta es obvia
Pero las empresas saben que la mayoría no puede hacer el trabajo que realmente quiere, así que se enfocan en los procesos y flujos de trabajo
Para cada persona, lo mejor es poder hacer algo que le guste y recibir buena remuneración por ello
Que un desarrollador diga “no quiero aprender algo nuevo” no es necesariamente malo
El cansancio por frameworks que cambian todos los días, como en el ecosistema de JavaScript, es distinto de la estabilidad técnica basada en Go o en LTS
La estabilidad también ayuda a la agilidad del producto
Tal vez tengas que negociar con un ingeniero senior que mantiene una vieja base de código en C++, pero llamarlo simplemente deuda técnica es un prejuicio
Solo el IC líder responsable de esa base de código y el manager que lo supervisa pueden juzgar si realmente es deuda técnica o no
Mencionar problemas humanos en una entrevista es una buena forma de que te rechacen
Muchos entrevistadores consideran que solo las respuestas técnicas son correctas e ignoran cualquier insight humano
Yo más bien valoro mucho esa perspectiva, pero luego tengo que entrar en una pelea para convencer a mis colegas
Cuando dije que, según el volumen de mensajes, quizá el procesamiento por lotes era suficiente, él concluyó que “no sabía de colas”
Le dije que llevaba más de 10 años trabajando con productos de datos a escala de petabytes, pero igual me rechazaron porque no encajaba con su diseño de sistemas
Al final, ahora ese equipo está metiendo todos los microservicios detrás de una sola API
Si el equipo no entiende ese equilibrio, entonces tampoco hace falta unirse a ese equipo
Como ingeniero de datos en Big Tech, los dos problemas más difíciles son estos
Primero, por la ley de Conway, cada departamento tiene toolchains y filosofías de datos distintas
Segundo, cada silo insiste en que su forma es la única correcta, pero al mismo tiempo quiere los datos de los demás
La razón por la que no se puede estandarizar es que los líderes de cada área creen que su manera es la única solución posible
Cuando lo ves en la práctica, la mayoría de los enfoques son correctos y equivocados al mismo tiempo
Por fuera parece un problema técnico, pero al final es un problema de personas
Como no hay notificaciones de cambios en los sistemas upstream, recién te enteras cuando saltan las alarmas downstream
Hay tantas solicitudes improvisadas que los sprints pierden sentido, y sobra conocimiento no documentado
Esta experiencia incluso me motivó a estudiar informática a un nivel más bajo
Para impulsar cambios hay que construir una red, reunir a las personas y propagar el cambio con transparencia
Pero para que haya un cambio real hace falta el apoyo de líderes de más arriba, como directores o VPs
AWS publicó una guía para este tipo de transformación organizacional, y AWS Prescriptive Guidance es un excelente plano de referencia
Todo empieza con “unamos a todos en una sola solución”, pero pronto se divide en proyectos separados por área
Para evitarlo hace falta un líder con autoridad real
En el sector público esto es todavía más difícil porque muchas veces las áreas directamente se detestan; en el privado al menos existe el objetivo común de conservar el empleo
Como decía Jerry Weinberg en Secrets of Consulting,
“Aunque parezca un problema técnico, siempre es un problema de personas”
La raíz de los problemas técnicos termina estando en decisiones humanas, comunicación, gestión y capacidades
Trabajé como analista en un proyecto de reemplazo de sistema
El sistema anterior repartía el trabajo con un simple mecanismo round robin, pero el nuevo lo distribuía de forma más justa tomando en cuenta la carga de cada persona
Sin embargo, algunos empleados manipularon el sistema para parecer ocupados, y como resultado los empleados responsables terminaron absorbiendo más trabajo
Explicamos con claridad que la esencia del problema no era técnica sino la falta de supervisión, pero al final nos obligaron a buscar una solución técnica
Por naturaleza humana, el trabajo tiende a expandirse hasta ocupar todo el tiempo disponible, y ese tipo de incentivos perversos hay que controlarlos técnicamente
Si diseñas un sistema suponiendo seres humanos ideales, va a fracasar
Jerry Weinberg, ya desde The Psychology of Computer Programming (1971),
insistía en el principio de que “aunque parezca un problema técnico, siempre es un problema de personas”
Sus libros siguen valiendo la pena incluso hoy
No me gusta esa actitud de culpar a la gente por “no tener orgullo por su trabajo”
La mayoría de los empleados no son dueños de su trabajo; la dueña es la empresa
Si la empresa te obliga a ir en cierta dirección y te castiga por oponerte, ¿por qué ibas a pelear?
No somos más que engranajes de una máquina, y si nos tratan así, actuamos en consecuencia
La actitud egocéntrica del autor me resulta desagradable
Ahora estoy bastante senior y trabajo directamente con sponsors de presupuesto y responsables de requerimientos
Ellos preguntan “haz esto, ¿cuánto cuesta?”, y yo tengo que sacar una estimación aproximada en 18 minutos de una reunión de 30
No saben de tecnología, pero dominan perfectamente el lenguaje del dinero y la política
Algunos problemas los resolví con un solo mensaje de texto, y el presupuesto era de 6 millones de dólares
Otros proyectos se los llevó otro equipo, quemaron 35 millones de dólares y fracasaron
Los sponsors que manejan el presupuesto, en su mayoría, priorizan la política, y su objetivo es “el siguiente puesto”
Cuando ves sus carreras, muchas veces piensas “¿cómo llegó esa persona hasta ahí?”