█████▒▄▄▄       ▄▄▄▄    ██▓ ▒█████        ▄████▄  ▒█████   ███▄ ▄███▓      ▄▄▄       ██▀███  
▓██   ▒▒████▄    ▓█████▄ ▓██▒▒██▒  ██▒     ▒██▀ ▀█ ▒██▒  ██▒▓██▒▀█▀ ██▒     ▒████▄    ▓██ ▒ ██▒
▒████ ░▒██  ▀█▄  ▒██▒ ▄██▒██▒▒██░  ██▒     ▒▓█    ▄▒██░  ██▒▓██    ▓██░     ▒██  ▀█▄  ▓██ ░▄█ ▒
░▓█▒  ░░██▄▄▄▄██ ▒██░█▀  ░██░▒██   ██░     ▒▓▓▄ ▄██▒██   ██░▒██    ▒██      ░██▄▄▄▄██ ▒██▀▀█▄  
░▒█░    ▓█   ▓██▒░▓█  ▀█▓░██░░ ████▓▒░ ██▓ ▒ ▓███▀ ░ ████▓▒░▒██▒   ░██▒ ██▓  ▓█   ▓██▒░██▓ ▒██▒
 ▒ ░    ▒▒   ▓▒█░░▒▓███▀▒░▓  ░ ▒░▒░▒░  ▒▓▒ ░ ░▒ ▒  ░ ▒░▒░▒░ ░ ▒░   ░  ░ ▒▓▒  ▒▒   ▓▒█░░ ▒▓ ░▒▓░
 ░       ▒   ▒▒ ░▒░▒   ░  ▒ ░  ░ ▒ ▒░  ░▒    ░  ▒    ░ ▒ ▒░ ░  ░      ░ ░▒    ▒   ▒▒ ░  ░▒ ░ ▒░
 ░ ░     ░   ▒    ░    ░  ▒ ░░ ░ ░ ▒   ░   ░       ░ ░ ░ ▒  ░      ░    ░     ░   ▒     ░░   ░ 
             ░  ░ ░       ░      ░ ░    ░  ░ ░         ░ ░         ░     ░        ░  ░   ░     
                       ░                ░  ░                             ░                     

Me encontré con un tema que, cada tanto, aquí también he tocado con respecto a la figura de responsabilidad de la comunidad de IT con respecto a su trabajo y cómo otros le quieren forzar estructuras, colegiaturas y limitaciones para hacerlos responsables.

Es un tema interesante que siempre genera reacciones virulentas por parte de los que están involucrados en sistemas porque... ¡quienes opinan usualmente son los de afuera! Queriendo forzar formalismos y estructuras que se utilizan en otras disciplinas.

Vamos a la pregunta clave ¿Debería ser responsable el encargado de IT de una empresa por las cosas que fallen? Es decir, desde el software que se desarrolla hasta una intrusión de seguridad ¿Es posible esto? Cabe destacar que quienes lo proponen usualmente no saben diferenciar una tecla de una taza de café...

Los ingenieros civiles son responsables de su firma

Uno de los argumentos más utilizados es el de comparar la profesión de sistemas con otras para buscar paralelos, un ejemplo de esto es aclarar que un ingeniero civil que firma por el diseño y construcción de un puente es penalmente responsable por las consecuencias de que éste se caiga.

Así con arquitectos, médicos, y varias profesiones más. Casi todas tienen un siglo más de existencia y profesionalismo que la de sistemas que, quiérase o no, es muy nueva.

Hay una clave: en todas esas profesiones lo que hace esa persona lo ejecuta y lo ubica en la pirámide de decisiones, el médico decide si corta o no tal parte del cuerpo, las consecuencias son imediatas. Okey, el ingeniero probablemente vea sus consecuencias en 50 años, el de sistemas no tiene idea de qué está sucediendo con lo que hace, es todo demasiado nuevo y nada estandarizado.

No sólo es una profesión nueva, no es una profesión, son muchas englobadas en una misma sigla "IT" pero que no tienen nada que ver entre sí aunque dependan entre ellas.

Esto ya nos tira la pista de un problema ¿Quién es el encargado en jefe? ¿El responsable? ¿Es acaso el de diseño, el de UX, el de maquetado, el de backend, el DBA o el sysadmin? ¿Quién de todas esas personas tiene qué responsabilidad y por qué debería tenerla?

En casi la totalidad de los trabajos que he tenido, y supongo que no debe ser muy distinto para ustedes, no fui yo quien firmó ni decidió qué se iba a hacer y pocas veces el cómo, usualmente fue forzado. Eso nos lleva a otra pregunta.

¿El responsable es quien hace o quien pone la firma?

El software no es algo que hace una sola persona, lo hace un conjunto de personas. Así como el ingeniero no construye el puente su responsabilidad está limitada a lo que puede hacer, si la empresa constructora ahorra en materiales, si el que tiene que poner los tornillos no lo hace (por negligencia o mala intención) y si no lo dejan inspeccionar su obra, está claro que habrá problemas.

Pero cuando veo que se quiere forzar lo mismo hacia los programadores no veo que estén apuntando al ingeniero civil, están apuntando al obrero.

El software muchas veces es como un puente que construye un tipo solo al que le prometieron los planos que nunca llegaron y tiene que hacer lo que puede con recursos limitados y sin tiempo.

¿Quién es el responsable ahí? Usualmente la compañía, el gerente, el project manager, el vendedor, el de cuentas, el de legales y un largo etcétera. El developer apenas entra al final, cuando hay que ejecutar algo mal presupuestado y sin recursos. Es el que se cuelga del andamio.

Por eso existen los contratos y una empresa de desarrollo le entrega al cliente uno para que firme, ahí deslinda responsabilidad de algunas cosas y se hace cargo de otras, en muchos casos nadie arma un contrato complejo y es sólo para "entregar" algo barato que el cliente quiere "ya mismo".

El que toma las decisiones NUNCA es el developer, siempre hay alguien haciéndolo y es el que comete los abusos y excesos ¿No debería ese ser el responsable? ¿O Ninguno? Al fin y al cabo hay un cliente comprando y tomando la decisión que, usualmente, es la más barata que había entre las opciones de mercado.

Si armarmos el organigrama veremos que nunca se encuentra el programador ni en la mitad superior de la misma, es de la parte baja, de la base, las decisiones las toma siempre alguien que está vendiendo, más cerca del dinero, más cerca del negocio.

La realidad es un poquito más compleja

Si se quiere reducir el problema de la responsabilidad a un individuo está claro que quien busca eso lo hace por dos motivaciones principales: o es el que se va a llevar una porción de la torta (ej: Colegiaturas) o está buscando un chivo expiatorio para algo.

En la realidad tenemos un escenario completamente distinto a esa fantasía de solucionismo barato.

Por un lado el empleado contrata a los developers más jóvenes y novatos posibles, baratos, entrenándose en "lo último" y sin experiencia en absolutamente nada. Su código es un colador, no hay otro resultado posible. Son baratísimos y reemplazables.

Eso implica que el developer con conocimiento de campo real no es contratado o se lo deja de lado, es caro, es "lento" y se preocupa por la seguridad de su código. Para abaratar costos hay que bajar la seguridad.

Sumado a todo esto están los tiempos nada realistas que suelen presupuestar. Si algo se tardará 10 horas (número tirado al aire por el developer luego de ser presionado por el PM que fue presionado por el gerente) pocos sumarán más horas de buffer, algunos hasta las recortarán arbitrariamente (tuve un jefe que hacía esa estupidez).

Combinemos ahora con el cambio casi constante de requerimientos, sea porque el cliente no se decide nunca y cambia de opinión a cada rato o porque el estúpido de cuentas le sigue tirando ideas a éste y no le cobra la diferencia por cada nuevo pedido. Los sistemas se volvieron tan dinámicos que la calidad final se ve afectada permanentemente.

QA? ¿Alguien dijo QA? La calidad de producto es costosa, poner a un team para testear y otro para hacer QA es costoso, mejor que todo eso lo haga el mismo developer que, todos sabemos, NO DEBERÍA TESTEARLO. Pero no, olvídense, así pasan todos los bugs a producción.

El cliente, además de todo esto, está pagándole al que menos dinero pidió y más rápido prometió entregarlo, muchas veces asoció ese timeline a acciones de marketing y otra cosa que hace que lo requiera sí o sí así como viene, sin testing, sin QA, sin seguridad.

Si se produce mal software ¿Es culpa del programador? Pues no mi ciela, es de toda esta estructura extremadamente dependiente de la inmediatez y los costos bajos.

¿Tiene solución? Responsabilizar a un dev no hará que se deje de producir software malo, sólo creará una casta de privilegiados en algún "Colegio de Ingenieros de Software" como existe en varias provincias argentinas y que sólo sirve para recaudar dinero a costa de otros y limitar a los mejores dejando sólo lugar a los dinosaurios.

Las soluciones van por otro carril, el de estabilizar los requerimientos, disponer de testing y QA, que el mismo cliente apunte a la calidad O NO SE QUEJE, y así. El developer, al fin de cuentas, está colgado de un andamio preguntándose por qué ese tornillo no entra en esa rosca, nada más.