2 puntos por GN⁺ 2023-12-15 | 1 comentarios | Compartir por WhatsApp

Entrevista con mi madre, programadora COBOL de mainframe

  • Mi madre ha trabajado en uno de los bancos más grandes de la UE desde antes de que yo naciera.
  • El mundo de la programación bancaria es completamente distinto del que la mayoría de la gente conoce.
  • Si mi madre y su equipo dejaran de trabajar, el banco quebraría en cuestión de semanas.

1991

  • Mi madre comenzó su capacitación interna en Nordbanken (ahora Nordea).
  • Presentó varias pruebas y aprobó tests de IQ, evaluaciones psicológicas y pruebas de multitarea.
  • Empezó como programadora COBOL de mainframe de IBM y, 25 años después, seguía desempeñando el mismo rol en el mismo banco.

COBOL

  • COBOL no es un lenguaje de programación llamativo como el Haskell funcional o el Golang concurrente.
  • COBOL es un lenguaje imperativo y procedimental, y desde 2002 también es orientado a objetos.
  • En el contexto de la programación de mainframes, casi no hay gente que sepa COBOL.

Base de datos

  • La base de datos principal se llama IMS, una base de datos jerárquica que IBM creó para el programa Apolo.
  • Se está intentando migrar a DB2, pero es un trabajo que tomará varios años.
  • La base de datos DB2 actualmente almacena alrededor de 10 TB de datos.

Batch

  • Aproximadamente el 80% del sistema está compuesto por trabajos batch.
  • Los trabajos batch se ejecutan en horarios o intervalos específicos, procesando datos o enviándolos a otros bancos e instituciones.

Problemas que enfrenta el banco

  • Los bancos que usan mainframes tienen muchos problemas que deben resolver.
  • Los programadores están envejeciendo y a los nuevos empleados les toma entre 2 y 3 años poder trabajar de forma independiente.
  • Hay programas de hace décadas y nadie sabe qué hacen.

Palabras finales

  • Es muy interesante pensar qué nuevas tecnologías introducirán Nordea y otros bancos en los próximos años.

Q & A

  • ¿Por qué elegiste la programación COBOL de mainframe de IBM? Porque quería trabajar con computadoras.
  • ¿Cuál fue lo peor que te pasó en un día de trabajo? Un colega omitió un punto en un módulo crítico del sistema y el banco estuvo caído durante 16 horas.
  • ¿Cómo será el futuro del banco? Son conscientes de que deben reemplazar el mainframe por algo moderno.
  • ¿Qué desafíos enfrentaste como programadora en los años 90? Ninguno.
  • ¿Trabajar más de 20 años con la misma base de código se vuelve aburrido? Crear sistemas nuevos siempre fue divertido.
  • ¿Da miedo escribir código para un banco? Muchísimo, pero el entorno de pruebas es sólido, así que en general todo sale bien.
  • ¿Alguna vez cometiste un gran error en el banco? En 1997 cometí un error que permitía retirar dinero ilegalmente de cuentas de ahorro para el retiro.
  • ¿Cómo es el ambiente de trabajo? Pasaron de escritorios personales a un espacio abierto, y lo detesta.

Opinión de GN⁺

  • Los mainframes y el lenguaje COBOL siguen desempeñando un papel importante en la industria financiera, y la experiencia en esta tecnología sigue siendo muy valiosa.
  • La complejidad de los sistemas bancarios y la dependencia de tecnologías antiguas dificultan la transición a sistemas nuevos, lo que representa un gran desafío.
  • Esta entrevista muestra que, en contraste con el rápido avance de la tecnología, algunas industrias siguen usando tecnologías antiguas, lo que resulta en un contraste interesante.

1 comentarios

 
GN⁺ 2023-12-15
Comentarios de Hacker News
  • La publicación original en HN de 2016 fue https://news.ycombinator.com/item?id=12096250
    Si buscan más lecturas sobre el tema de que “el mundo de la programación bancaria es un mundo completamente distinto al que la mayoría de nosotros está acostumbrada”, también está bueno An oral history of Bank Python: https://calpaterson.com/bank-python.html
    También apareció antes en HN: https://news.ycombinator.com/item?id=29104047

  • La gente suele pensar que “si eres un programador de mainframe de 20 años, vas a ganar un sueldazo porque la edad tiene un valor enorme”, pero la realidad suele ser un sueldo promedio, o incluso por debajo del promedio, y eso genera un problema de pipeline de talento
    Lo realmente valioso no es la habilidad en sí, como “saber COBOL”, sino el conocimiento organizacional sobre la enorme lógica de negocio acumulada dentro del COBOL. Un desarrollador promedio también puede aprender COBOL, pero cuando un programador COBOL jubilado vuelve con un contrato de 500 mil dólares al año, no es por COBOL, sino por el conocimiento institucional acumulado
    Si los bancos y las instituciones realmente les hubieran pagado mucho a los programadores jóvenes de mainframe, el problema demográfico actual habría sido menos grave

    • En la universidad de posgrado conocí a alguien que estaba en esa situación. Trabajaba en un banco, lo despidieron durante la crisis financiera, y el banco quería migrar el sistema existente a algo como Java
      Al ver que el proyecto estaba casi terminado, pensaron que el equipo de reescritura ya estaba lo bastante familiarizado con COBOL como para hacer el resto sin él, pero en realidad, aunque entendían COBOL, necesitaban desesperadamente su conocimiento institucional. Al final volvió a tiempo parcial con una tarifa de consultoría absurdamente alta hasta que terminara la transición, y mientras tanto siguió con la universidad de posgrado para desarrollar sus capacidades
    • Trabajé con sistemas core COBOL en una gran aseguradora y estoy totalmente de acuerdo. La empresa no pagaba por el conocimiento de COBOL en sí, sino por las personas que conocían las rarezas y trampas no documentadas dentro del código
      Un programador decente puede leer y seguir un programa COBOL. Pero no sabe por qué falla una exportación crítica durante la extracción de datos para una presentación 10-K. Fue porque alguien asumió que cierto número de registros no superaría los 3000 y hardcodeó que simplemente arrojara un error si se pasaba de ese valor
    • En mi primer trabajo hice tareas de mainframe para banca/seguros, y el entorno laboral era bastante malo, desde cosas menores como el código de vestimenta hasta cosas difíciles de tratar como una base de código legacy horriblemente anticuada. Lo habría tolerado si pagaran bien, pero tampoco era el caso
      En realidad ganaba mucho menos que en mi trabajo anterior instalando infraestructura de cableado físico, es decir, fibra óptica y Ethernet de cobre, y elegí ese trabajo básicamente porque la oficina tenía aire acondicionado. No era algo que quisiera convertir en carrera
      Cuando trabajé como administrador de sistemas Windows de nivel medio dando soporte telefónico a clientes en un proveedor cloud, ganaba casi 30% más que como junior de mainframe en banca/seguros. Aunque era una habilidad escasa y una industria de alto valor, el trabajo de mainframe estaba mucho peor remunerado, y en esa empresa los desarrolladores de mainframe eran los desarrolladores peor pagados en todos los niveles de experiencia. Los únicos que recibían una compensación adecuada eran contratistas independientes que habían trabajado 30 años antes de jubilarse
    • Tengo experiencia en COBOL, también trabajé en mainframes y estaría dispuesto a hacerlo de nuevo. Para los estándares de los programadores COBOL, todavía soy joven, así que alguien podría aprovecharme por 20 años más
      Pero los sueldos de esos roles son pésimos comparados con la compensación que puedo obtener con otras tecnologías, y la vida moderna te presiona mucho para perseguir salarios más altos
    • De hecho, eso pasa. Trabajé en un banco multinacional con sede en Estados Unidos, y el equipo de la casa matriz creó un programa vistoso para atraer recién graduados en ciencias de la computación
      El programa ofrecía el valor de mercado “justo” para puestos de entrada en la industria, y durante el primer año los hacía pasar por 2 o 3 equipos o departamentos. Al final, si la empresa todavía los veía con buenos ojos, el candidato podía elegir el equipo al que entraría como empleado de tiempo completo, pero no había aumento salarial, y para ese momento ya se había filtrado a quienes no lograron rendir rápidamente
      Para la empresa, el resultado fue excelente. Podían tener programadores jóvenes más competentes en COBOL que sus nuevos colegas por 60 mil a 70 mil dólares al año, mientras que compañeros senior o de larga trayectoria cobraban, según el caso, 200 mil a 400 mil dólares
  • Mi abuela programaba con tarjetas perforadas, aunque no sé en qué hardware, y ya es tarde para preguntarle. Mi padre trabajó mucho con Fortran y COBOL en mainframes soviéticos, y después hizo bastante trabajo de Y2K en Estados Unidos
    Lo más genial de todo es una impresión de un programa Fortran que mi padre rompió en tres partes para envolver película grande de 64 mm de unas fotos de montañas que había tomado antes. Probablemente salió de un mainframe Minsk-32, el programa se llama MATR1, hace manipulación de matrices y en los comentarios menciona terreno. Ahora lo tengo enmarcado en la pared cerca de mi mesa de trabajo
    Yo también he programado toda mi vida en varios lenguajes, y ahora mi hijo adolescente se está interesando por la programación haciendo Java y Python en la preparatoria. Vamos rumbo a la cuarta generación de programadores

    • Suena como una idea para una película donde la misma base de código se transmite de generación en generación. El título Código legacy le quedaría bien
  • Si es cierto que, desde el punto de vista técnico, ese es el puesto más importante del banco, entonces, considerando la cuota de mercado de Nordea en Suecia y los países nórdicos, si ese equipo desapareciera podría sacudir la economía sueca, y quizá incluso la nórdica. Entonces creo que también tendría un impacto considerable en la UE.
    Desde que leí este artículo, no dejo de preguntarme si los programadores COBOL que mantienen funcionando bancos como este no son un factor bus enormemente subestimado en varias economías del mundo. También me pregunto cuál será el plan de respaldo para una situación así.
    [0] https://en.wikipedia.org/wiki/Nordea

    • Me pregunto si los programadores APL estarán en una situación parecida. Tengo entendido que bastantes grandes empresas usan APL.
    • El plan de respaldo para una situación así podría ser, tristemente, dejar de funcionar durante varias semanas: https://en.wikipedia.org/wiki/TSB_Bank_(United_Kingdom)#Migration_to_the_Sabadell_Proteo_banking_platform
      Creo que la pérdida de conocimiento institucional debe haber sido un factor importante en ese desastre.
    • Como programador al que lo atropelló un autobús —y justamente el mismo autobús en el que había viajado 5 horas hasta la terminal en el oeste de Grecia—, diría que el riesgo de morir atropellado por un auto es mucho mayor.
      Si a eso le sumamos el aumento en las ventas de SUV, que son más peligrosas para peatones y ciclistas, hasta puede resultar sorprendente que los bancos no colapsen por programadores muertos, sino por mala contabilidad y fraude.
  • La parte de “tenía un escritorio propio, pero ahora nos mudaron a un espacio abierto donde uno elige cualquier lugar para sentarse, y lo odio” me pega raro y fuerte, aunque nunca haya trabajado con mainframes.

    • Yo también prefiero muchísimo tener escritorio propio. Es muy natural que una persona configure su entorno según sus gustos y preferencias; no entiendo que algunos diseñadores de oficinas no lo tengan en cuenta.
    • Me pregunto si en la mayoría de las oficinas pasa como en la nuestra: le dicen “asientos flexibles”, pero en la práctica todos tienen su lugar, llegan y se sientan siempre en el mismo escritorio, y en general los demás lo respetan.
      Como la silla, la posición y el brillo del monitor, la altura del escritorio, etc., están ajustados a cada quien, el concepto mismo de hot desking se vuelve ridículo. Ojalá lo abandonaran oficialmente.
  • Cuando trabajaba como consultor de integración de sistemas en servicios financieros, tenía que hacer muchas integraciones con estos sistemas bancarios core.
    Por lo general, si se negociaba una interfaz completamente nueva, la fricción técnica, comercial y de cumplimiento regulatorio era tan grande que el proyecto podía retrasarse fácilmente 1 o 2 años o más, así que intentábamos reutilizar puntos de integración existentes de proyectos anteriores.
    La integración normalmente consistía en entregar documentos estructurados antes de cierta hora de la tarde para procesamiento por lotes nocturno. Los documentos de datos basados en offsets incluyen por diseño zonas aún no asignadas para futuras actualizaciones y usos; si se necesita información nueva, se negocia qué bytes de esas zonas se pueden usar.
    Del lado de extracción de datos a veces se busca una API más “moderna”, pero no conviene esperar algo muy granular tipo REST. Era frecuente reunirse con gente de regulación y cumplimiento para encontrar formas de evitar desarrollos nuevos y costosos.
    Dicho sea de paso, muchas veces la gente de cumplimiento era mucho más práctica y orientada a soluciones que IT. A menudo era más difícil convencer a nuestro propio equipo de que la letra de la norma no necesariamente debía interpretarse de la manera más restrictiva y literal, que ponernos de acuerdo con los responsables de cumplimiento.
    Si uno imagina que esta capa de integración se acumuló durante décadas a lo largo de cientos de proyectos, empieza a entender por primera vez por qué es tan difícil reemplazar los sistemas core.

  • Mi suegra trabajó toda su vida en el departamento de IT de una aseguradora. No programaba mucho, pero con el tiempo se convirtió en una fuente de conocimiento del dominio.
    Tiene muchas historias de antes. Antes de los sistemas informáticos propiamente dichos, por supuesto, todo se almacenaba en documentos físicos, y su primer proyecto después de graduarse de la universidad fue recorrer oficinas satélite para reorganizar los sistemas de archivo de las sucursales de acuerdo con la nueva estrategia definida por la casa matriz.
    Mientras el equipo literalmente sacaba todos los documentos, les cambiaba las etiquetas y los volvía a guardar, el trabajo de esa sucursal se detenía, y el proyecto completo tardó más de un año. Eso me cambió un poco la perspectiva sobre mi propio trabajo.

    • Pensando en cómo los bancos de esa época llevaban el papel al límite, es difícil imaginar la complejidad de un banco moderno. No sé lo suficiente de finanzas como para saber siquiera por dónde empezar a hacerme una idea.
  • Ojalá hubiera hablado más con mi abuela antes de que desarrollara demencia. Sabía que era matemática y programadora, pero hace unos años, en una conversación breve, me dijo que en la Unión Soviética trabajaba calculando órbitas de satélites.
    Espero que al menos hayan sido satélites.

    • Estoy en una situación parecida. Mi madre trabajaba en simulaciones de software para el sistema AEGIS. No era algo común para una mujer negra en los años 80.
      A los 20 años obtuvo una licenciatura en matemáticas en 3 años, y en los años 70 programaba computadoras con tarjetas perforadas.
      Ahora ni siquiera puede atarse los cordones de los zapatos de forma confiable. Ojalá registren los logros y las historias de vida de sus seres queridos antes de que sea demasiado tarde.
    • Si alguna vez pensaron en hacer algo así, recomiendo mucho que lo hagan. Si se preguntan cómo empezar, recomiendo la app de StoryCorps.
      Es fácil de usar, trae muchas preguntas prearmadas y también permite crear preguntas propias. Pueden grabar directamente en el teléfono y, si quieren, subir la entrevista a la Biblioteca del Congreso de Estados Unidos.
      https://storycorps.org/participate/storycorps-app/
    • Podría haber sido ambas cosas: https://en.wikipedia.org/wiki/Fractional_Orbital_Bombardment_System#Development_history_and_deployment
  • Mi abuela cumplió 95 años este año. Todavía va todos los días a un instituto de investigación del antiguo bloque soviético y escribe simulaciones numéricas en Fortran y Maple.
    Sus colegas todavía no quieren que se jubile, y ella también posterga la jubilación todos los años. Su conocimiento de análisis numérico y matemáticas es extraordinario, y me enorgullece muchísimo.

  • Mi primer trabajo como programadora fue en una empresa de transporte, donde había muchos programadores que llevaban más de 15 o 20 años trabajando, y muchos de ellos se dedicaban principalmente a mantener COBOL, que era lo que sostenía el negocio.
    Entre esos programadores sénior había muchas mujeres; en el grupo sénior daba la impresión de que eran más del 50%. Lo triste era que, aunque entre los programadores jóvenes todavía había bastantes mujeres, en general eran hombres.
    Como esa empresa contrataba sobre todo en universidades técnicas locales, parecía un caso interesante que mostraba cómo, con el tiempo, fue disminuyendo la cantidad de mujeres que ingresaban a carreras de ingeniería de software.

    • Recuerdo haber escuchado que, antiguamente, la programación de computadoras se consideraba algo parecido a la mecanografía o al trabajo de secretaria, por lo que al principio atraía principalmente a mujeres.