/ Pesadilla en la Oficina

Pesadilla en la oficina: La micro consultora

Pepe ha estado trabajando en un lugar decadente y misterioso en el que se la pasa soldando cables e intentando reparar computadoras. Lo llamaremos “El primer trabajo”. En sus palabras, el lugar es un infierno. Un lugar horrible en el que trabajar y eso le ha orillado a pensar en nuevos horizontes.

De hecho, de un tiempo a la fecha, a Pepe le ha surgido la idea de ser programador. Ha vendido un par de sistemas 2 capas en java y le gustó. Es más, lo desea. Le encanta la idea de programar sin tener que ver a nadie y estar en un rincón de una oficina, alumbrado y alimentado por la luz azul del monitor sin tener que cruzar palabra con ningún humano. Este pensamiento le provoca… le parece sublime. Utiliza sus noches enteras para pensar sobre ese trabajo en el que tirará código solo y de calidad considerable. Bueno, eso es lo que el cree… realmente su código es una aberración mal salida del infierno computacional… pero el quiere tirarlo y no ha encontrado la empresa que le de la oportunidad.

Han pasado los meses, tres para ser exactos y de pronto, una oportunidad aparece. La toma y a pesar de ofrecerle un menor sueldo que en su infernal primer trabajo, acepta. No tendrá porque ver a más personas… estará solo, tirando código y participando en proyectos innovadores como los que quería hacer con sus compañeros de la universidad.

Los días en su cabeza no pueden ser más largos… la simple espera lo saca de sus casillas. Sabe perfectamente que lo que le espera no es desarrollar software para llevar cosas a la luna o hacer una distribución de GNU/Linux, como la que quería hacer con sus amigos… pero sabe que el proyecto que hará le encantará.

No hay día que no llegue y plazo que no se cumpla. Llega a su lugar de trabajo y lo recibe el proyecto más innovador y mejor hecho de la historia del mundo y que por cierto jamás imagino: un sistema administrativo. Si no notó la ironía querido lector, se la pongo en cursivas.

chris-ried-ieic5Tq8YMk-unsplash-min

Bueno, al menos estará en java, pensó. De hecho me gustaría hacer una pequeña acotación aquí. Pepe en ese momento pensaba que desarrollar en java era la cosa más espectacular del mundo e, ilusamente, pensaba que no podría existir un proyecto mal hecho en ese lenguaje. Bendita ignorancia.

Para su mala suerte, el software estaba desarrollado en Visual Basic .NET y lo había desarrollado una persona que según comentarios se había ido a trabajar a Microsoft. Diantres, pensó el. El código (ideologías a parte) debería de ser una lindura de ver. Muchas cosas que aprender, pensaba.

No tengo palabras para describir la cara de nuestro protagonista cuando vio el código la primera vez. Era el libro de clean code, pero haciendo todo lo que te dicen que NO hagas. El proyecto estaba tan mal hecho y tan mal diseñado que incluso el y sus compañeros, pensaron que estaba así después de un proceso de ofuscado, para que nadie pudiera mantenerlo o copiar la lógica de negocio y sacar provecho de ella.

El software estaba lleno de nombres de variables con un carácter, nombres de funciones con dos caracteres, cero diseño, cero legibilidadad, cero clases, cero capas, cero todo.

chuttersnap-cGXdjyP6-NU-unsplash-min

Con el tiempo se dieron cuenta que la variable p era pedimento y que la función pp era pago de pedimento. El sistema estaba tan bien hecho, que además, facturaba: gf.

Ante un proyecto de ese calibre, en el que prácticamente el flujo de trabajo era no tocar nada para no romper nada y la refactorización era sumamente dificil; el equipo llegó a una conclusión bastante buena/mala en ese momento. No tocarían el código base, pero escribirían sobre el. Aprovecharon que todo estaba escrito en .NET Framework y utilizaron C# en la misma solución teniendo en cuenta que los dos lenguajes compilan a un intermedio similar y que la experiencia del equipo era más cercana a Java.

Esta especie de fachada le permitió a Pepe avanzar en nuevos requerimientos y retrasarse en el mantenimiento ya que aún con el código sucio que había, tuvo que debuggearlo, refactorizarlo y cambiar los nombres de variables y de funciones lo que tomaba realmente mucho tiempo.

Estos retrasos en el mantenimiento fueron el caldo de cultivo de ciertas interacciones tóxicas que no voy a describir. Solo basta decir que la desesperación de los usuarios era tan grande que la educación y la ética profesional faltó.

A los meses, Pepe se cansó de la toxicidad, de lo mal que estaba este proyecto (y otros más) y renunció.

¿Qué podemos aprender de esta experiencia?

road-trip-with-raj-o4c2zoVhjSw-unsplash-min

  • Escribe código para las personas, no para las máquinas.
  • Si eres freelancer, usa un estándar de codificación común para todos.
  • Intenta escribir código limpio.
  • Siempre se ético y educado.
  • No hables de más provocando que te pidan más requerimientos.
  • Intenta estructurar tu solución con un mínimo diseño.
  • Regla del boy scout: Deja el lugar en el que estuviste mejor que como lo encontraste.
  • Y por sobre todas las cosas, no programes en Visual Basic .NET.

Todos los nombres, situaciones y proyectos aquí mostrados están basados en hechos reales. Hemos cambiado los nombres y lugares para no perjudicar. Pepe somos todos y no es nadie.

Eduardo Montalvo

Eduardo Montalvo

Programador con intereses en machine learning, clean code, arquitecturas de software y formación de equipos técnicos.

Read More