Otro error grave de querer equiparar a los programadores con otras profesiones, va por el lado de la mutabilidad. Es poco probable que un edificio sea modificado en el corto plazo. Menos aún una represa o un puente. Una ruta será repavimentada y le harán cambios con el tiempo.
Salvo raras excepciones, un software, en cambio, muta todo el tiempo. Es como si hoy hicieras una ruta para que circulen autos y en cinco años lo cambies a trenes, en otros cinco a cintas transportadoras y dos años después, con las cintas detenidas, la gente se desplace en bicicletas mientras construís un sistema de trenes maglev alrededor.
O sea que no solo hay mucha gente involucrada y el programador está al final de la lista, sino que además toda esa gente está todo el tiempo metiendo cambios en una dinámica que otras profesiones no tienen. Volviendo al ejemplo del ingeniero civil, si le calcula mal el hierro en una estructura de hormigón, no lo puede corregir o tendrá que construir algún refuerzo. En el software, podrías sacar los hierros y poner unos más gruesos sin tocar el cemento y mientras los ocupantes del edificio están durmiendo.
¿Serán los programadores culpables de todo?
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.
Otros posts que podrían llegar a gustarte...
Comentarios
-
Cuando tenes software que tiene que correr en situaciones criticas y no podes darte el lujo de perder todo un un bug. Se supone que la empresa cliente debería realizar pruebas de QA exhaustivas que certifiquen que el producto no presenta fallas graves. Porque de ahí en adelante toda la responsabilidad cae en ellos y no en los contratados. Salvo que tengas algún 0-day como fue el log4j que no se salva nadie ahí.
-
Habría que ver algún caso tipo el soft defectuoso del 737 Max, quizá es lógico esperar que haya una figura que en proyectos grandes pueda hacerse responsable como el ingeniero de un puente o el director de una película.
Igualmente quizá todas las profesiones y ámbitos van hacia el mismo rumbo, la especialización y tercerización terminan generando tantos responsables que al final no es culpa de nadie (y me viene a la mente un accidente de tren rápido en Alemania que creo que terminó arrasando un puente y después de años y años de juicio no generó responsables).
En resumen: al final el culpable es el proceso mal planeado o mal ejecutado y si se mejora el proceso se evitan futuros problemas similares (aunque la turba quiera incendiar a alguien con sus antorchas). -
Ahí existe toda una cadena de responsabilidades que llega, por el lado de la empresa a responsables de área y del programa 737MAX, y por el lado de la FAA a todos los que pusieron la firma para certificar al avióne hicieron la vista gorda en más de una cosa.
El software en ámbito aeronáutico no es tan fluido además, casa cambio debe pasar por un proceso de certificación bastante exhaustivo (en teoría al menos) antes de implementarse en sistemas operativos (sea de vuelo que equipamiento terrestre)
-
Yo lo que si quisiera que se hagan responsables son los HDP que no documentan nada de nada ni un comentario en una funcion y cuando uno quiere tocar algo te encontras que es un chino basico
Al final de cuentas si hay que asumir responsabilidades deberia hacerlo la empresa desarrolladora no una persona en si, en mi ejemplo personal la empresa para la que trabajo (Claro) desarrollo una aplicacion al estilo flow (cablevision) y son tan ratas que los programadores que la desarrollaron se fueron a otras empresas cansados de los malos sueldos y la gente que quedo ahora son todos programadores junior ya que contratar nuevos programadores senior es muy caro segun ellos, como termino la cosa los desarrollos vienen atrasados mas de un año y cada vez que sale una version nueva sale con banda de errores que no saben ni porque se presentan.
-
Y ni arrancaste con la tercerización... si la empresa hace outsourcing a unos pibes en India o Hungría, la responsabilidad se diluye mucho más.
-
¿Quién habló de tercerización en la India? ¿Boing y los errores en el software de la Starliner?
Ahora todos a programar en Ada
En la empresa en la que trabajo antes teníamos un soft para el pago de salarios, y una contadora nos hecho la culpa, porque el software no le aviso que tenía que pagar las cargas patronales. ¡Más ridículo no se consigue!