Primero, creo que muchos de estos resultados pésimos no provienen de que los ingenieros sean malos por naturaleza.
Simplemente toma a un ingeniero no muy senior, añade una gestión débil y un liderazgo técnico débil, aumenta la presión, y obtendrás toneladas de código basura al final.
Por cierto, lo que describo es solo una forma de obtener malos resultados. Existen otras formas: la cultura de no compartir conocimiento en la organización, la ausencia de mentoría, una dirección poco clara con cambios constantes y drásticos en los requisitos, etc.
Entonces, la verdad es que tienes múltiples entradas: personas, procesos, cultura y demás, y un solo resultado (tu software).
Puede que tengas personas buenas (o aceptables), pero si el resto de las entradas es basura, tienes garantizado que obtendrás basura al final.
Una nota al margen: Puedes argumentar que si las personas son buenas, podrían/deberían arreglar el proceso, la cultura, etc. Intentar arreglarlo desde la trinchera es extremadamente doloroso y rara vez funciona.
Este es otro tema del que escribí en el artículo "El mal ingeniero de una empresa es el buen arquitecto de otra empresa".
A veces, las personas simplemente no encajan bien en la empresa. La persona podría ser buena. La empresa podría ser buena. Sin embargo, pueden operar en frecuencias diferentes, valorar cosas distintas y enfatizar áreas diferentes.
Y a veces, es asombroso ver cómo una persona que era absolutamente terrible en un entorno (razonablemente bueno) prospera en otro entorno.
Ok... Fui amable y suave en las dos últimas secciones. Ahora es momento de sacar las armas pesadas.
Nos estamos acercando rápidamente a los 30 millones de ingenieros de software en todo el mundo. Eran alrededor de 5 millones en el año 2000 y algo así como 1 millón en 1980. (Por cierto, estos son números muy, muy aproximados que reuní de varias fuentes, así que tómalo con un grano de sal). Si retrocedes hasta 1960, el número de personas que hacían algo parecido a la ingeniería de software (con una gran mezcla de ingeniería de hardware) se medía en decenas de miles.
Por cierto, todos estos números cuentan solo ingenieros de software. Si agregas a esto la gestión de productos, la gestión de ingeniería de software, TI, Operaciones, etc., los números y el crecimiento se verán aún más impresionantes.
Un período de 60 años puede parecer largo para un ser humano. Sin embargo, es un abrir y cerrar de ojos desde una perspectiva social. Y dentro de estos 60 años, la industria pasó de casi nada a estos 30 millones de ingenieros. Oh... Y 5 de las 10 empresas más grandes por capitalización de mercado son empresas de software (con algo de hardware mezclado).
La industria del software absorbió a su órbita todo lo que se movía y podía escribir 'print "Hello world"'. Hay toneladas y toneladas de personas que fueron atraídas por las grandes cantidades de dinero que fluyen en el software (por cierto, no culpo a estas personas. Si mañana, los salarios en astrobiología se convirtieran en $5 millones al año, consideraría seriamente aprender más sobre formas de vida alienígenas :)).
El problema es que muchas de estas personas que no tenían interés en el software no están interesadas en aprender más o mejorar (siempre y cuando sigan recibiendo su cheque).
Y continuando con el tema del crecimiento explosivo de la industria del software.
Desafortunadamente, muchas personas que terminaron en el software no estaban bien preparadas para ello. Algunos se pondrán al día, pero muchos apenas estarán sobreviviendo, moviéndose de una empresa a otra, dejando un rastro de problemas detrás de ellos.
Hay otra cosa que fue causada por este rápido crecimiento.
Cuando una empresa crece muy rápido, generalmente termina siendo bastante perjudicial para la ingeniería. Si no tienes suficiente personal principal que sea bueno y que pueda compartir/mantener/imponer las mejores prácticas, llegarás rápidamente a un punto donde todo vale. Y la calidad de todo caerá muy rápido.
Lo mismo terminó sucediendo con la industria en su conjunto. El crecimiento fue demasiado rápido, mientras que muchas de las mejores prácticas ni siquiera se habían adoptado bien. De hecho, ni siquiera se ha llegado a un acuerdo sobre muchas de las mejores prácticas.
Como resultado, todos (incluyéndome a mí) a menudo reinventan las mismas ruedas repetidamente, tropezando y levantándose solo para descubrir cosas que deberían haber sido enseñadas en el primer año de universidad para las personas que ingresan a nuestra industria.
¿Cuánto en común tiene escribir software para la Voyager 1 frente a algún script desechable para limpiar datos en tu proyecto de pasatiempo?
El primero (Voyager) requiere sobrevivir décadas, trabajar en hardware extremadamente limitado y necesita estar documentado, revisado, revisado de nuevo y revisado una vez más.
El otro podría ser una basura, armado en 15 minutos, ejecutado una vez y desechado. Y en realidad puede ejecutarse en una configuración realmente potente y no será documentado, revisado, y así sucesivamente.
El software parece el mismo desde una vista de 30 mil pies. Sin embargo, la verdad es que la tecnología no es una industria uniforme ni por asomo.
Lecciones valiosas aprendidas en un área del mercado del software pueden ser perjudiciales en otra. Como resultado, los ingenieros que se mueven incluso a industrias adyacentes pueden llevar consigo lecciones equivocadas.
Primero que todo, creo que los mayores contribuyentes a malos resultados no son los malos ingenieros, sino las malas empresas.
Sin embargo, justo detrás de las malas empresas, están las personas que no tienen ningún interés en mejorar (y poner el esfuerzo honesto) y que se unieron al software solo por un sueldo más grande.
Recibí un buen punto adicional de Vivek: hay una cuestión de motivación. Creo que muchas personas que llegaron al software solo por dinero pueden disfrutar felizmente incluso del lado más bajo de los salarios en el mercado del software. Y podría ser demasiado problemático invertir mucho tiempo y energía en aprender más (para obtener un aumento lo suficientemente grande como para que valga la pena). 😉
Jorge García
Fullstack developer