- Un gran proyecto para un cliente importante de una empresa Fortune 500 comenzó dependiendo de un producto de un vendor, pero en realidad era un software casi semiterminado que requería una personalización pesada
- La integración del vendor combinó a la vez las desventajas de un paquete inflexible y del desarrollo a medida, y terminó en una marcha de la muerte de integración para intentar cumplir con el lanzamiento de octubre tras la entrega de agosto
- Un diseño que guardaba todas las transacciones del cliente en un único documento JSON gigantesco provocó problemas de rendimiento, y el entonces límite de 16 MB por documento de MongoDB se reveló como una limitación fatal durante la conversión de datos reales
- La empresa ocultó el problema al cliente y al vendor, retrasó el lanzamiento un mes y, con un equipo interno de 3 personas, llevó a cabo una reescritura skunkworks para reemplazar la integración del vendor en aproximadamente 2 meses
- Cuando el CTO ordenó trabajo durante las fiestas justo antes de Navidad, el líder del equipo reportó cada día como si el trabajo ya terminado siguiera en curso para darles descanso a los desarrolladores, y el equipo logró cumplir con el calendario de pruebas de enero y el lanzamiento
Un mal diseño que comenzó con un producto de vendor
- En una empresa Fortune 500, el CTO prometió entregar un gran proyecto para un cliente importante con el que tenía una relación personal
- La parte central se subcontrató a una gran empresa de servicios tecnológicos, y el vendor aseguró que tenía un producto que se encargaría de la mayor parte del trabajo pesado
- En realidad, el producto apenas coincidía a grandes rasgos con los requisitos, así que se necesitaba una personalización profunda para lograr el comportamiento requerido
- Como resultado, se juntaron las desventajas del software del vendor y del software a medida
- Terminó siendo un paquete inflexible que había que forzar para hacer algo distinto de aquello para lo que fue diseñado originalmente
- Quedó bifurcado del codebase principal del vendor, lo que elevó el costo de mantenimiento y además abrió la posibilidad de que algún día se quedara sin soporte
- Quienes participaban en el proyecto veían que este enfoque no era bueno, pero como la cadena de reportes directos al CTO cambiaba con frecuencia, las reuniones de estado terminaban en algo como “buena idea, jefe”
Retrasos del calendario y una estructura de datos fatal
- El equipo interno de desarrollo construyó por su cuenta otras partes del proyecto, mientras el vendor prometía durante todo el verano que su producto pronto estaría listo para integrarse
- Cuando el producto del vendor fue entregado en agosto, comenzó una marcha de la muerte de integración con el objetivo de lanzar en octubre
- En septiembre aparecieron bugs lo bastante graves como para bloquear el lanzamiento
- El producto del vendor almacenaba todas las transacciones del cliente como registros JSON dentro de un único documento JSON gigantesco
- A medida que se acumulaban los datos de prueba, el rendimiento se volvía cada vez más lento
- Cada vez que se agregaba una nueva transacción, se leía desde la base de datos el documento JSON completo y luego se anexaba el nuevo registro al final
- El vendor dijo que podía arreglarse agregando índices a los campos de las transacciones, y por un momento pareció ayudar
El límite de 16 MB de MongoDB y la reescritura oculta
- El problema más grande era que la base de datos elegida por el vendor era MongoDB, que en ese momento tenía un límite de 16 MB por documento
- En octubre, cuando el equipo de migración comenzó a cargar datos reales del cliente, empezaron a chocar con ese límite de 16 MB
- La empresa decidió iniciar operaciones con un mes de retraso sin revelar esa limitación al cliente
- Al mismo tiempo, arrancó un proyecto skunkworks para reemplazar la integración del vendor
- Tampoco le informaron esto al vendor
- En la práctica, ocultaron la situación clave tanto al cliente como al socio tecnológico
- Originalmente había unas 70 personas asignadas por parte del vendor, pero para el reemplazo interno solo destinaron 3
- 1 para el diseño de la base de datos
- 1 para construir el backend que interactuaba con la base de datos
- 1 para construir la lógica de negocio y los servicios web
La decisión justo antes de la marcha de la muerte navideña
- Al cliente se le informó que en enero se le entregaría una nueva versión para pruebas y que corregiría los defectos más críticos que se habían aceptado al iniciar la operación original
- Pero no se le dijo al cliente que en realidad se estaba reescribiendo todo el sistema central en unos 2 meses
- El proyecto original había tomado más de un año hasta el lanzamiento, pero la reescritura tenía que hacerla un equipo de 3 personas, incluyendo el periodo de fiestas
- Hacia mediados de diciembre, a quienes participaban en el proyecto se les notificó el trabajo durante las fiestas no como una solicitud, sino como una orden
- La mayoría del equipo ya llevaba 6 meses trabajando entre 60 y 80 horas por semana y estaba quemada
- Los lanzamientos de software traen una presión y una recompensa parecidas a las de un espectáculo en vivo
- El resultado de meses o años de preparación llega a usuarios reales el día del lanzamiento
- El desarrollador obtiene una fuerte sensación de logro en el “lo hice” y en la reacción de los usuarios
- Un lanzamiento de software puede sentirse como una presentación en vivo para personas introvertidas
La semana en que le mentí al CTO y dejé descansar al equipo
- Cuando ya se acercaba Navidad, el equipo de 3 personas había completado casi todo el software de reemplazo en un mes
- Todavía quedaban funciones por pulir, pero si el equipo evitaba quemarse, podía cumplir con el calendario de pruebas de enero
- Cuando el CTO ordenó cancelar las vacaciones, el líder del equipo respondió “OK” de cara al exterior
- En realidad, les dijo a los 3 desarrolladores: “Descansen una semana. Yo me encargo”
- Cada mañana, el líder entraba a la reunión obligatoria de estado y le reportaba al CTO como si trabajo ya terminado el mes anterior siguiera en progreso
- “El equipo está trabajando duro. Hoy alcanzamos el hito de integración #73”
- “Ayer el equipo avanzó muy bien y terminó otro servicio web”
- Los desarrolladores volvieron una semana después ya recargados
- El equipo cumplió con el calendario de enero, completó un buen lanzamiento y por un momento se sintió como una banda de rock
- Más cerca de Herman’s Hermits que de The Beatles, pero aun así, recuerda que se sintió bien
1 comentarios
Opiniones de Hacker News
Si eres de esas personas que cancelan sus vacaciones y siguen trabajando porque “lo importante es cumplir la fecha de entrega”, como alguien que ya lo vivió, quiero decirte: deja de ser tan tonto.
Es especialmente difícil parar cuando te reconocen por trabajar duro, pero al final terminas lamentando todo ese tiempo.
Si la estructura de la empresa da por hecho que puede usar los días libres y vacaciones de sus empleados para vender su producto, entonces está contribuyendo a crear este mundo lleno de problemas en el que vivimos.
Si mucha gente lo hace, más gente tendrá que hacerlo; si nadie lo hace y todos actúan como si esa exigencia fuera absurda, la empresa terminará haciendo estimaciones realistas aunque le duela el bolsillo al CEO.
Avisas tus planes de vacaciones, consigues reemplazo, lo pones en el calendario del equipo, haces la transferencia de responsabilidades y simplemente descansas.
Los proyectos van y vienen, y los cronogramas a veces se corren solos.
Si empiezas a mover tus vacaciones para ajustarte al calendario de un proyecto, nunca vas a poder tomarlas en toda tu vida.
Una excepción sería un rol con periodos ocupados claramente conocidos, como fin de año, cierre de trimestre o temporada de impuestos, donde sería inapropiado desaparecer justo entonces.
Mi primo trabajó casi todos los días hasta la 1 de la mañana desde septiembre de 2023 hasta enero de 2024 para terminar un proyecto pésimamente gestionado, y solo descansó en Navidad, e incluso eso fue porque era una festividad religiosa y el director lo permitió por miedo a que los empleados demandaran.
Se perdió cosas importantes y bajó unas 20 libras por el estrés.
La empresa tenía un plazo ajustado para migrar a un sistema nuevo; lo sabía desde hacía 5 años, pero no empezó hasta el año anterior.
Si no cumplían el plazo, les costaría millones de dólares en cargos fuera de contrato, y al final el equipo llegó a la fecha, pero la recompensa fue que unas semanas después lo despidieron porque su puesto había sido eliminado.
Ahora, con más de 50 años, está buscando empleo en el peor momento posible.
Son adictos a sentirse valiosos e importantes, y cuando terminan la jornada no tienen otra cosa que hacer.
En algunos casos, el empleado premiado también tenía parte de la responsabilidad por ese desastre.
Recién alrededor del cuarto caso los altos directivos en la sala se dieron cuenta de que la empresa tenía un problema estructural.
Si hay gente joven leyendo esto, que una historia así termine de esta manera depende muchísimo de la empresa y la suerte.
En una empresa sana, probablemente la forma de implementación tercerizada ni siquiera habría empezado.
Es un patrón de fracaso demasiado obvio, cuyo resultado una persona con experiencia podría prever antes de arrancar.
En una etapa más temprana, la gente no le habría mentido al CTO diciendo que todo iba bien; le habría dicho que no iba bien.
Si se necesitaba una forma más inteligente o creativa de salvar el proyecto, se habría coordinado con el CTO, y quizá también con el cliente.
Tampoco habrían empujado al equipo a trabajar largas horas en días festivos cuando ya estaba en burnout.
Un gerente o líder habría confrontado a los superiores por el éxito del proyecto y la salud del equipo, y, de ser necesario, habría insistido en que el equipo debía descansar durante los feriados.
En una organización “medianamente sana”, un gerente puede ser deliberadamente ambiguo u omitir información, y si eso es bueno o no depende de la situación.
Pero si, como en esta historia, un gerente o líder le mintió de forma abierta y repetida hacia arriba en la cadena de mando, normalmente se considera algo muy malo, sea una empresa sana o no.
Por supuesto, este tipo de situación es mucho más fácil de evaluar después, con los brazos cruzados.
Cualquiera puede equivocarse en un puesto difícil o estando sobrecargado, pero tiene sentido observar el escenario y aprender de él para responder mejor si te vuelven a lanzar a una situación parecida.
Si estás en una empresa así, conviene empezar a buscar otro trabajo.
Cuando la corrupción en la cúpula llega a ese nivel, es imposible arreglarla, y tampoco te van a convertir a ti en CTO.
En 25 años de trabajo nunca vi uno.
Tomó un año y medio arreglarlo, y mientras tanto ni siquiera podíamos revertir ventas porque supuestamente se habían enviado “calzoncillos”.
En realidad no vendíamos ropa interior, solo servicios de red, pero teníamos que esperar a que el sistema cerrara el proceso de pedido antes de poder ayudar al cliente.
Ese miembro del directorio se fue un año después, y me imagino que quedó bastante satisfecho de haber engañado al CEO idiota.
Al final me despidieron de ahí, y no siento ninguna simpatía por esa empresa torpe.
Eran unos tontos que, al intentar tercerizar la “solución”, solo le agregaron sufrimiento a todo el mundo.
Hay problemas que realmente necesitan solución, pero la mitad de eso no es más que basura para sentirse bien por “ahorrar dinero no construyéndolo internamente”.
Al final, tienen que seguir pagando costos de contrato para mantener una basura que ni siquiera construyeron desde el principio.
Me refiero a decir los hechos tal cual son, sin ocultar los problemas, algo realmente raro.
Basta ver los memorandos de seguridad de Microsoft.
Que no haya marchas de la muerte en días festivos es más o menos cierto si trabajas en un banco o en FAANG.
Si es una empresa con “cultura startup”, mejor olvídalo.
En la práctica, cuando hay intereses propios en juego, la actitud frente al trabajo cambia bastante rápido, pero creo que no hay muchas empresas donde uno tenga la oportunidad de conseguir y ver eso.
Muchas veces hice lo necesario en plena noche, doblando las reglas sin que nadie se enterara, y muchas personas capaces también han seguido ese camino.
Incluso vi cosas así en bancos.
Mientras no hagas una apuesta financiera mayor que el valor de la empresa o del equipo, muchas cosas pueden pasar sin consecuencias.
O lo logras y te ascienden, o reduces tú mismo tus posibilidades de ascenso y terminas buscando otro trabajo.
El pasaje que dice que “el producto del proveedor guardaba todas las transacciones de los clientes como registros JSON dentro de un enorme documento JSON, y para agregar una nueva transacción leía todo el documento JSON desde la base de datos y luego anexaba el nuevo registro al final” debería sonarles como una locura
De forma parecida, una vez ayudé con la due diligence técnica sobre una posible inversión de un fondo, y la tabla de usuarios de esa startup también contenía los datos de tickets/reservas
Como cada ticket era una columna, si el usuario más activo tenía 5 tickets en todo su historial, hacían falta 5 columnas
Cuando la revisé, ya tenía más de 500 columnas, y estaban buscando inversión para “escalar”
Por supuesto que era un problema solucionable, pero, como se imaginarán, todo estaba diseñado de una forma retorcida y al revés, y ese fue el momento más evidente de “¿qué es esto?”
No consiguieron la inversión
Toda la base de datos de clientes y productos estaba guardada, junto con contraseñas en texto plano, en un único archivo
.jspúblico de varios megabytes, y con las velocidades de Internet de principios de los 2000 la app tenía que cargar todo ese archivo antes de poder hacer cualquier cosaAdemás, la app era un único archivo gigante, y el directorio estaba lleno de nombres como
index.1.js,index.final.js,index.newest.js,index.45.jsTenía suficiente experiencia como para conocer las buenas prácticas, así que fui con el CEO, logré que despidieran al CTO y empecé a reconstruir todo con
git,mysql, lógica del lado del servidor y una estructura realLuego el servidor Windows donde corría todo esto fue hackeado y convertido en un servidor porno; yo ni siquiera había visto ese servidor y no tenía permisos de administrador, pero por alguna razón terminó siendo mi culpa
Mis primeros trabajos fueron realmente educativos
El sistema lo diseñó un ingeniero sénior que presumía de haber salido de Stanford
Discutí largamente, con datos reales de producción, que no iba a escalar cuando lo lanzáramos, pero nadie escuchó, y a las pocas semanas del lanzamiento se vino abajo
Poco después me cambié de equipo, y lo peor es que ese ingeniero sénior terminó siendo ascendido y el sistema fue entregado a un equipo completamente nuevo para que ellos se pelearan con él
Todo el diseño del sistema era espantoso, y se pueden imaginar por qué
Se ganan a los ejecutivos con cenas y viajes lujosos, entregan un producto desastroso y se aseguran de que sigan necesitándolos en el futuro
En la historia en sí, el CTO no tenía idea de nada
Desde su punto de vista, al final todo parece haber salido bien
Es una victoria para todos, salvo para los desarrolladores que trabajaron 80 horas por semana
Todo en esta historia está roto, incluida la forma en que actuó el protagonista
Que un líder de equipo le dé vacaciones a la gente y lo oculte con una mentira es completamente inaceptable, y entra bastante en territorio por el que la empresa podría despedirlo
De hecho, parece que hasta podría ser un despido con causa
Aunque la cúpula parece tan fuera de órbita que probablemente lo dejen pasar e incluso lo elogien
Sí parece una conducta adaptada al entorno en el que estaba
Como consejo para un nuevo líder de equipo: acá no hay nada de qué enorgullecerse, y la mejor opción habría sido plantear en voz alta que la gente estaba haciendo horas extra y exigir que al proveedor se le aplicaran estándares normales, o que se revisara el alcance del proyecto para ajustarlo a una semana laboral normal
Si logras que una situación así “funcione” de alguna manera, lo único que puedes conseguir es que la gente termine quemada o despedida sin ningún beneficio
Salvo que estén en una situación realmente desesperada para mantener a sus familias, el líder del equipo tiene la responsabilidad de proteger horarios de trabajo razonables frente a exigencias absurdas
Esa es una colina en la que vale la pena arriesgarse a que te despidan, no una colina en la que mentir
Por lo tanto, si no afectó los resultados, es perfectamente aceptable que el líder les dé vacaciones a las personas e incluso que mienta
Si lo hubieran compartido, ¿qué habría hecho la gerencia? Habría adelantado aún más el proyecto
A la gente que quiere hacer trabajar más duro a otros para lucirse hay que darle una lección
¿A quién se supone que le salvó el día?
¿Al proveedor mediocre que entregó basura?
¿Al CTO que claramente se rodea de yes-men y no tiene idea de lo que pasa en la empresa?
¿A los desarrolladores que se mataron trabajando y a quienes luego les quedó un “no pasa nada, les di una semana libre”?
¿Al protagonista, que les mintió a todos para cumplir una fecha límite arbitraria de una empresa a la que no le importan sus empleados?
Esta historia me hizo estremecer a cada paso
Soy de trabajar duro, y a veces también hice horas extra para que un lanzamiento para un cliente saliera sin problemas, pero esta historia es pura locura
Uno invierte tiempo extra de vez en cuando porque existe una relación de confianza con el jefe y sabe que siempre puede decir la verdad
De hecho, ese es el concepto central de una cultura sin culpas, y solo es posible cuando todos dicen la verdad
Mentir como loco para cumplir la fecha límite de un CTO idiota es, literalmente, una pérdida de cordura
Si estás en una situación así, sal de ahí de inmediato y busca un mejor trabajo
¿“Orgullo y sentido de logro” más burnout?
En la parte de “también cumplimos el cronograma de enero, lanzamos de forma excelente y por un momento fuimos rockstars”, ese “nosotros” claramente significa yo
Puede que haya tenido suerte, pero nunca me despidieron por decir la verdad, y la verdad era más fácil de sostener.
Era decir cosas como: “hay un bug en una biblioteca de terceros que está en la ruta crítica. Podemos hacer que sea más difícil toparnos con el bug, pero no podemos corregirlo hasta que el proveedor lo arregle”; o “el crecimiento de usuarios expuso problemas de rendimiento antes de lo esperado. Mientras tardamos 2 meses en corregirlos, podemos mitigarlos gastando el triple en infraestructura, o podemos perder clientes por el rendimiento”; o “nuestro cliente más grande recién entendió lo que quería después de recibir la primera iteración. Es algo totalmente distinto de lo que pensábamos construir. Podemos construir eso y generar ingresos, o podemos perseguir un sueño y morir”.
De nuevo, quizá tuve suerte, pero la honestidad me funcionó bien.
Por eso, como dijeron otros, dicen “lo vamos a revisar” y luego lo van desplazando lentamente, o lo asignan a tareas menores.
La segunda opción es quedarse callado y verlos pelear durante mucho tiempo hasta fracasar.
Normalmente toma alrededor de un año, pero también he visto que se caiga en 2 o 3 meses y que en el siguiente trimestre prácticamente corten a la dirección.
Si alguien te pide tu opinión, puedes explicar tus preocupaciones con diplomacia; si no te la pide, también puedes quedarte en silencio.
El punto clave es si vas a señalar activamente los problemas de un plan con el que alguien por encima de ti quiere llevarse el crédito.
En cuanto lo dices, sienten que estás cuestionando su criterio y lo toman como un ataque personal.
Es extremadamente difícil hacerlo sin ganarse enemigos, y los enemigos duran mucho; el daño de un solo enemigo es difícil de compensar incluso con varios amigos.
Así que hay que jugar el juego.
Es un detalle muy importante que el protagonista estuviera mintiendo sobre trabajo que ya estaba terminado.
Cada mañana entraba a la reunión obligatoria de estado tipo deathmatch con el CTO y decía: “el equipo está trabajando duro”, “hoy alcanzamos el punto de integración del hito #73”, “ayer tuvimos un buen avance y terminamos otro servicio web”, pero en realidad eran cosas que ya habían terminado el mes anterior.
Desde cierto ángulo, esto se parece a prometer por debajo y entregar por encima.
Si hubiera mentido diciendo que algo aún no terminado ya estaba listo, habría sido mucho peor.
Sin duda habría sido más riesgoso, y tampoco habría sido bueno para el equipo cuando regresara decirles: “aquí están estos tickets, pero ya le dije al CTO que estaban terminados, así que apúrense”.
La interacción entre desarrolladores y directivos sufre mucho por la asimetría de información y la falta de confianza.
Ahora estoy en un proyecto para actualizar una base de código que corre en un compilador antiquísimo.
Llevamos un año trabajando y ya terminamos grandes partes del sistema, pero todavía queda una parte bastante importante.
La dirección no entiende el proceso y tampoco tiene certeza de que el proyecto vaya a tener éxito al final.
No los culpo por estar ansiosos, porque los proyectos de software, especialmente las migraciones, tienen una larga historia de fracasos.
Las reuniones de avance pasaron de ser semanales a dos veces por semana, como si creyeran que eso lo va a acelerar.
Por lo general no asisten directamente, sino que un gerente intermedio actúa como mensajero.
Desde el punto de vista de los desarrolladores, por supuesto que esto va a funcionar, y personalmente nunca dudé de que tendría éxito.
Solo que el sistema es grande y viejo, así que el plazo es incierto.
Lo que queda son meses, no años, y conozco la regla 80/20, pero ya estamos metidos de lleno dentro de ese 20%.
Para la dirección todo es un estado binario de terminado/no terminado, así que les cuesta medir el avance, y no tienen “confianza” en lo que decimos.
Lo entiendo.
Si no hubiéramos hecho nada durante un año y solo hubiéramos tenido reuniones, ellos no lo habrían sabido.
Como es un contrato a precio fijo, no tenemos motivo para alargarlo, pero todo el riesgo lo tienen ellos.
Ya gastaron mucho dinero y están nerviosos.
Tomaron buenas decisiones técnicas con base en el consejo de expertos técnicos externos, pero aun así les falta certeza.
Al final, si el proyecto fracasa, el golpe lo reciben ellos; nosotros, relativamente, no tanto.
No hay una solución fácil.
No basta con decir que los gerentes deberían ser técnicos, y esa tecnología ni siquiera es el negocio principal de ellos.
Traer más consultores tampoco les va a calentar el corazón.
Lo mejor que podemos hacer es seguir empujando y entregar.
Aunque sean bloques de un mes, está bien: hay que desglosarlos y dividir todo en subtareas.
No tiene que ser perfecto; no importa si tiene partes imprecisas.
Recomiendo ponerle a cada bloque un nombre amigable y divertido.
Por ejemplo, funcionan bien nombres de bailes clásicos como tango, chachachá o vals.
Programa reuniones con los gerentes, incluye también a la alta gerencia y pide que los gerentes intermedios observen los standups diarios.
Haz que todos estén de pie para que las reuniones terminen rápido, y hay que dar seguimiento al avance contra las tareas de la lista.
Que se agregue una tarea o que algo se retrase un poco no asustará a nadie mientras en conjunto se mantengan cerca del plan.
Ambos sabemos que el despliegue real es el gran obstáculo, pero no hace falta decírselo hasta que esté listo.
Los retrasos ponen nerviosa a la dirección, y eso se entiende, pero hacer más reuniones no lo acelera.
Que el PM haga check-ins diarios de 30 minutos diciendo que “va a apoyar y proporcionar lo necesario para devolver el proyecto al curso correcto” no ayuda.
Lo único que se necesita es tener menos reuniones.
El único obstáculo es el tiempo, y la razón por la que el tiempo es un obstáculo es que, para empezar, los de arriba insistieron en un calendario poco realista.
Al final, al demostrar que no confían en los desarrolladores, también están demostrando que no confían en su propia capacidad de gestión para haber contratado a los desarrolladores correctos.
Están haciendo muy mal una parte central de su trabajo.
Un proyecto de un año no debería estar en un estado binario de terminado/no terminado.
Debería haber indicadores de avance con los que se pueda trabajar.
La alta dirección no necesita ser técnica, pero en algún punto de la jerarquía tiene que haber alguien capaz de traducir el progreso a un formato comprensible.
Hay dos cosas que sé con certeza sobre el proveedor que son difíciles de perdonar
Una es que hizo que la lógica central dependiera de hacer crecer indefinidamente registros de Mongo, y la otra es que tres personas un poco por encima del promedio, si se lo proponían deliberadamente, podían reemplazarlo en unos 3 meses
El hecho de que ese proveedor haya llegado al punto de tratar con clientes Fortune 500 muestra lo impotentes que se sienten organizaciones parecidas a este cliente incluso ante trabajos de software no tan grandes
De hecho, el alcance de ese proyecto parece algo que algunos de los presentes podrían hacer incluso como proyecto personal
Por eso también se entiende por qué Retool es popular entre líderes técnicos, aunque no necesariamente entre ingenieros
Me pregunto qué otros enfoques de producto podrían cerrar esa misma brecha
Gracias a las hojas de cálculo, cualquier persona de bajo rango podía crear en cuestión de días un prototipo tosco, casi funcional, sin tener que lidiar con nadie más en la organización
Antes de las hojas de cálculo, había que convencer a los superiores para que el departamento de IT tomara la solicitud, y solo ese proceso tardaba al menos 3 meses
Luego habría que esperar unos trimestres más para recibir una implementación tosca, casi funcional, escrita en algo como Cobol o C, que no coincidía con los requisitos
Unos cuantos desarrolladores y personas de soporte fuimos a reunirnos con los usuarios, y los desarrolladores llevaban 6 meses construyendo una nueva herramienta para resolver un gran problema
Pero ese día era la primera vez que los usuarios finales la veían
Poco después ya íbamos de regreso cruzando la frontera estatal, y los desarrolladores venían con la cola entre las patas
Hasta donde sé, nadie volvió a mencionar ese proyecto
La modalidad es hacer que los recién ingresados hagan todo el trabajo y facturarlo como horas de desarrollador senior
Ojalá la gente dejara de usar imágenes de encabezado generadas por IA
Rompen la concentración desde el inicio
¿Ese código está detrás del monitor?
¿Y también hay código en el respaldo de la silla de atrás? ¿O lo que está sentado es un iPad gigante?
Si vas a usar imágenes de IA, al menos deberías esforzarte en que no se vean completamente raras y disparatadas
Estas imágenes se generan literalmente en segundos; ¿esta fue la mejor que eligieron?