Recientemente me he topado con este post en TheAtlantic.
Dice que los “Software Engineers” (aquí llamados Ingenieros Informáticos o Ingenieros de Software) no deberían llamarse jamás “ingenieros” a sí mismos, ya que echa por tierra una larga y establecida tradición y escuela. Parece ser que a nosotros, “los chicos del software”, no nos gusta llamarnos Programadores y en cambio nos gusta más el término “Ingenieros de Software” o “Desarrolladores de Software”.
En un primer momento, podríamos estar de acuerdo. Es decir, ¿cómo se puede comparar a una persona que construye una web con otra que construye edificios o aviones? Todos sabemos cuan susceptible de fallar es el software. Desde los archiconocidas (aunque ya olvidadas) pantallas azules de Windows, hasta los millones de cuelgues, bugs y problemas diversos en nuestro trabajo diario con los ordenadores y demás dispositivos.
Yo soy un Ingeniero Electrónico de formación, pero soy desarrollador de software en cuanto a profesión. Para que podamos llamar a un Ingeniero de Software “desarrollador”, este tiene que pasar en la carrera por exactamente las mismas asignaturas que muchos Ingenieros Electrónicos, Mecánicos o Industriales. He visto a chicos de Ingeniería Informática estudiando mecánica de fluidos. Quejándose -sí, lo admito- pero además teniendo que examinarse entre otras, de muchas asignaturas de matemáticas y física. A eso le tenemos que sumar estadística, contabilidad y gestión de proyectos.
No es mi intención alabar el sistema Universitario (español). Al revés, hay mucho espacio para la mejora. Pero de lo que sí me gustaría hablar es de si deberíamos llamar “ingenieros” a la gente que escribe código (insisto en el “si deberíamos”).
En primer lugar, un Ingeniero es una persona que diseña, construye, o mantiene motores, maquinaria o estructuras (sacado del diccionario). Una definición más pragmática que prefiero es “alguien que usa y combina diferentes campos de la ciencia y las matemáticas para resolver problemas del mundo real”. El tema es que aunque cojamos la primera definición, estaríamos hablando de motores, máquina o estructuras. Y el código no es más que un montón de estructuras que intentan vivir conjuntamente y que se comunican las unas con las otras.
Está claro que hay grandes diferencias entre construir un puente y montar un sistema informático. Y son precisamente esas diferencias las que hacen que el software sea más proclive a tener fallos que los puentes.
En primer lugar, cuando “definimos” un puente, todo esta mucho más atado. Las especificaciones son claras desde el principio y además, no cambian. Cuando se está construyendo un puente tú no vas al arquitecto o al ingeniero y le dices “escucha, ya sé que estabas construyendo el puente de dos sentidos de circulación, pero podrías añadirme también una vía de tren y una acera para transeúntes? ¿No cambia mucho, no?”. Pues esto en software pasa siempre. ¿Y sabéis qué? Pues que está BIEN que así sea. Porque los ingenieros resuelven problemas, ¿recordáis? Además, el “time to market” (el tiempo que se tarda en sacar un producto al mercado) es clave aquí. El software nos permite probar técnicas interesantes como el “continuous delivery”, el “client side iterations”, las metodologías Agile y toda esa jerga… Personalmente, yo no me imagino construyendo una central eléctrica y haciendo visitas guiadas al cliente final cada mes, o permitirle que las barras de uranio estén sueltas por ahí. En cambio, si que es normal construir una aplicación web “para unos cuantos cientos de miles de usuarios”, y entonces ver como tus servidores se saturan por un anuncio en la tele, o un link en reddit. Si un avión es para 400 pasajeros, nadie va a poner 500. De hecho, ahí los márgenes de riesgo son muchísimo más altos que en cualquier software que puedas encontrar. Si un servidor acepta 1 Millón de peticiones por minuto, pues vamos a intentar meterle 5 Millones, sólo para ver que pasa.
Dicho esto, cabe recordar que hay muchísimos tipos de proyectos de software. Desde una tienda online para una marca, hasta un microcontrolador que se encarga de la regulación de los flujos en el sistema de alcantarillado. Desde una app móvil, hasta el software que usan los controladores aéreos. O incluso el software que usan los ingenieros mecánicos para diseñar sus piezas o los arquitectos para diseñar sus estructuras.
Cada proceso, cada sistema, cada problema de un negocio o desafío en la vida real requiere ser abordado de forma distinta y con un conjunto de recursos concretos. A una pieza clave de software le podemos hacer un montón de Tests de Calidad, ya sean manuales o automatizados, podemos además ceñirnos a las especificaciones originales y asignar los suficientes recursos y tiempo para desarrollarla. Y entonces no fallará. O bien podemos tener en cuenta el “time to market”, jugar con los pocos recursos que disponemos y hacer cambios en caliente en producción y continuar solucionando problemas de negocio como ingenieros de verdad.
Entonces, tú que eres, ¿un programador o un ingeniero de software?
Si quieres saber que oportunidades laborales hay para Ingenieros Informaticos en Barcelona hecha un vistazo a JobsBCN.